Ticket attribute propagation

[Chris Nelson]

When thinking about subtasks, one of the issues that comes up is propagating changes from child to parent. If you use subtasks with Time and Estimation, you likely want a parent task's estimate to be the sum of it's children's estimates. If you assign Start or Finish dates to children, you likely want the parent to start when the earlieast child starts and finish when the latest child ends.

I'm considering writing a generic ticket attribute propagation plugin. This would implement a configurable Ticket Change listener capabale of doing the updates described above. Configuration might look like:

[attribute_propagate]
parent.fields=start, finish, estimate, work
parent.start.method=min
parent.finish.method=max
parent.estimate.method=sum
parent.work.method=sum

Which means: when a ticket changes, if the parent field is not empty, use it to find another ticket and update its start, finish, estimate, and work fields. Start is updated as the minimum of the current ticket's start and the other ticket's start. Finish as a max. The other ticket's estimate would be it's value minus the current ticket's old value plus the current ticket's new value. I hope you get the idea.

This doesn't seem too complex and I'm ready to dig in but if there's a plugin that does something like this already, I'd rather same the time. Any thoughts?

Chris
--
Christopher Nelson, Software Engineering Manager
SIXNET - Solutions for Your Industrial Networking Challenges
331 Ushers Road, Ballston Lake, NY  12019
Tel: +1.518.877.5173, Fax: +1.518.877.8346 www.sixnet.com

[Ethan Jucovy]

I don't know of a plugin that does this but it sounds very useful, I'm looking forward to seeing it.

How would propagation "parentness" be determined?  Would you look directly to the MasterTicket fields or rely on some kind of interface?  I've only skimmed the recent threads on subtasks, sorry if this has already been discussed on one of them.

In the TimingAndEstimation case, and presumably others, propagation could lead to misleading reports -- e.g. doubling the estimated time for a set of tickets by counting the fields twice.  Solving that automatically and in a generic way seems hard.  The user can probably deal with that (and I bet a sufficiently clever SQL report could account for it).

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To post to this group, send email to trac-...@googlegroups.com.
To unsubscribe from this group, send email to trac-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.

[Chris Nelson]

Ethan Jucovy wrote:
> I don't know of a plugin that does this but it sounds very useful,
> I'm looking forward to seeing it.
>
> How would propagation "parentness" be determined? Would you look
> directly to the MasterTicket fields or rely on some kind of
> interface? I've only skimmed the recent threads on subtasks, sorry
> if this has already been discussed on one of them.

As I developed the concept, I realized this might apply to
MasterTickets, too. My plan was to have a list of ticket "link" fields
(e.g., parents for Subtickets or parent for ChildTickets, blockedby for
Master Tickets, etc.) so you could configure what fields to look at.
The plugin would do something like:

get ticket's dependent (parent, predecessor, successor, etc.)
if dependent != None:
for field in rollup.fields:
if current's old value and new value differ:
get dependent's value for field
switch rollup.%s.method % field:
case 'min':
if dependent's value > current's new value:
set dependent's value to current's new value
case 'max':
if dependent's value < current's new value:
set dependent's value to current's new value
case 'sum':
dependent's value = dependent's value -
current's old value +
current's new value

> In the TimingAndEstimation case, and presumably others, propagation
> could lead to misleading reports -- e.g. doubling the estimated time
> for a set of tickets by counting the fields twice. Solving that
> automatically and in a generic way seems hard. The user can probably
> deal with that (and I bet a sufficiently clever SQL report could
> account for it).

I'm not sure how that's going to work. One answer would be to only
query leaf nodes for that kind of report. OTOH, if you're looking at a
top-level ticket, the values were already rolled up so you can just look
at it and no report is needed.

[Ethan Jucovy]

I think that 'sum' algorithm will break for the case where the dependency is added at the same time that the field value changes.  (e.g. in the same action, ticket #10 is made a child of ticket #15 and its estimation is changed from 4h to 2h)

As I'm thinking about it, some other potential uses occur to me that I've sometimes wanted -- closing child tasks when I close the parent ticket; making the parent ticket's priority or severity the max of the child tickets'; bubbling keywords across related tickets.  I think some of those could be covered by min/max/sum, but not sure they'd all be handled.  You might want to end up with two pluggable interfaces, one for defining link types and another for defining rollup methods.  Then other plugins could be built to extend it with custom propagation methods and/or to interface with other ticket-relationship-defining systems.  (I like when Trac plugins are pluggable.)

> In the TimingAndEstimation case, and presumably others, propagation

> could lead to misleading reports -- e.g. doubling the estimated time
> for a set of tickets by counting the fields twice.  Solving that
> automatically and in a generic way seems hard.  The user can probably
> deal with that (and I bet a sufficiently clever SQL report could
> account for it).

I'm not sure how that's going to work.  One answer would be to only
query leaf nodes for that kind of report.  

 

OTOH, if you're looking at a
top-level ticket, the values were already rolled up so you can just look
at it and no report is needed.

Good point.  And if you want to collect more than one ticket, you can just build a report that includes only top-level tickets.  For more free-form relationship graphs like MasterTickets' that might not have any meaning .. but it's also less clear what sort of reports you'd want to do, there.  So it is probably worthwhile to be lazy about the reporting question and see what sorts of needs come up when the system's put in use.

Anyway, enough backseat driving from me.  Thanks again for thinking about this, it could be a very useful system.  Let me know if you put the code somewhere collaboratable like trac-hacks or github - like everybody else on this list, I don't have a lot of free time, but I'd be happy to help out with this if I can.

[Chris Nelson]

Ethan Jucovy wrote:
> ...

> I think that 'sum' algorithm will break for the case where the
> dependency is added at the same time that the field value changes.
> (e.g. in the same action, ticket #10 is made a child of ticket #15
> and its estimation is changed from 4h to 2h)

I think you're right. What it should do is:

subtract current's old value from old dependant's value then add
current's new value to new dependant's value. If the dependant (e.g.,
parent) didn't change, this reduces to the calcuation I illustrated.

> As I'm thinking about it, some other potential uses occur to me that
> I've sometimes wanted -- closing child tasks when I close the parent
> ticket;

Which would be some operation to propagate the status field.

> making the parent ticket's priority or severity the max of
> the child tickets';

Actually, I think that's wrong. I have a long analysis of how to
propagate priority but it's wiki formatted and hard to post here.

> bubbling keywords across related tickets.

I can see that.

> I think some of those could be covered by min/max/sum, but not sure
> they'd all be handled. You might want to end up with two pluggable
> interfaces, one for defining link types and another for defining
> rollup methods. Then other plugins could be built to extend it with
> custom propagation methods and/or to interface with other
> ticket-relationship-defining systems. (I like when Trac plugins are
> pluggable.)

That'd be awesome. I'm not sure I'm that smart. ;-)