On 30 December 2013 00:11, Ryan Ollos <[email protected]> wrote:
> 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:2<http://trac.edgewall.org/ticket/2045#comment:27> So this looks like you want to make it so that the ticket can start either as new or as assigned as the original message suggests. This is probably OK as long as we also keep note that 'assigned' is not a state that a workflow has to define. As such we cannot predict the status that a user will want to go directly to and that either means that it only works when that status is available or we allow the initial-state-if-owned to be configurable (perhaps defaulting to new if the specified state does not exist.) Cheers, Gary
