On Saturday 09 June 2007, Alec Thomas wrote: > > On 6/9/07, Alec Thomas <[EMAIL PROTECTED]> wrote: > > TBH I haven't looked at the workflow yet, but is the implication of > > I've now actually looked at it and I have some comments: > > - When you have accepted a ticket, the "accept" action is still > available...which does nothing. Perhaps, as a general rule, if the target > state of an action is identical to the current state, the action could be > omitted?
This isn't very straight forward to do. There could be side-effects. Or it could be the 'leave' action. Being able to conditionally hide actions has been a common request though. > - It now takes three steps to change the resolution of a ticket instead of > the current two: reopen, accept, close. This is a fairly common action on > edgewall.org, and presumably other public Trac installations where end > users close a ticket with an incorrect resolution. Might be nice to have a > "change resolution" action when closed. As we found in IRC, it's still 2 steps. I'm definitely open to 'change resolution' and/or 'change owner' action(s) for the 'closed' state. Anyone want to chime in on this? > - I'd prefer "disown" or "abandon" to "unaccept". Also, the hint text uses > "unowned" which should be "disowned" if we're being consistent about using > verbs to describe the actions being taken. Done > > Also, I retract my -1 and turn it into a +0 ;). If we require an env-upgrade > and print a notice about the change, users won't be surprised and can apply the > old workflow explicitly if they wish. The concensus I'm seeing is that on upgrade, we should not change the workflow, but we should use basic-workflow for new environments. There are two ways we can implement this. 1) Write the basic-workflow config into the generated .ini on environment creation, and make the 'no workflow specified' case use original-workflow. 2) Make env-upgrade write the original-workflow config into the upgraded .ini, and make the 'no workflow specified' case use basic-workflow. I prefer #2's behavior since it means the original-workflow is relegated to 'legacy' status code wise. It looks like the config upgrade would need to be done in trac/upgrades/db21.py, correct? Pointers on how that should be implemented would be appreciated. Comments? Eli --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
