Tickets and My Tasks

We've received a good amount of feedback from clients that use Tickets that, like Tasks, they'd like to see Tickets they're assigned in My Tasks. Prior to 5.0, we were also receiving a lot of feedback that people wanted Tasks to be threaded like Tickets (with conversations / replies), and others wanted Tickets to show up on the gantt like Tasks. This led us to believe that Tasks and Tickets were very similar.

After releasing activity streams in 5.0, Tasks now have conversation threads, making them a lot more like Tickets. Now we're wondering if we need *both* Tasks and Tickets, or if they're really the same thing--an entity that gets used to track work that needs to be done.

We're leaving this feature request open-ended to hear from clients how they use Tickets if they think Tasks would work as a replacement, or if Tasks are still missing something that prevents them from working like Tickets.

댓글 11개

0

Armando Ricalde
2013년 10월 19일 15:15

We have a trigger that automatically creates a task for every ticket and also keep them synced, assigned person, status, name. And also automatically set the start date of the task to the day the ticket was created, so then it can be just easily dragged to the desired dates. This way people assigned to tickets must do time logging on the corresponding task.

Interesting implementation! Do the Tasks which mirror the Tickets link to the same Ticket, do the two entities exist separately, or are the Tasks linked to something else altogether? What are the advantages you've found of using this workflow? Do you then assign those mirrored Tasks to people so they can see and interact with them in their My Tasks/Inbox, since Tickets are not yet supported?

As you say first, the tasks are linked to the tickets they mirror, this in order to make an easy track of their relationship. We make this because we need to schedule many of our tickets, not all can be solved in the same day are created, and also as you say, with the MyTasks app is easily to arrange and sort the tasks and interact with them.We think tickets as a user problem to be solved ASAP, and tasks more of a long term planning of development in the IT and RnD teams, (off course, tasks also work really good with artists :P)

For me, could be good to have both, but with the same functionality, only to track it different.

Thanks for the additional use cases Hasiel and Tony. Tickets definitely have filled that more technical oriented niche for assigning/tracking work, and as such users have been adding fields to the Ticket entity to help track that work. Combining all the necessary fields that would be needed by different departments onto a single entity definitely could make it more difficult to for both sides to wade through fields which don't pertain to them.

With the addition of the Master Detail mode, one alternative for having a "My Tasks"-like experience with Tickets would be to have a Ticket page set up with filters for Tickets assigned to me (and any other filter conditions to whittle down what you don't want to see). Then just enter Master Detail view. A column of Tickets will be on the left, and clicking each will show its details on the right. See the attached screenshot for an example.

Questions: Are the two "workflows" needed? Is there value in the Ticket workflow that Task does not provide? Why shouldn't a Task behave like a Ticket and vice-versa? Would Ticket related work confuse/clutter the display of Task related work? Would a couple Task Templates and a Task/Ticket Naming convention for Tasks satisfy the need? Maybe an exposed Type field on Tasks that can be set to Ticket or Task?

I would like to see this functionality make it into the product. I re-purposed the tickets into more of a bug flow that I'm used to as a QA Manager but was looking for a way for those tickets to show up under the "My Task" field so that the assignee could see tasks and tickets that are currently assigned to them.

We use Tasks for content + feature development and Tickets for bugs and are in frequent need of prioritizing the two together for each person on the team. Sounds like what we should do is basically follow Mauricio's last sentence: "exposed Type field on Tasks that can be set to Ticket or Task" so that way everything is a Task at the end of the day and both types can be prioritized per developer on the team, at the same time.

Small consideration with that is the status for a task and ticket could be very different. For example.... bugs could have the status "not reproducible" to signify the developer can't reproduce the bug and needs QA to identify better steps to reproduce the result. In a way that's a "kickback" though huh?

Anyone else collapsing Tickets into Tasks that has any advice/suggestions?