Christopher Lenz wrote: > Am 11.09.2007 um 17:50 schrieb Christian Boos: > >> Christopher Lenz wrote: >> >>> Am 11.09.2007 um 10:25 schrieb Christian Boos: >>> >>>> 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 ;-) >>>> >>> [snip] >>> >>>> Opinions? >>>> >>> I agree with you in general, but maybe we can still simplify the >>> change a bit. >>> >>> Specifically, do we really need the wildcard and negation support for >>> specifying the list of statuses? People won't have 50 different >>> statuses (and if they do, they deserve some punishment ;) ), and you >>> really don't need to go in and edit the grouping configuration all >>> the time. So I think that using just a plain list of status names >>> would be sufficient, and simplify the code (and documentation). That >>> would also remove the reliance on the order of the options if I'm not >>> mistaken. >>> >> Negation support was there for being able to specify things like >> "anything but closed". >> A wildcard is useful for specifying a catch-all group, useful when you >> upgraded the workflow a few times and you are unsure about what are >> the >> remaining states. >> However the first use case could probably be subsumed by the second >> and >> we'd only need one catch-all group after all. >> So yes, I think the patch can be simplified further in this area. >> The .order is still needed I think, in order to have control over the >> sequence of the groups within the progress bar. >> > > Hmm, I'm not sure whether you understood me correctly here ;) >
Nah, I understood correctly but perhaps expressed myself not clearly enough: the only use case I'd like to support is one catch-all group, which I find quite useful in order to not "loose" a ticket when its state is not specified in any group. That could happen even if we're checking that all the _currently known_ states are all defined in groups (i.e. when remaining_statuses is empty), because it can happen that tickets are left in some obsolete state after a workflow upgrade (see e.g. #5531, #5307). Not having a catch-all group would make those tickets disappear from the milestone view and producing an error here is not pretty, as it can be detected only late by the user viewing a particular milestone and not by the admin doing a simple check of the roadmap. Or, at the very least this would require a global consistency check like the solution suggested in #5307. > Another question: is it possible to set the "label" of the milestone > groups through this configuration? I.e. the "Active tickets" and > "Completed tickets" strings? If not, what is going to get displayed? > No it's currently simply the group name (capitalized through CSS). -- 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 -~----------~----~----~----~------~----~------~--~---
