'Allo. This is in reference to http://trac.edgewall.org/ticket/6135, which I wandered past and peered at and thought it just didn't suit my needs. I've been hacking away and think I found a solution that will, but which is configurable enough to fit into anyones workflow.
Anyhoo, before I reorganize it and clean it up and such, I was gonna explain how I was doing it and see if anyone had a better idea, or saw a problem I didn't :) The enterprise-hook does away with hardcoded commands and relies on these trac.ini settings: [svn-post-commit-hook] command_groups = close, refs, answer close_commands = close, closed, closes, fix, fixed, fixes refs_commands = addresses, re, references, refs, see answer_commands = answers, answer close_actions = test answer_actions = provideinfo What that means is that I have three groups of strings it watches for; close commands and ref commands which are basically like the old hook, and answer. So it'll see 'close #1' and 're ticket:2' and all that jazz. I could add any arbitrary other command if I wanted. The '(group)_actions' options are optional; if present they attempt to integrate the hook with the defined workflow. Refs_actions are blank so after the commit message is added to the ticket, nothing else happens. Answer_actions says to perform the 'provideinfo' action-- so the hook will do so, /if/ that action is available. If the ticket isn't really in the "infoneeded" status and 'provideinfo' isn't one of the actions that can be performed, the hook shrugs and moves on. Of notable importance is that you can provide more then one action, and it'll perform the first one that IS available. So if I have a status "infoneeded", and another "infoneeded_new", and each has its own answer (one called 'provideinfo' to send the ticket to the Assigned status, the other called 'provideinfo_new' to send the ticket to the New status), then I can set the option to: answer_actions = provideinfo, provideinfo_new If the ticket has either of those available, they'll be performed. In my environment, developers don't close tickets-- QA does. So for close_actions, I have it run the 'test' action, which sets the status to in_QA. Now, my question-- does this approach seem useful or reasonable? I was originally just gonna alter it to set configurable status's depending on the command (as opposed to the hard-coded ones the current hook does), but it occurred to me that the point of having a workflow defined is have a particular schedule of events, and if the hooks just overrode this all and jumped around, that's be bad. I'll post code later when I have it generalized and cleaned up, seeking ideas now from the people more aware of what Trac's become since I first threw together that hook. :) --Stephen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
