Epic Status value sync help

Use Case
, , , ,
1

Originally asked by Ariel Aguilar on 07 August 2021 (original question)

Question by Kevin Ketchum:

I am getting this error in the sync attempt while trying to sync the Epic Status value:
Field Specify a valid ‘id’ or ‘name’ for Epic Status: customfield_10012.
This is my setting on the incoming script - as you can see, I’m setting it to a specific value:
issue.customFields.“Epic Status”.value = “To Do”

Jira Server Outgoing:

replica.customFields."Epic Status" = issue.customFields."10003"  //Epic Status (gh-epic-label)

Jira Cloud Incoming:

def epicstatusMap = ["10000":"10016", "10001":"10017", "10002":"10018"] //To Do In Progress, Done
	def epicstatusIncomingID = replica.customFields."Epic Status".value.value
/*
  	def epicstatusId = epicstatusMap[epicstatusIncomingID]
    if (epicstatusId == null) {
      throw new com.exalate.api.exception.IssueTrackerException("No Epic Status mapping for incoming Epic Status value(s) " + epicstatusIncomingID)
    }
    */
issue.customFields."Epic Status".value = "To Do"

Comments:

Daniel Carvajal commented on 07 August 2021

Hi

From the line:

replica.customFields."Epic Status" = issue.customFields."10003"

Could you verify that the custom field Id “10003” is the correct one for the Epic Status field, usually 10003 is used for Epic Name.

Kind regards,

Daniel

Kevin Ketchum commented on 09 August 2021

I have confirmed in our system, the Epic Status internal ID is 10003.

In case this helps, the replica data from our system (when looking at the error in the cloud instance) shows this for the Epic Status field:

"10003": {
        "id": 10003,
        "name": "Epic Status",
        "uid": "10003",
        "description": "Epic Status field for Jira Software use only.",
        "type": "OPTION",
        "value": {
          "id": "10002",
          "sequence": 2,
          "value": "Done",
          "disabled": false,
          "childOptions": []
        }
      },
Kevin Ketchum commented on 11 August 2021

Another observation:

When I use this to attempt update the Epic Status field:

I get this in the stack trace.

Using Postman, when I use this JSON to attempt to update the field, I get the exact same error

(the top is the JSON I use in the PUT, and the bottom is the results)

However, when I use this JSON format, the field is updated correctly:

2

Answer by Kevin Ketchum on 25 August 2021

I believe I have this under control.

my sync is configured as such (basically):

if (issuetype == "bug") {
   ... update bug specific fields
} else if (issuetype == "epic") {
    ... update epic specific fields
    def epicStatusValue = replica.customFields."Epic Status".value.value
    issue.customFields."Epic Status".value = nodeHelper.getOption(issue, "Epic Status", epicStatusValue)
} else if (issuetype == "story") {
    ... update story specific fields
} else if (issuetype == "task") {
    ... update task specific fields
}
Epic.receive()

Then, per the exalate documentation, I added Epic.receive() to the end if the imcoming sync

567×154 6.18 KB

(see this documentation: https://docs.idalko.com/exalate/display/ED/How+to+sync+epics+in+Jira+Cloud)

When I do that, I get the error initially reported.

So, I have adjusted the sync config as follows:

if (issuetype == "bug") {
   ... update bug specific fields
   Epic.receive()
} else if (issuetype == "epic") {
    ... update epic specific fields
    def epicStatusValue = replica.customFields."Epic Status".value.value
    issue.customFields."Epic Status".value = nodeHelper.getOption(issue, "Epic Status", epicStatusValue)
} else if (issuetype == "story") {
    ... update story specific fields
    Epic.receive()
} else if (issuetype == "task") {
    ... update task specific fields
    Epic.receive()
}

Notice the Epic.receive() code is at the end of the incoming sync (per the documention), but it is now inside all code sections EXCEPT the epic section, instead of at the end of all code.

So far, this seems to work.

I’ll update it as I see more or less success.

Comments:

Francis Martens (Exalate) commented on 26 August 2021

Ah - thanks for the hint. We’re reviewing the external script and will take this into account

3

Answer by Francis Martens (Exalate) on 19 August 2021

Kevin Ketchum

I reproduced the problem as follows

  • Setup a local connection
  • Add following code to the connection
if (firstSync) {
...
    if (issue.typeName == "Epic") {
        issue.customFields."Epic Name".value = "Hello"
        issue.customFields."Epic Status".value = "To Do"        
    }
}
  • Trigger an exalate
  • See that it fails with the failure

Then adapt the code to

if (firstSync) {
...
    if (issue.typeName == "Epic") {
        issue.customFields."Epic Name".value = "Hello"
        issue.customFields."Epic Status".value = 
					nodeHelper.getOption(issue, "Epic Status", "To Do")        
    }
}

And now it works.

Give it a try

Comments:

Kevin Ketchum commented on 19 August 2021

I’ll try it out - but first I have a question.

You are using the qualifier

if (firstSync) {  
  
}  
  
What happens if this is not the first sync but, instead, is an update?

What is the actual affect of using (or not using) the firstSync qualifier ?

Francis Martens (Exalate) commented on 19 August 2021

That is completely fine.

Kevin Ketchum commented on 20 August 2021

It looks like the Epic Status was settable during initial issue creation.

However, whenever I use this code:

  issue.customFields."Epic Status".value \= nodeHelper.getOption(issue, "Epic Status", "To Do")

to update the issue (specifically, change the Epic Status), I get the same error:

  Could not update issue \`10,034\`: Field customfield\_10012: Specify a valid 'id' or 'name' for Epic Status.