Table of contents

It happens sometime that the values in the datasource got changed (updated or deleted). So, if those values were presents on Jira issues, in an Elements Connect field, how the field will behave?

This is a tricky subject, and it depends on the user use case (we can't provide a solution that covers all the cases), but at least, there are some general concepts that should be considered.

Before starting, it's important to always remember that:

• The Key of a Connect field of type Live, should be unique and doesn't change because this Key is the only value Elements Connect stores in Jira database.
• If what we delete/update in the datasource is the field Key value, there's no way to keep the value selected once the issue is edited (a change request already exists to overcome this problem, please check CO-2837).

We can have 3 scenarios:

Deleting the field key value

A Connect field of type Live is defined by its Key. The Key is the only data that Elements Connect stores in Jira database, and through this Key, other data is retrieved dynamically by executing the query (the "Display query" if configured, otherwise the "Edit query").

Now, if the field Key is deleted, the link between the field in Jira issue and the datasource is broken. In that case, $currentCustomfieldValue variable will be displayed which contains the previous field Key value.

Let's have as an example the following Connect field which will list the issues from another project Asset.

• Type: Live Text.
• Datasource: Jira issues JQL

And this is how the field is displayed on Jira issue:

Now, If the user needs to delete the asset laptop, $currentCustomfieldValue variable will be used and displayed in the field, which contains the previous field Key.

Two possible solutions:

• The best practice is to not delete the Key in the datasource, but rather If it's possible, to create a new attribute in the datasource, let's say "Disabled", which takes as values 0/1. When the user needs to delete a value, that attribute will be set to 1; otherwise, it's set to 0. Consequently, the Edit query of the Elements Connect field should be updated to retrieve not disabled values.
  In the above example, as we can't add an attribute, let's say we will move the issues that we don't want them to be selected to a specific status "Done". That way, only issues in a status other than DONE will be listed. The edit query should be updated consequently as below:

  project=AST and status !=DONE

• Use a Snapshot field. The Snapshot field functions differently than the Live field. one of the main differences is the fact that it has no Key, what is displayed in the field is stored in Jira database. If that displayed value was deleted, it will always appears on the Jira issue unless the field is edited. Once edited, the data will be lost.

Updating the field Key value

As said above, the best practice is to keep the field Key unique and not change. In fact, when the user needs to update the Key value of a Connect field, that indicates that they have chosen a wrong Key for their Connect field.

Some examples: using company name, account manager,... as Key. Instead, it's better to use company id, account manager id.

Let's have as an example the following Connect field (an Issue Picker):

• Type: Live Text.
• Datasource: Jira SQL database.

On issue view, this is how the field will appear:

Now, imagine we need to transfer the issue selected in the field (its Key is TEST-168) to another project. The issue key will change for sure, and consequently, the field Key (a combination of project key and issue number) will change.

In this case, the $currentCustomfieldValue variable will be displayed and it will contain the previous field Key value.

In this case, the only solution is to use a Snapshot field. As mentioned before, the Snapshot field has its limitations, so it might be not the preferable solution for many users.

Deleting/updating the field Display value

The field Display value is what we see on the issue view screen. As said before, through this Key, other data is retrieved dynamically by executing the query (the "Display query" if configured, otherwise the "Edit query"). 

Unless the Display value is the same as the Key (in this case we are back to one of the previous scenarios), changing the Display value (what we set in the Template) will reflect directly on the issue because the Key didn't change.

In other words, field can still be edited without loosing any data.

So for the above issue picker field, if we update the query as below to display the issue description in the Template besides the issue summary (Key always on issue ID):

On the issue view, this is how the field will be displayed:

The same issue is always selected and the description will appear directly besides the summary.

Updating the summary or description of the selected issue will also reflect automatically on the issue view screen.