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