Modify state to match whatever the workflow says is next when _cmdClose(self, ticket) is called

We handled this by changing what the trac-post-commit script does for the command, or simply by adding a new command that puts stuff into the status desired (EG: 'test #123', rather than 'fix #123'). If you would rather query from the workflow, I'm sure that is possible, but probably overkill (given that you will probably not change the workflow often and changing the post commit manually is easy).

If you want to permanently change the "fix" commands to set into testing mode you could change _cmdClose to set those statuses, or you could add a new command "test" and an associated function to set the correct state.

There is already a ticket to change how this all works anyway, so I dont think that making the existing post commit script more complex is ultimately the correct solution right now.

If you feel that I am wrong and that it would be worthwhile to expand the existing post commit hook to include the requested changes, please post why and I will consider further. I will also accept patches accomplishing the stated goal.

Hope this helps, Russ

Russ, I would try to do the code, but I only know enough Python to shoot my own foot off. I do have a lot of experience with code in general (20+ years), to be able to find the area, but not enough knowledge to change it or the knowledge of the API to be able to query the ticket to know what was next. If this were not the case I would have offer to create the patch -- but, alas, my knowledge is not all encompassing!

I could do what you had suggested (change 'closed' to move to 'testing'), and it would work for my current situation, but anything that would change the work flow in any other repository would negate the use. The other option (creating a _cmd 'testing') could require that people know what was allowed where. (Violation of the KISS principle and giving people a way of really messing things up!)

The idea I was trying to get at is that many organizations have various work flows based on what is being tracked. I personally have 2 repositories for 2 different data sets. Fortunately, both are code and have the testing workflow.

However, I can see where a tool like this may be used for working with something that doesn't contain a 'company standard' workflow. An example would be where a company has three: one for code, one for documentation, and one for marketing materials. Only one of these has the concept of testing. One could be 'Proof reading', and the other could be 'Approval'. By having sub-repositories, and code that is work flow aware, these changes could be independent. The only other option is to have three separate SVN and Trac repositories, with all the additional admin that it would require.

I contract to a large organization that uses RequistPro? to control various work flows and I know of at least 6 that are in use within my immediate knowledge area. My recommendation for the change was to extend the amount of people that could use this plugin with no requirement for local modifications.

You make several good points I had not considered (having to do with multiple trac environments). I will look into this further, but I cannot guarantee that I can come up with a solution.

• What if there was no "resolve" action (or this had been named to some other verb)?

I will look at dynamically handling the 'resolve' action and finding the next state it should go in.

Thank you for your feedback, Russ

Russ,

I didn't know that the "resolve" action name could be changed -- it appears to be something that is on the ticket form as a heading. I haven't seen anywhere that it is modifiable, but I could be very wrong also.

Thank you for re-examining the issue, and if there is anything that I can do or help you with, please feel free to let me know.

Roy

Just FYI: TracWorkflow, every action and state name is customizable as best I can tell

(In [9633]) Make trac-post-commit handle putting tickets into the correct "resolved" state based on configureable workflow. Also added newer better git_post_receive that wont post patches moved from one branch to another a second time. fix #8234

I tested the new trac-post-commit against default (trac12) workflows, my custom workflow and the TestingWorkflow. I think it will work as long as there is a resolve action that changes the status of the ticket.

I hope this helps, Russ Tyndall

PS. If you ever need help on your trac consulting work, my company Acceleration.net has lots of experience, and would be happy to help you out.