On Mon, Dec 30, 2013 at 9:56 AM, Gary Martin <[email protected]>wrote:
> 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 > That is a good point about the potential of constraining the workflow to have an assigned state. I've proposed a different way to solve this issue, which I'm continuing to investigate: http://trac.edgewall.org/ticket/2045#comment:28
