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).
- <note>using quick create ticket shortcut</note> Besides the automatic
assignment function... It would be good to be
able to assign the ticket to any user (working in the project) from
the creation window itself.
For example: The case when you have 3 people working on the same
product and you want to assign the ticket to any one of them. Right
now, the automatic assignment would always assign the ticket to the
same owner and then the user would have to manually change the owner
to the desired person.
My initial design for the quick ticket box showed optional fields to be
added (link-style starting with a +):
https://redpen.io/a8ytcn
Maybe something similar should be considered again, but instead a generic
+Add new field, which would be a dropdown of potential fields to be set,
such as who the Owner.
- When writing a user name to assign a ticket (or whatever)... Like in
Modify Ticket --> Reassign To. It would be good to have some help like
a user list displayed as we type. Currently there is no help, so I
must know the user name and type it (hopefully) without errors.
A dynamic list that displays the user names as we type and allows to
select a user name from the list (actually this should probably be a
constraint) would improve the usability and prevent typing errors and
assigning the ticket to the wrong owner.
Also this list should be filtered so only the users working in the
product would show
Makes sense.
- Joe
<note>
we have developed a plugin for the feature above , see
https://github.com/olemis/trac-mentions
</note>
- There is no easy way to see the tickets that I create as a reporter.
They do not show in the dashboard. The feature of showing only the
last created ticket in the creation window is a bit obscure (I need to
click "Create Ticket" to find out which is the last created ticket)
not to mention lacking because if I had created 5 tickets, only the
url of the last one would show here. For the other ones, there is no
easy way to access their url.
Ideally for me the tickets that I report, would show in my dashboard.
This way I could easily see the list by clicking "Dashboard'. Right
now the alternative is to use a report (not always can find the right
one). In practice I end-up creating a custom query just to see the
newly created tickets, which is a tedious task (click Custom query,
configure it, add/remove query parameters, select Status=new, type my
own name as reporter)
<note>I see this feature deployed at i.a.o/bh/report/7 , maybe we should
just distribute that query in default BH installation ?</note>
--
Regards,
Olemis - @olemislc
Cheers,
Gary
