With the new default work flow, is there easy way to update the default report? Now the ticket with accepted status is not considered active ticket.
Does the trac-admin upgrade handle the change of default report based on workflow? If Active means not closed, then ticket with accepted status should appear in the Active ticket report as well. I am sorry I haven't check if there is any ticket or the latest source have taken this into account. -- Deen On 6/11/07, Eli Carter <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
