#8234 closed enhancement (fixed)
Modify state to match whatever the workflow says is next when _cmdClose(self, ticket) is called
| Reported by: | Owned by: | Russ Tyndall | |
|---|---|---|---|
| Priority: | normal | Component: | TimingAndEstimationPlugin |
| Severity: | minor | Keywords: | Testing, timing, estimator, workflow |
| Cc: | Trac Release: | 0.11 |
Description
The trac-post-commit.py script always sets the status to 'closed' when the comment includes 'closes', 'closed', 'fixed', etc. When the work flow has been modified in any way to have a step between 'open' and 'closed', such as 'testing', the script continues to set the status to 'closed'.
- Is there a way to query the system to see what the next step is? When the ticket is presented by Trac, there is a description for 'resolve as' stating what the next status will be when it is selected.
- When using the testing workflow, http://trac-hacks.org/wiki/TestingWorkflow, the comment for the 'resolve' is: "The resolution will be set. Next status will be 'testing'". This had to be queried from the workflow system somehow since 'testing' only appears in a configuration file (conf/testing.ini).
- This appears to be applicable to at least 0.11 and 0.12.
Attachments (0)
Change History (7)
comment:1 Changed 14 years ago by
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
comment:2 Changed 14 years ago by
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.
comment:3 Changed 14 years ago by
| Resolution: | worksforme |
|---|---|
| Status: | closed → reopened |
| Type: | defect → enhancement |
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
comment:4 Changed 14 years ago by
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
comment:5 Changed 14 years ago by
Just FYI: TracWorkflow, every action and state name is customizable as best I can tell
comment:6 Changed 14 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
comment:7 Changed 14 years ago by
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.
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