Hello All, Just made a quick setup and testing of the proposed workflow branch, r5109 (especially, in comparison with the old http://trac.edgewall.org/wiki/NewWorkflow proposal for Trac 0.8, which we are using still).
The idea/implementation looks very good (thanks, Eli and others!). Comments after testing: - The 'set_resolution' action does not set the resolution to 'fixed' by default. Actually, when resolution is empty in a ticket, the render_ticket_action_control() in api.py sets every option in the resolution combo box as "selected". Basically, I vote for inclusion of the workflow branch in 0.11 since it is one of the important and constantly required features in Trac IMHO. Note: The following workflow setup has been used (traditional and simple develop-test-integrate cycle): ===== [ticket-workflow] ; qarmt-workflow.ini leave = * -> * leave.operations = leave_status leave.permissions = TICKET_MODIFY leave.default = 195 reassign = new,resolved,verified,reopened -> * reassign.name = reassign to reassign.operations = set_owner reassign.permissions = TICKET_MODIFY reassign.default = 185 ; positive flows accept = new,reopened -> accepted accept.name = accept ticket accept.operations = set_owner_to_self accept.permissions = TICKET_MODIFY accept.default = 190 resolve = new,accepted,reopened -> resolved resolve.name = resolve as resolve.operations = set_resolution resolve.permissions = TICKET_MODIFY resolve.default = 180 verify = resolved -> verified verify.name = verify ticket verify.permissions = TICKET_MODIFY verify.default = 170 close = verified -> closed close.name = close ticket close.permissions = TICKET_MODIFY close.default = 160 ; negative flows unaccept = accepted -> new unaccept.name = unaccept to unaccept.operations = set_owner unaccept.permissions = TICKET_MODIFY unaccept.default = 90 reopen = resolved,verified,closed -> reopened reopen.name = reopen ticket reopen.operations = del_resolution reopen.permissions = TICKET_MODIFY reopen.default = 80 retest = verified,closed -> resolved retest.name = retest ticket retest.permissions = TICKET_MODIFY retest.default = 70 ===== Regards, Pavel On Mar 16, 1:08 am, Eli Carter <[EMAIL PROTECTED]> wrote: > On Wednesday 14 March 2007, Eli Carter wrote: > > > > > All, > > > Ok, I'd like to get some code review and testing of the workflow branch. > > > There are currently 5, count them, 5 example workflows in the contrib > > directory: > > original - Implements what Trac has historically had for workflow > > trivial - open, closed > > simple - new, accepted, closed > > opensource - geared to distributed volunteer projects > > enterprise - geared to paid developers with QA > > Make that 6. There's a enterprise-review-workflow.ini to go with the > CodeReview.py plugin. This plugin implements a simplistic code review > step -- you can't review your own ticket, and you have to have permission to > review tickets. > > > > > There is also the UnknownStateTicketActionController workflow component. > This > > provides TICKET_ADMIN users with the ability to force a ticket to any state > > whatsoever. As a separate component, it can be disabled separately > > with "trac.ticket.api.UnknownStateTicketActionController = disabled". > > I've moved this out into its own plugin, "StatusFixer", with a corresponding > TICKET_STATUSFIX permission. It's in sample-plugins. > > > I updated the testcases, and added one for > > UnknownStateTicketActionController. > > And it's gone again since it's now in a plugin. > > > > > In the API, apply_ticket_action() should not have any side-effects because > it > > gets called on preview. > > Alec pointed out that this needed a better name; so apply_ticket_action is now > get_ticket_changes. > > > > > Side effects would need to be implemented in a > > ticket change listener, and key off a status change. That approach would > > allow for sending email, triggering builds, etc. You're also not limited to > > how many listeners trigger on a status transition. > > As a demonstration of this idea, I added DeleteTicket.py to sample-plugins. > > One of the interesting things here is that you could setup a workflow that > > included a delete status after a deletion_review status. > > > I believe the configurable DefaultTicketActionController will cover 90% of > the > > workflows people will need. For more nuanced workflows, a plugin that > > replaces it would be needed. > > With the ability to stack the workflows, having to completely replace it > becomes less likely. > > > > > Current warts: > > - restrict_owner handling duplicates the user listing logic stuff. Compare > > DefaultTicketActionController.render_ticket_action_control vs > > TicketSystem.get_ticket_fields. Pointers welcome. > > - there are no provisions for adding to the list of supported operations > short > > of modifying DefaultTicketActionController.apply_ticket_action() > > - it needs more testing > > > I'm thinking that once the restrict_owner stuff is addressed, this would be > a > > candidate for merging. I'd like feedback on this. > > Based on feedback from Alec, I eliminated field.py. (Correctly, this time.) > > I cleaned up the html, in particular the use of id= and <label for="... > (Thanks cboos) > > I changed the syntax for the .ini. We now support things like this: > > my_action = new,needinfo -> active > my_action.name = do something > > leave = * -> * > leave.operations = leave_status > > force_to_new = * -> new > force_to_new.name = force to new > force_to_new.permissions = TICKET_ADMIN > > API changes: > - I removed the vestigial intercept_ticket_action method. > - get_ticket_actions now returns an ordering weight for each action so actions > can be ordered across plugins > > I also fixed up the support for multiple operations on an action, so you can > actually create an action that sets the owner and the resolution. > (Known bug: if two actions want to set the owner, the first one wins... either > don't do that, or give suggestions. :) ) I believe this should work if more > than one plugin adds a control to a given action... but I haven't tested > that. > > Ok, feedback welcome! > > 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 -~----------~----~----~----~------~----~------~--~---
