On Tue, Dec 17, 2013 at 8:29 AM, Gary Martin <[email protected]>wrote:
> On 17/12/13 15:48, Joachim Dreimann wrote: > >> On 17 December 2013 14:22, Olemis Lang <[email protected]> wrote: >> >> Hi ! >>> >>> Recently I have received user feedback from Bloodhound users and wanted >>> to >>> highlight these points for us to discuss (as usual, my comments inline) : >>> >>> >>> - After ticket creation, if the ticket is automatically assigned >>> (depending on the product), the ticket status is inconsistent. When >>> you enter the ticket url, you can see that the ticket has been >>> assigned to xxxx, but the ticket status is still new. You must >>> manually modify the ticket status and select "reassign to: xxxx" so >>> that the ticket status becomes "assigned". >>> If the ticket is automatically assigned on creation, the ticket status >>> must be changed accordingly without user intervention. >>> >>> From a user experience perspective I don't think "assigned" helpful as >> a >> status (like "new" or "re-opened", I mentioned this before). >> >> A ticket is: >> - re-opened => if it was closed before >> - assigned => if it currently has an owner >> - new => if it was recently created >> - etc >> >> They are properties, not a status. >> > > They each look like a status to me. Obviously a status is a property! > > You could of course state that assigned is closer in meaning to ownership. > We could offer an alternative workflow that defines a better set of ticket > states than the current default. I think we are only constrained in having > new and closed states at the moment. > > > None of these may be true for a ticket, or some, or all of them. I think >> it's a bad decision to have a singular status define one properties to be >> displayed. This problem described by Olemis would not have happened if it >> wasn't the status. >> >> Just throwing it out there in hope other people agree and are willing to >> change this. It's certainly not the easiest solution to this particular >> problem :-) >> > > Yeah, I am fine with improving the possible states and offering those up > by default or whatever if we can basically agree. > > Essentially we seem to be considering better terms for a ticket that has > been given to a user but is pre-work being performed (currently assigned) > and for when a ticket is being worked on (currently accepted seems to be > used for that purpose). I was similarly troubled at one time by new tickets with an owner not being in the assigned state, which led to a small change in Trac. The following threads reference a plugin to address the issue, and some similar opinions on the matter: http://trac.edgewall.org/ticket/8484 https://groups.google.com/forum/#!topic/trac-users/_ndwqwz9MUU https://groups.google.com/forum/#!topic/trac-users/Sih7yxnLH9o I think it would make sense to have the assigned state track with the owner property in the same way that the closed state tracks with the resolution property. However, we'd need to look into the consequences of changing Trac's constraint that all tickets start in the new state.
