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 If there is no [ticket-workflow] section in trac.ini, the system will default to using the original workflow. This keeps us backward compatible, and leaves the arg^Wdiscussion about what the default workflow should be as a separate step. If there is a [ticket-workflow], it must specify the entire workflow; it doesn't include just a delta/overrides. The reason for this is that it's a lot clearer to have it all spelled out. Otherwise, we wind up unable to eliminate states easily. And contrib/workflow_parser.py can then help you get a graph of the workflow. 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 updated the testcases, and added one for UnknownStateTicketActionController. In the API, apply_ticket_action() should not have any side-effects because it gets called on preview. 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. 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. Thanks, 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 -~----------~----~----~----~------~----~------~--~---
