[TIME-301] Ability to aggregate time associated with "is composed of" linked issues in addition to sub-tasks

Issue #301 resolved
Andriy Zhdanov created an issue

Current timesheet plugin reports aggregate time associated with all issue sub-tasks, but it would be extremely useful if we could also include time associated with all "is composed of" linked issues as well - please see discussion in Atlassian Answers: https://answers.atlassian.com/questions/106271/is-there-an-option-to-track-time-across-linked-issues

By rick.waring/Rick Waring on Fri, 16 Nov 2012 02:48:39 -0800

Comments (27)

  1. Andriy Zhdanov reporter

    Added to 2.3.8 for all plugin assets, however it is disabled by default and need to be activated with application properties in home/jira-config.properties, then JIRA must be restarted.

    E.g.:

    jira.timesheet.plugin.composeIssueLink = Compose
    jira.timesheet.plugin.isComposeIssueLinkTransitive = true

    Where composeIssueLink is link name, see screen shot for example. Outward link is used then.

    And isComposeIssueLinkTransitive is false by default, and may be used when e.g. ISSUE-1 'is composed of' ISSUE-2 and ISSUE-2 'is composed of' ISSUE-3, and it is desired that worked time is summed up to ISSUE-1 finally.

    Please let me know how it works.

    Thank you.

    // Committed revision 170033

    By azhdanov on Sun, 18 Nov 2012 03:50:29 -0800

  2. Andriy Zhdanov reporter

    Thanks for the really fast turn-around - we have installed the new version 2.3.8 and are testing now - will report back once our testing has been completed

    By rick.waring on Mon, 19 Nov 2012 07:10:58 -0800

  3. Andriy Zhdanov reporter

    Andrew - after doing some testing - we encountered two unexpected results and just need to be sure we understand our environment. After updating the plugin to v2.3.8, editing jira-config.properties, and restarting JIRA – we ran a test time-sheet report grouped by linked-issues. The total time now seems to include both sub-tasks and linked-issues as we expected, but did not seem to total in the "RoadMap Item" as we expected. I will attach a couple of screenshots showing our "linked-issues" configuration page we used as a reference for editing the jira-config.properties, and the resulting report.
    The second unexpected result was the "field not set" entry under the "linked-issues" column - we didn't know if that was by design, or if it indicated another problem.

    Can you take a quick look and let us know if we missed something? Thanks!

    By rick.waring on Tue, 20 Nov 2012 01:13:25 -0800

  4. Andriy Zhdanov reporter

    These show our "linked-issues" config screens - we edited our jira-config.properties using these lines:
    jira.timesheet.plugin.composeIssueLink = Aggregate
    jira.timesheet.plugin.isComposeIssueLinkTransitive = true

    By rick.waring on Tue, 20 Nov 2012 01:20:30 -0800

  5. Andriy Zhdanov reporter

    And this is the time-sheet report we generated – the times reported are correct, and the total for the report seems correct, except we expected them to be rolled-up into the roadmap item - did we miss something? Thanks!

    By rick.waring on Tue, 20 Nov 2012 01:23:37 -0800

  6. Andriy Zhdanov reporter

    Hi Rick,

    Looks like I confused you with previous screen shot using 'Group By' option. Please set 'Sum SubTasks' report configuration option instead.

    Thanks.

    By azhdanov on Tue, 20 Nov 2012 11:05:03 -0800

  7. Andriy Zhdanov reporter

    I thought that we did select the "sum sub-task option - here is the report config we used, and the results.. maybe we did miss something else.. thanks

    By rick.waring on Tue, 20 Nov 2012 12:50:34 -0800

  8. Andriy Zhdanov reporter

    Just a thought - it may be that we are just looking in the wrong place for our totals – the "total" shown at the bottom of that group did seem to have the right number, my user was just expecting it to be aggregated in the "roadmap item 1" line – should we just look for the "linked-by issues" group total to be at the bottom of each group? We may just need to learn how to read the report -

    By rick.waring on Tue, 20 Nov 2012 13:00:17 -0800

  9. Andriy Zhdanov reporter

    After further review and testing - it seems that we now understand the report better, and all our issues are now resolved (we had selected the "show details" option and it generated more details than we expected - without that option selected, the reports now seem to be what we need) - thank you! sorry for the confusion on our part -

    By rick.waring on Mon, 26 Nov 2012 02:28:36 -0800

  10. Andriy Zhdanov reporter

    Hi Rick,

    Great, and thank you for your efforts on making sense of the report! Note, 'Group by field' is useless for Issue Links. And yes, details report may be confusing, it shows all worklog entries.

    By azhdanov on Mon, 26 Nov 2012 05:58:57 -0800

  11. Andriy Zhdanov reporter

    Just one last question – more of a cosmetic request than anything – but we need to report over a 3-month period instead of the new default 2-month maximum - I found your notes on editing the maxDays property - and that works very well, thank you - but often my users manage to enter a time-frame more than 90 days, generating an alert "The "End Date" must not be later than 2 months." – Is there any way to change the text on the alert to either reflect the current maxDays setting, or even just a way for me to manually edit the text? Not critical or anything, with the right time-frame - the new patch works very well - just would help reduce user-confusion.. thanks!

    By rick.waring on Wed, 28 Nov 2012 03:38:25 -0800

  12. Andriy Zhdanov reporter

    Hi Rick,

    Oh, thank you for catching it, just fixed it also, please reinstall 2.3.8 if needed.

    Thank you.

    By azhdanov on Thu, 29 Nov 2012 01:22:21 -0800

  13. Luca Cito

    Hi Andriy,

    What if we want to choose between following the inward or the outward link?

    Cheers, Luca

  14. Luca Cito

    Thank you for your swift response! I was kind of surprised since JIRA itself also offers both directions when linking issues, so I thought implementing it that way would be trivial. Is there an underlying technical reason or might this be a possible improvement for a future version?

    Cheers, Luca

  15. Andriy Zhdanov reporter

    Hi Luca,

    It looks redundant to me. You may have some historical reasons by using inverted direction of some link that would mean child-of, but I can't come to some common case. Could you please describe your use case?

    Thank you.

  16. Luca Cito

    Hi Andriy,

    You guessed pretty much correctly. The way our JIRA is set up, we keep the parent tasks in project A. We might have sub-tasks of such a parent tasks which stand for analysis, requirements, etc. For the actual implementation although (for historical reasons and also in order to circumvent the sub-task depth limit) we create tasks in project B and connect them to the parent task of project A via a "is gathered by" link. When I create a timesheet and configure it so that the link is followed, I'd like to get the following:

    A1 (CR 432)
    |- A2 (subtask of A1, e.g. for analysis)
    |- B1 (implementation task, "is gathered by" A1)
    

    But since I can only configure "Gather" as the link type to be followed, I get this:

    A1
    |- A2
    B1
    |- A1
    

    I know our setup is a little unorthodox, but otherwise we would have to "turn around" and rename the link for thousands of issues.

    Thanks for your help!

    Luca

  17. Andriy Zhdanov reporter

    Well, I think, it would be better to fix 'unorthodox' then evolve it, though there are no technical reasons of not supporting it. Would you prefer to wait for such improvement for a month?

  18. Luca Cito

    While I agree with you, it mostly has to do with the way we interface with our clients' processes and we can't easily change that :) flexibility is one of the strengths of JIRA, after all.

    It would be great if such an improvement would show up in the next release! Big fan of your plugin.

    Cheers, Luca

  19. Log in to comment