Marcos, thanks for adding your vote for this feature.

At the moment, Structure does not have this feature out of the box. It is possible to add it through a third-party plugin and using Structure API and adding a new column, so maybe someone will create one.

At the same time, we're working on Structure 3.0 now, and we'll try to fit in this specific feature into 3.0 or in one of the following releases that should come out faster after 3.0. (The ETA is still not announced.)

Kind regards,
Igor

Hi Igor,
I have the same need. I think that your second way to show the 'rolled up date' like total estimation would work for me. Please, how can I get that ?
Thanks

Marcos

Brian, thanks for your comment. There are two ways we can do this roll-up:

1. Actually change the field of a parent issue when children's field changes. That will require an installation of a synchronizer that would do the change in the background. It's also naturally limited to one structure - if an issue is in two or more structures, you need to decide which to roll up.

2. Do not modify the issue itself, but displayed the "rolled up date" on the Structure grid, like total estimation is displayed right now. This addresses the issues with the 1st approach, but the drawback is that the issue will not have this rolled up value in its field - so the core JIRA functionality or other plugins will not "see" the rolled up value.

Which of these solutions would best suit you?

Thanks,
Igor

I would add that it would be nice if Structure would roll up start/completion dates based on the earliest and latest date specified by any child task. If it already does this, apologies, but I couldn't find it in the docs.

Jeffery, thank you very much for the comment.

I like the idea of "flags", which means that things won't necessarily happen automatically, but will draw attention and will allow the user to act.

The way you suggest to automatically divide the time between sub-issues and calculate due dates based on that implies that the issues are worked on in order (noone starts working on the next issue until previous is finished), with no work done in parallel, and with no dependencies without tasks. I'm not sure how much traction in real world would this calculation make.

Isn't it better, perhaps, just to propagate due date as it is, and leave it up to the user to set due dates for sub-issues (that will also be propagated down), and show the red flag when there's a contradiction?

Or, rather, solve this problem with a Gantt chart with dependencies, resources and stuff - when we have it...

Igor

I suggest the following:

Changing the parent issue should provide an option/check box to push out the due dates of the sub issues based on the estimated time to complete the sub issues (if the estimate exists). It may also be worth having the option to divide the added time based on percentage of time currently needed to complete the issues (if one issue requires 1 day and another issue requires 4 days append 25% of the newly available time to the shorter task and 75% to the longer task). The trick is propagating these changes to tasks further down the tree and those completed in parallel.

Likewise, changing the due date or time estimate of a sub issue such that it will be completed after the due date of the parent should raise a flag indicating the due date won't be met based on that issue (perhaps just highlighting the offending issue and/or tree including that issue). This allows the Project Manager to easily find and mitigate issues manually when possible. Alternatively they should have an option to automatically modify the parent(s) to meet the new timeline if necessary.

I think Haroon keeps in mind auto changing of DueDate for all tasks linked as "Depends on". something like changing of End Date for all related with main task(as it is in the MS Project )
in Jira I think need the folowing:
- if DueDate is updated for task 1 then need update DueDates for all tasks, linked to task 1 as "Depends on"( example: when task 1 "depends on" task xxx, task yyy then need update DueDate in the xxx, task yyy)
- how to update:
-- Dif = new DueDate of task 1 - old DueDate of task 1
-- set DueDate of task xxx = current Duedate of task xxx + Dif
-- set DueDate of task yyy = current Duedate of task yyy + Dif

Thanks for posting this idea. Could you please elaborate a bit, how would this work? What is the relationship between due dates of sub-issues and parent issue? How is estimated time a factor?