Any ticket not classed as open is classed as closed
Anonymous
Currently it is only possible to define custom ticket states by manually adding them to the status table in the retro database. As such it makes sense that any status other than ‘Open’ is considered closed/resolved as the unconfigurable status values currently available other than ‘Open’ are ‘Fixed’, ‘Duplicate’, ‘WorksForMe’, and ‘Wontfix’. However there is often a need for intermediary ticket states between an open state and a resolved state. For example we have the need for an intermediary ‘InProgress’ state to show that the ticket is being worked on by the allocated individual and should not be listed on the unfiltered ticket list view unless that state is specifically added to the filter. Only when the ticket is actually resolved is the state changed to Implemented or Fixed. Although we can add arbitrary states to the database Retrospectiva will always regard them as closed states and this affects things like milestone completion.
It would be very useful to be able to rename existing states and create new ones using the administration account, and also assign some sort of semantic value to them – even if this is just resolved/unresolved. An intermediary step in this direction would be to add a column to the status table indicating whether the state is resolved or not and modify the various parts of the code which assume not open is closed – ‘All resolved’ in the ticket list view, and calculation of milestone completion
Comments and Changes
- Assigned user set to dim
- Priority changed from Normal to Enhancement
Sounds very reasonable … I’ll see what I can do.
- Assigned user set to dim
- Milestone changed from 1.0 to 1.1
I think that one needs a more general solution. It will be implemented into v1.1.
I like the black and white of “open” and “resolved,” though I agree that it would be nice to define “In Progress” and even nicer to be able to adjust these as settings in the app.
It would be nice to alter the defaults for the ticket listing.
What I did on our install was modify it so ALL tickets are showing by default.
sudara
I like the black and white of “open” and “resolved,” though I agree that it would be nice to define “In Progress” and even nicer to be able to adjust these as settings in the app.
A very flexible solution is going to be integrated in v1.1, including user-definable fields, multiple states and many other features (but still keeping a simple default set).
It would be nice to alter the defaults for the ticket listing.
I’ll think about that, shouldn’t be to hard to implement, but I’d prefer a show a default report solution. Any concerns?
Not from me, that sounds great!
zerohalo
I was just about to modify my Retro version to accept additional non-closed states (which is needed), but I’ll wait for 1.1 instead. Thanks, Dimitrij!
Another advantage of user-defined states: While Retrospectiva is built as a trac system primarily for software development (thus the typical bug-related states), it also can be a nice general project-management system, which is what I’m starting to use it for as well. However, for that purpose, often different states are needed than the defaults.
- Status changed from Open to Fixed
Most of the functionality is implemented in [142]. Enabling the creation of new Status records is the the only thing left to do (will be added soon). I regards this one as resolved.
Feeds