Select List (Single Choice) Custom Field Values are NULL When Using Exalate Now Post Function

General Questions
, , ,
1

Originally asked by John Anderholm on 05 April 2021 (original question)

In our setup, we are attempting to use a transition to Exalate issues in JIRA (Server). When the “Exalate” workflow transition is selected, the user is prompted with a screen presenting two custom fields:

  1. Exalate Project
  2. Exalate Issue Type

Both are “Select List (Single Choice)” fields. Using these fields, the target project and issue type will be selected, and then those values will be used for creating the new issue during the first sync. However, when using the “Exalate Now” post function, the custom fields are passed without their assigned values (i.e. the value property is missing).

The outgoing script is setup like so:

Outgoing Sync Snippet

replica.customFields."Exalate Project" = issue.customFields."Exalate Project"
replica.customFields."Exalate Issue Type" = issue.customFields."Exalate Issue Type"

And the remote replica contains the custom fields but without the value property:

Remote Replica Snippet

    "customFields": {
      "Exalate Project": {
        "id": 14211,
        "name": "Exalate Project",
        "uid": "14211",
        "description": "The project to Exalate to.",
        "type": "OPTION"
      },
      "Exalate Issue Type": {
        "id": 14209,
        "name": "Exalate Issue Type",
        "uid": "14209",
        "description": "The type of issue to Exalate to.",
        "type": "OPTION"
      }
    },

Since the id /type/description properties are present, that indicates that the field name is being passed with the correct spelling. And there is a [JSU] validator in place to require a non-null value for both fields before the transition can occur.

I originally suspected it might be a delay issue - where the values set during transition weren’t yet available to the outgoing query. However, if I edit the issue and set the values before invoking the transition, they are still unavailable during the outgoing sync.

Additionally, I have implemented the following workaround:

  1. Remove the “Exalate Now” post function from the transition;
  2. Configure a trigger to exalate where:

Trigger If

"Exalate Project" is not EMPTY AND "Exalate Issue Type" is not EMPTY

In this scenario, the data is passed as expected. So it seems to be only during a transition that the value of the custom fields are getting omitted/popped.

2

Answer by Ariel Aguilar on 06 April 2021

Hi John,

This conflict has to do with the moment that the post function is called. It should be called after the changes have been stored. Please take a look at our documentation:
https://docs.idalko.com/exalate/x/rAjuAg

Kind regards,

Ariel

[Failed to download attachment: attachment_25071110__thumb_91874.png. Error: 401 Client Error: for url: Select Identity Provider - Jira - Idalko]

Comments:

John Anderholm commented on 06 April 2021

Hi Ariel,

At the time, the post function was placed after the Re-Index step (which is after the Update step), so I don’t believe this was the issue.

Additionally, even if the values are set on the issue before invoking the transition, they are still not passed.

Steps to reproduce:

  1. Edit the issue;
    1. Set “Exalate Project” → “Car”;
    2. Set “Exalate Issue Type” → “Bug”;
    3. Update;
  2. Transition the issue (“Exalate” transition);
    1. Set “Exalate Project” → “Moped”;
    2. Set “Exalate Issue Type” → “Story”;
    3. Exalate.

If it were a matter of the post function order, I would anticipate the values in the above scenario to be “out of date” (Car/Bug instead of Moped/Story). But they are still missing altogether.

I also tried removing all other variables from the transition (there was a JSU validator as well as a post function to change the assignee of the issue), but still no go.

Francis Martens (Exalate) commented on 06 April 2021

The trigger approach is indeed a good alternative. Still the updated fields should be available to the outgoing processor.

John Anderholm commented on 06 April 2021

Hi Francis,

I think we’ve determined we like the trigger better in some regards, so it’s not a pressing issue for us. I would’ve liked to have had all of the activation logic confined to the workflow (less moving parts), but this current setup will also allow for somebody to edit the issue directly and invoke the exalation.

Some possible clues (or red herrings):

Field ID v Name

We previously encountered this issue and discovered a workaround was to use the custom field id in lieu of the name - e.g.:

replica.customFields."14211" = issue.customFields."14211"
replica.customFields."14209" = issue.customFields."14209"

At the time, this seemed reliable but, in retrospect, perhaps it was just the luck of the draw. Since the problem returned, I’ve seen no difference in using the id or the name.

Funky Cache State?

I’ve managed to get the outgoing replica to have the values after the first fail (though it still won’t succeed). Say I have the following code in the outgoing sync:

replica.customKeys."ExProj" = issue.customFields."Exalate Project".value.value

On the initial call to exalate, it will error that issue.customFields."Exalate Project".value is null and has no value property. At this point, the outgoing replica is also null.

If I simply retry the error without changing the code, an odd thing happens. Firstly, I get the exact same null error about value (undesired but expected). However, at this point the outgoing replica is fully populated including my missing data.

So replica.customKeys."ExProj" will be set to the expected value in the remote replica even though it errored that the value being assigned didn’t exist. So it’s almost like the outgoing sync is being run twice?