Seeking advice. I use a custom integer field, call it, JobID, and let it lie on parent and subtask. At each workflow transition for each subtask, a post trigger copies the parent's JobID to the subtask's JobID field. This JobID is used to form the basis for a "customer project" - a collection of work to be built - this is how we define our projects. To be clear, I'm NOT talking a "JIRA Project" when I say customer project.
Creating a filter against all things with JobID ~ '123' yields the collection. However, often times, the JobID is fat fingered at creation or more usually, the story simply belongs against another customer's job after some other review, etc...so, the user simply updates JobID on the applicable Story from 123 to 456.
Downstream, folks are pulling reports against the data behind that JobID ~ 123 filter, and find it doesn't balance with our billing system at times (there are more hrs in JIRA than our billing system shows).
The reason: The story that was updated to 456 did not propagate the change (yet) to its child subtasks because the subtask has simply not been transitioned. I'm referring to my post trigger defined above.
The result: The filter still includes that subtask with 123 on it even though it really belongs with story 456.
How do you carve out a collection of issues to define your "customer project"? This seems so elementary to solve, but seemingly has me cornered at the moment and accountants wondering what the heck are we doing over here:-).
JQL has some limitations and I'm afraid there's no way to search for issues that have a value on a given custom field and their sub-tasks have a different value.
As for preventing this in the future, my suggestion is to remove the custom field from the edit issue screen, so it cannot be editable, unless the issue is transitioned. In addition to that, I would add transitions in every step of the workflow that transition the issues to the same status as it currently is, and add the post function to copy the value from the parent to the child issue. This way, it is possible to edit the value for that custom field and not change the status of the issues.
I hope this helps.
What a terrific solution, Clarissa. That should work perfectly. The only thing I think I'll need to validate once I make those changes is to assure that this custom field can still accept a value at issue creation. In other words, when the user creates the parent issue, that custom field needs to be visible and accept a value. Big thank you...so far.
Clarissa - Updating my custom field only on the transition screen for the parent is perfect, but how would I go about pushing the new value of that custom field to all of the children? I don't see a mechanism in my Cloud instance to transition subtasks from the parent...or conversely, I don't see a means to trigger the update from the subtask when the parent changes. Perhaps I'm not understanding what you mean by..."transition the issues to the same status as it currently is..."
Hey Paul, in the same way you did before, you were using a post trigger copies the parent's JobID to the subtask's JobID field. For instance, your parent issue is currently "In Progress" and you want to edit the JobID from it but you don't want to change the issue status. What I meant by "transition the issues to the same status as it currently is..." is to have a transition from "In Progress" to "In Progress", so you can edit the field without changing the issue status. My suggestion is to have those transitions that will transition the issue to the current status in all of your workflow steps. Cheers, Clarissa.
I see - that's a good trick to use to update JobID on the parent without transitioning the parent's status. I understand this part. But, how do I then get the new JobID value I just updated on the parent to its children? I see no post function to copy the value to the child from the parent (I can only set a function to copy a value from a parent to a child). Thanks for your patience.
Hi Paul, Sorry for the delay. I was searching on the web, and it seems the post function Set Field Value from Parent post function works only on the workflow of child issues. If you are trying to copy fields from a parent issue to all its child issues when transitioning the parent issue, this won't work. In this case, I believe the workaround I provided you won't work, at least not on Cloud. I was able to find another add-on callled Minyaa: https://marketplace.atlassian.com/plugins/jira.plugin.minyaa that has a post function "Inherit Custom Field Workflow Function": http://www.minyaa.com/documentation/3.4/Features/ModuleWorkflows/WorkflowFunctions/InheritCustomfieldsFunction.html that might help you with that, however this add-on is not available on Cloud, you would have to use JIRA Server to use that. Cheers, Clarissa.
Correct. At least I know we're on the same page. Thank you for that. So, I'm left with both dilemmas unresolved, unless anyone has any bright ideas for a Cloud user. 1. I cannot programatically locate subtasks without its parent "JobID" custom field. 2. I cannot programatically update "JobID" custom field on a parent issue and expect to get it copied to the subtask(s)
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
@Rachel Wright (Jira Genie), @Billy Poggi (AUG NOVA, DC), and @Dana Jansen (Confluence Queen) are just some of the folks that lead one of the world's most active Atlassian User Group (AUG)....
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs