Due to JRASERVER-16281, A4J smartvalues "issue.issuelinks.last.*" or "issue.issuelinks.first.*" behaves unreliably

Problem Definition

In A4J rules we can have the following smartvalues related to Issue Links which might fail to fetch the correct linked issue details based on the scenario:

{{issue.issuelinks.first.outwardIssue.<attribute>}}
{{issue.issuelinks.last.outwardIssue.<attribute>}}
{{issue.issuelinks.first.inwardIssue.<attribute>}}
{{issue.issuelinks.last.inwardIssue.<attribute>}}

This is because A4J fetches the "last" or "first" values based on Jira APIs where the issuelinks section is alphabetically ordered instead of displaying the issues in the order they were linked.

Due to this behaviour (as described in JRASERVER-16281), if there are multiple issue links from different projects, the issue.issuelinks.last.inwardIssue.key, for example, might fetch the incorrect issue key depending on the alphabetical order of the project keys.

For example, Let's say there are the following issue links in a given issue "ROOT-1234":

1. Linked "HELPDESK-10"
2. then linked "ADMIN-25"

Even though we'd expect issue.issuelinks.last.inwardIssue.key smartvalue to print "ADMIN-25" issue key, it would instead print "HELPDESK-10" because Jira orders the issue links alphabetically and hence HELPDESK project would be the last in that order.

Look at the source issues REST API output of https://<BASE-URL>/rest/api/2/issue/ROOT-1234

{
  "id": "10330",
  "key": "ADMIN-25",
.....
}
{
  "id": "10324",
  "key": "HELPDESK-10",
...
}

Suggested Solution

The Solution has to come from Jira (a feature added against JRASERVER-16281) where the Issue Links contain a timestamp so that A4J can then rely on the timestamp to reliably determine which linked issue should be considered "first" and "last".

Workaround

Depending on the scenario, the following smartvalue can be used instead:

{{createdissue.key}}
{{createdissue.summary}}
...
{{createdissue.<attribute>}}