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 -~----------~----~----~----~------~----~------~--~---
