nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Filling fields via scripting affects uninvolved issues that were cloned?

unknown

Hello,

in our "change management" process we normally raise an issue from type "suggestion" which gets cloned into a "request" issuetype and finally gets cloned into a "change" type issue. To track several fields like "release date" and stuff we implemented a script fragment panel and a script listener which gets displayed in the "request" issuetype and shows relevant data from the "change" issuetype.

Problem: In our issue search and furthermore our gadgets and reporting dashboards the initial issuetype "suggestions" now also shows data in fields like "release date". But these fields are only configured and relevant for "changes" and get synchronized backwards to the script runner web panel displayed in "requests". We use the following script to fill the web panel fragment:

ApplicationUser superuser = ComponentAccessor.userManager.getUserByName("superuser")

def issueManager = ComponentAccessor.getIssueManager()

Date date = new Date();

SimpleDateFormat dateFormat = new SimpleDateFormat("DD/MM/YYYY");
String formattedDate = dateFormat.format(date);

IssueLinkManager issueLinkManager = ComponentAccessor.getIssueLinkManager()

List<IssueLink> inwardLinks = issueLinkManager.getInwardLinks(event.issue.getId())

// CustomField implementationIssue = ComponentAccessor.getCustomFieldManager().getCustomFieldObject("customfield_11572");
CustomField implementationStatus = ComponentAccessor.getCustomFieldManager().getCustomFieldObject("customfield_11601");
CustomField implementationManager = ComponentAccessor.getCustomFieldManager().getCustomFieldObject("customfield_12600");
CustomField readyPlan = ComponentAccessor.getCustomFieldManager().getCustomFieldObject("customfield_12605");
CustomField readyIs = ComponentAccessor.getCustomFieldManager().getCustomFieldObject("customfield_12604");
CustomField releasePlan = ComponentAccessor.getCustomFieldManager().getCustomFieldObject("customfield_12606");
CustomField releaseIs = ComponentAccessor.getCustomFieldManager().getCustomFieldObject("customfield_12607");
CustomField release = ComponentAccessor.getCustomFieldManager().getCustomFieldObject("customfield_11400");
CustomField changeManager = ComponentAccessor.getCustomFieldManager().getCustomFieldObject("customfield_10315");

for (IssueLink issueLink : inwardLinks){
Issue destination = issueLink.getDestinationObject()
Issue source = issueLink.getSourceObject()
MutableIssue mutableSource = source as MutableIssue
MutableIssue mutableDestination = destination as MutableIssue
if (issueLink.issueLinkType.name == "link" && source.getProjectId() == 10100L && destination.getProjectId() != 10100L) {
log.debug("ID parent: " + mutableSource.getId())
log.debug("Key Parent: " + mutableSource.getKey())

mutableSource.setCustomFieldValue(implementationStatus , destination.getStatus().getSimpleStatus().getName().toString())
mutableSource.setCustomFieldValue(implementationManager , destination.getCustomFieldValue(changeManager));
mutableSource.setCustomFieldValue(readyPlan, destination.getCustomFieldValue(readyPlan ))
mutableSource.setCustomFieldValue(readyIs, destination.getCustomFieldValue(readyIs))
mutableSource.setCustomFieldValue(releasePlan, destination.getCustomFieldValue(releasePlan))
mutableSource.setCustomFieldValue(releaseIs, destination.getCustomFieldValue(releaseIs))
mutableSource.setCustomFieldValue(release, destination.getCustomFieldValue(release))

issueManager.updateIssue(superuser, mutableSource, EventDispatchOption.ISSUE_UPDATED, false)
issueManager.updateIssue(superuser, mutableDestination, EventDispatchOption.ISSUE_UPDATED, false)

log.debug("Ready")
} else {
log.debug("Project not BRM")
} 
}
}

Accepted answers

Marc Minten (EVS)

Just add a check on issue type where you check already link type and project ?

Unfortunately, for the issues where the values are already copied by the script above, the values will remain...

All comments

Marc Minten (EVS)

Just add a check on issue type where you check already link type and project ?

Unfortunately, for the issues where the values are already copied by the script above, the values will remain...

unknown

Thanks for your reply. I added some check in the if clause which looks like the follwing:

if (issueLink.issueLinkType.name == "link" && source.issueType.name in ["Request"] && destination.getProjectId() != 10100L)

It's still copying these values to our initial "suggestion" issue type. Am I mising something? Should I check for issuetype in my for loop before? Or maybe my source.issue calls for all sources in the link hierarchy not only the "request"?

Marc Minten (EVS)

First : your code is really hard to read (no indentations at all).

What links do exist between your Suggestion, Request and Change issues ? You talk about "cloning" and you check in your script on a link type "link" ???

What do you find in your log files as result of the log.debug statements in your script (assuming you activated DEBUG level logging) ?

unknown

Sorry for that, but the style gets lost when I copy my blocks into these text fields here.

Normal issue links, don't know what it's called in english but in german it would be "Verknüpfung".

I added 2 more logging statements (Issue Key and LinkList):

2020-01-08 12:06:38,622 DEBUG [groovy.PostFunction]: Issue: ERP-48

2020-01-08 12:06:38,623 DEBUG [groovy.PostFunction]: [com.atlassian.jira.issue.link.IssueLinkImpl@4638ee81[id=13832,sourceId=20838,destinationId=20839,issueLinkType=10300], com.atlassian.jira.issue.link.IssueLinkImpl@5e757180[id=13831,sourceId=20837,destinationId=20839,issueLinkType=10300]]

2020-01-08 12:06:38,625 DEBUG [groovy.PostFunction]: ID parent: 20838
2020-01-08 12:06:38,626 DEBUG [groovy.PostFunction]: Key Parent: BRM-25

Im confused since the issueLink shows 2 Links from our request (ID 20838) to our change (ID 20839) and from our suggestion (ID 20837) to our change (ID 20839). Maybe thats the problem?

Another problem is, that the last 2 logging statements ("Ready" / Project not BRM") won't get reached and the issues might not get updated. You have and clue about that?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

scriptrunner

jira-software

jira-software-server

script

link

panel

web-fragment