On Fri, Dec 20, 2013 at 4:14 PM, Ryan Ollos <[email protected]> wrote:
> 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. > This issue has also been discussed in trac:#2045. I think we can probably change the behavior for Trac 1.2 so that tickets with an owner are always in the assigned state. http://trac.edgewall.org/ticket/2045#comment:27
