Sent from Android On Dec 17, 2013 11:30 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. >
I do not think this is the spirit of the initial request. The subject is not about whether new, assigned, ... are appropriate or not but rather about the fact that once user creates a ticket *if* its owner is automatically set to a given user then status should be assigned > >> 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. > I do not think there is a critical need to change the default workflow since its configurable. I am not against doing so either. We could offer yet another workflow in /contrib though > 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). > +1 [...] -- Regards Olemis - @olemislc Blog-ES : http://simelo-es.blogspot.com Blog-EN : http://simelo-en.blogspot.com Projects : http://blood-hound.net
