Eli Carter wrote: > On Friday 14 September 2007, Christian Boos wrote: > >> Eli Carter wrote: >> >>> On Tuesday 11 September 2007, Christian Boos wrote: >>> >>> >>>> Hello, >>>> >>>> I'd like to reach a decision for ticket #5572 (Roadmap Progress bar >>>> errors when using custom Workflow). Again a bug report that turned into >>>> a new feature ;-) >>>> .. >>>> A simpler fix would be possible (one group for closed tickets, a second >>>> for all the other states), but as I said above I think it's just at the >>>> appropriate level of complexity, matching the workflow configurability. >>>> >>>> >>> Not only is it possible, but I committed that fix to trunk a while back >>> http://trac.edgewall.org/changeset/5842 (and re-diffed the feature patch >>> afterwards). 2-line change. :) >>> >>> >> Well, sorry that went unnoticed in all this discussion ;-) >> >> >>> I do think the feature is useful. With the new workflow, you could easily >>> have three groups: closed, in-work, and everything else. (As in fact, you >>> have in the workflows/basic-workflow.ini example.) >>> Based on that use case, I agree we need a wildcard capability. >>> >>> >> Yeah, I updated the basic-workflow.ini sample so that it illustrates the >> '*' group. >> >> >>> The r6000 diff still has a reference to '!'. >>> >>> Otherwise, the patch looks ok to me. >>> >>> >> Fixed also the above in r6011. >> > > I'm just now getting to this revision for the testing branch. And in looking > at it from the perspective of adding a testcase, I noticed something I hadn't > before. > > Adding the [milestone-groups] section to the basic-workflow.ini implies that > you wanted the closed/active/new progress bar to be the default. But it > isn't made the default because load_workflow_config_snippet() only loads the > [ticket-workflow] section. > Since the code as it stands passes the regression tests for 5602, I'll merge > r6011 into Testing, but can you clarify your intent on this? >
Ah no, sorry I haven't thought about this, I just wanted to stick an example somewhere. > And for the rest of the devs: Do we want the 3-part progress bar to be the > default? > Well, keeping the old default the way it was before would be OK for me. OTOH, seeing immediately the amount of tickets to be triaged in a milestone (the 'new' and 'reopened' ones) would be good, as those are not "really" part of a schedule, by definition. So I think this change would be good for the basic-workflow (where a 'new' ticket is really a 'new' ticket, not possibly a reassigned one like in the old default workflow). So I'm +1 on loading that together with the [ticket-workflow]. -- Christian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" 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-dev?hl=en -~----------~----~----~----~------~----~------~--~---
