Encapsulating a customer project

[Paul Alexander]

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.

Possible Solutions/Questions:

1. I tried using a different metaphor to define the customer project...Epic would be good, but epic is unaware of children attached to the issues related to the epic. (e.g., "Epic Link" in (TST-1234) returns only parent issues.
2. JIRA certainly understands the aggregate function to declare time spent on a parent (and look at all of its children)...but throwing a collection of parents (only) at a report (either in JIRA or in Tempo) yields no data - since it apparently can't walk the tree to its children to get its work logs.
3. How to find all subtasks whose parent's JobID does not match its JobID? That would help me clean up legacy data problems as a first step.
4. I can't trigger an event based on someone updating a field, so what to do? You may say...well, wait for the next transition, right?? That's not an option since a subtask may sit dormant for a while.
5. Another option could be...put process in place to ask the person who updates the JobID on the story to also update the JobID on all of its children......that too wont' work since by design, I hide the JobID on subtasks because I don't want someone hacking the field.

6. 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:-).

[cgauterio]

Hi Paul,

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.

Cheers,

Clarissa.

[Paul Alexander]

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.

[cgauterio]

Welcome Paul. In this case, you just need to use different screens for the Create and Edit issue operations. This way, the field can be present in the screen when creating the issue and not present in the screen when editing it. Cheers, Clarissa.

[Paul Alexander]

Right. I forgot there is a create issue operation (as well as edit and view). Excellent.

[Paul Alexander]

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..."

[cgauterio]

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.

[Paul Alexander]

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.

[Paul Alexander]

Any guidance for me, Clarissa, on my last comment above? Again many thanks.

[cgauterio]

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.

[Paul Alexander]

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)