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. ;-) -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
