Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Transition linked issues (JMWE add-on) does not work for transitions that have scripted conditions

Hi.  I'm using the JMWE Transition Linked Issues post function in the workflow on a Feature to transition it's parent Capability.  They're in a Jira Portfolio parent/child relationship. 

The post function on the Feature is configured to run as a specific account which has all the necessary permissions on the parent Capability. 

On the parent Capability's target workflow transition, I have a Scripted (Groovy) Condition (JMWE add-on) Condition which checks that all of the Capability's child Features have a certain value in a single select field. 

The scripted condition is very simple and works fine:

!jqlSearch( "\"Parent Link\" = ${issue.key} and \"Commit Status\" not in (\"Full Commitment\")", 1 )

There is also a second condition on the Capability transition which requires that the account executing the transition be in a certain group. Both conditions must be met.

When the post function on the Child Feature executes, it runs as an account that passes the group membership condition and has all necessary permissions. 

When the post function on the child feature runs, and all conditions are satisfied, the parent Capability should transition accordingly.  But it doesn't.  It does not throw any errors if I configure both parent and child transitions to fail on an error.  Nothing appears in the Jira logs.  It simply does not work. 

If I become the account that the transition runs as, I can manually execute the transition on the parent and it works perfectly fine.  But the only way that I can get it to execute from the child Features transition is if I configure the transition linked issues post function to ignore the conditions on the target transition.  That's not an option for me.  I need it to work as it should. All conditions are satisfied, yet it simply does nothing as if it didn't even try.  This only seems to happen when there is a Scripted (Groovy) Condition (also JMWE) on the target transition.  The transition on the Capability executes just fine with non-scripted, canned conditions that I've tried in troubleshooting. 

I've tried everything that I can think of.  I can only conclude that this is a bug??  I really need to get this working and its extremely frustrating when I know that everything is configured correctly and yet it seems to simply do nothing, with no errors or other explanation.  My only clue is that telling it to ignore the conditions on the target transition allows it to execute, but at the same time, it does not fail to pass the conditions that are set there.  It just seems to pass out and melt into a puddle when a JMWE scripted condition is present and not even TRY to execute the transition.

Any ideas? 

2 answers

1 accepted

0 votes
Answer accepted

Hi Andy,

my guess is that your problem comes from the fact you're using a JQL search in your condition. JQL searches rely on the Jira index to be up to date. So the JQL search, when it runs, doesn't yet see the changes made by the child transition.

You can try moving the Transition Linked Issues post-function to the very bottom of the list of post-functions (after the "reindex" post-function). But a better (and more efficient) solution would be to rewrite your Groovy condition without using a JQL search:

issue.portfolioParent?.portfolioChildIssues?.every {it.getAsString("Commit Status") == "Full Commitment"}

Thanks David.  I gave it a try but it didn't work. I don't know if the transition on the parent would have fired. The problem this time seems to be with the groovy script you gave me.  When the condition that I want is satisfied, the script you gave me doesn't think that it is.  I'm sure it's a very simple change that's needed.   If I was any good at all with groovy scripting I wouldn't have been trying to use the jql search. 

Here's what it should be doing in the Condition on the Parent Capability workflow:  Check that the Commit Status field on ALL Child Features has the "Full Commitment" value. All child features must have "Full Commitment" in their Commit Status field. If not then the condition will not be passed.

 

Thanks for your help and your patience with a complete non-developer.

Also, FWIW, I had already tried moving the original post function down a step at a time until it was at the very bottom and the behavior remained unchanged.

Sorry it didn't work.

Two questions:

  1. did you try simply removing the Scripted Condition (or replace it with "return true") to make sure the transition is triggered then (thus eliminating or mis-configurations)?
  2. Which version of Jira, JMWE and Jira Portfolio are you using? The portfolioChildIssues method only works with recent Portfolio versions, and only if you update the hierarchy from Portfolio (because Portfolio now uses issue links to represent the hierarchy, but doesn't automatically add them to existing issues unless you re-apply the hierarchy).

You can also try raising the log level to DEBUG for the "com.innovalog" package and trigger the child transition again - then you'll have much more information in the logs.

We're on Jira server 7.9.2 and Portfolio 3.x.  JMWE is at latest level (as is Portfolio).

But I don't think any of them are the problem.  I'm optimistic about this working now, but I think that something in this just isn't quite right, because when the condition is met and should return true it still returns false:

issue.portfolioParent?.portfolioChildIssues?.every {it.getAsString("Commit Status") == "Full Commitment"}

 

What I did was copy & paste (plain test) that snippet into the scripted condition in place of the former.

 

Looking at that snippet, I see that "it" and "every" are bold.  is that expected or an indication of missing or hidden characters or some other mishap?

Hi Andy,

did you "Test" the script in the Groovy Console, against a Feature whose Capability's Features all have a  "Full Commitment" Commit Status?

Did you check the exact (case- and space-sensitive) value of the expected Commit Status?

If the code doesn't return the expected value in the Groovy Console, you can add some debugging code to figure out why (and then "Test" again - you'll see the log output in the test result box):

log.debug("Parent key: "+issue.portfolioParent.key)
log.debug("Siblings: "+ issue.portfolioParent.portfolioChildIssues)
issue.portfolioParent.portfolioChildIssues.each{
log.debug("Feature "+it.key + ", Commit Status='"+it.getAsString("Commit Status")+"'")
}
issue.portfolioParent?.portfolioChildIssues?.every {it.getAsString("Commit Status") == "Full Commitment"}

Hi @David Fischer _Innovalog_ 

I finally did what I should have done long ago and spent a few hours brushing up on groovy scripting.  There was nothing wrong with what you gave me, just a misunderstanding between us in terms of what I needed it to do.  The Code you gave me was checking the content of the "Commit Status" fields on 'Siblings' as opposed to Children.  Your 'debugging' code helped me to see that.  Once I finally took the time to learn a little bit, the modification needed was very simple and clear.  

On the chance that this might help other non-developers like me, here are a few examples of groovy scripting for workflow conditions (or whatever your purpose).  In my case, these are applied as scripted Conditions within the workflow of a Capability, which is the parent of a Feature.

(1) Checks that the 'Commit Status' fields on ALL child Features of a parent Capability have the value of "Full Commitment" in them.  If not then the condition will not be passed. (Groovy script)

WITH DEBUGGING:
log.debug("Parent key: "+issue.portfolioParent.key)
log.debug("Children: "+ issue.portfolioChildIssues)
issue.portfolioChildIssues.each{
log.debug("Feature "+it.key + ", Commit Status='"+it.getAsString("Commit Status")+"'")
}
issue.portfolioChildIssues?.every {it.getAsString("Commit Status") == "Full Commitment"}
WITHOUT DEBUIGGING:
issue.portfolioChildIssues?.every {it.getAsString("Commit Status") == "Full Commitment"}


(2) Checks to make sure that none of the child Feature's Commit Status fields contain "Full Commitment".  If even one of the Child Features Commit Status fields contains "Full Commitment", then the condition will not be passed.

issue.portfolioChildIssues?.every {it.getAsString("Commit Status") != "Full Commitment"}

 

(3) Checks that at least 1 child Feature's Commit Status field has the "Full Commitment" value.  If not the condition will not Pass.

issue.portfolioChildIssues?.any {it.getAsString("Commit Status") == "Full Commitment"}

 

(4) Checks if ALL child Feature's have the "Full Commitment" value in their 'Commit Status' field.  If they do, then the condition will not be passed.

issue.portfolioChildIssues?.every {it.getAsString("Commit Status") != "Full Commitment"}

 

And lastly a couple examples below involving subtasks instead of 'Portfolio Manager' Parent/Child (Parent Link) relationships as are shown above.  These cases could not be satisfied using one of the canned JMWE conditions and thus required using a scripted one.  Also note that the cases below are checking status vs checking the content of a field (as above).

(5) Checks that at least 1 subtask is in the "Full Commit" status.  If not, then this condition will not pass.

issue.subTaskObjects.any { it.statusObject.name == "Full Commit" }

 

(6) Checks if ALL subtasks are in the "Full Commit" status.  If they all are, then the condition will not be passed.

issue.subTaskObjects.any { it.statusObject.name != "Full Commit" }

 

Hopefully these examples will help someone just as David helped me.  And if you don't have the JMWE add-on... you should get it!  ;)

HI @David Fischer _Innovalog_ 

I am trying to trigger another transition using JWME to create an issue post function.

in this post function.. I have added the below code in Post creation script block but it's not working.

//241 - is the transiotn ID

//ApplicationUser user = ComponentAccessor.getJiraAuthenticationContext().getUser();
IssueService issueService = ComponentAccessor.getIssueService();
IssueInputParameters issueInputParameters = new IssueInputParametersImpl();

TransitionValidationResult validationResult = issueService.validateTransition(ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser(), newIssue.getId(), 241, issueInputParameters);
if(validationResult.isValid()){
issueService.transition(ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser(), validationResult)
}

Getting below Error:

groovy.lang.MissingPropertyException: No such property: newIssue for class: script1586411867802147328352
Stack:
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:65)
org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:51)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:309)
script1586411867802147328352.run(script1586411867802147328352.groovy:12)

 

Could you pls help on this.

Thanks,

Yogesh

Hi Yogesh,

are you getting this error using "Test Groovy Script" or when actually triggering the transition? Because if the former, that's unfortunately normal because when testing, you are not actually creating a new issue so the newIssue variable doesn't exist...

Hello David,

i checked while creating an issue it's not working.

while transitioning issue I have added a post function with create an issue so the issue is creating fine, and in the same post function I wrote the script for transition this newly created issue using post-creation script.

And which version of JMWE are you using?

we are using JMWE v6.1.3

Can you share a screenshot of the post function configuration?

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Marketplace Apps & Integrations

Bitbucket Smart Commits vs. Genius Commits - What's the difference?

If you already heard about Smart Commits in Bitbucket, know that you just stumbled upon something even better (and smarter!): Genius Commits by Better DevOps Automation for Jira Data Center (+ Server...

130 views 0 2
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you