Status-Based Grouping in "All Tickets" for Department and Analyst Views

[dschipfel]

The status grouping that is currently available within departments works very well and provides a clear overview of open work.

A useful enhancement would be to make this functionality available directly in the "All Tickets" view, both in the Department and Analyst sections.

Current situation

When opening All Tickets, all tickets are displayed in a single list. This becomes increasingly difficult to manage as ticket volume grows, since agents cannot immediately see how many tickets are:

• Open
• In Progress
• In Analysis
• Waiting for Vendor
• Waiting for Business Department
• Planned
• Paused
• Closed

Suggested solution

Allow the All Tickets folder to be expanded in the same way as departments are today.

Example:

All Tickets (125)
├─ Open (32)
├─ In Progress (41)
├─ In Analysis (8)
├─ Waiting for Vendor (12)
├─ Waiting for Business Department (18)
├─ Planned (6)
├─ Paused (3)
└─ Closed (5)

The same functionality could also be available under the Analyst view:

Analyst
└─ All Tickets
├─ Open
├─ In Progress
├─ Waiting for Customer
└─ ...

Benefits

• Faster prioritization of work
• Better overview of ticket distribution
• Reduced need for manual filtering
• Consistent navigation experience across the entire ticket inbox
• Particularly helpful for teams with larger ticket volumes

Since status grouping already exists within individual departments, extending the same concept to All Tickets would provide a much clearer high-level overview while keeping the user experience consistent throughout the application.

[edmozley]

Hi @dschipfel

The structure you sketched is now all built.

This is on main now. All Tickets expands like any other folder, with a count per status:

All Tickets (97)
  Open (70)
  In Progress (6)
  On Hold (5)
  Awaiting Response (7)
  Closed (4)
  Resolved (5)

Clicking a status shows just those tickets, across every department and every analyst at once. It works the same whether you have the folder list grouped by department or by analyst, since All Tickets sits above both.

Unassigned got the same treatment, which was not in your request but is the obvious neighbour - it is often the fullest folder on the desk, and "60 unassigned" tells you far less than "57 of them still open, 3 closed".

That one had a wrinkle worth mentioning, because it may not be obvious on your install. What "Unassigned" means depends on how you have the list grouped: with Department grouping it means no department has been set, and with Analyst grouping it means nobody is working on it. Those are genuinely different sets of tickets - one can be filed to a team and still be nobody's job - so the folder shows a different breakdown in each mode rather than one number pretending to answer both questions. On my test install that is 60 versus 53.

A few other deliberate details:

• Clicking a folder still shows that folder. Expanding is additive, so opening the tree never changes what you are looking at.
• The statuses are your statuses, in your configured display order, so an install using "In Analysis" and "Waiting for Vendor" gets exactly those. A status with nothing in it is greyed rather than hidden, so the pane does not change shape as you work.
• You can drag a ticket onto a status to set it. Under All Tickets that sets the status and deliberately nothing else; under Unassigned it unassigns the ticket and sets the status in one move.
• The children add up to the parent, and the count on a folder now matches the list it opens exactly - see below.

There are two write-ups if they are useful:

• The folder pane - how the whole left-hand panel works, including the grouping toggle and what dragging onto each kind of row does
• The folder pane - Developer Guide - the internals, if you ever want to add a folder type of your own

The pleasant surprise was that All Tickets needed no new database work: the per-status totals were already being calculated and sent to the browser on every refresh, and simply had nothing rendering them.

Two bugs turned up while building it, and both are fixed.

The first was a race: clicking two folders quickly started two requests for the ticket list, and whichever the server answered last won - so you could end up looking at the wrong list with the right folder highlighted. It corrected itself on the next click, which is why nobody had reported it.

The second is the more interesting one, and putting counts next to each status is what exposed it. A folder could show a number the list underneath did not match, and the missing tickets could not be reached by any route at all. It turned out to be two unrelated causes: tickets that had been merged away were still being counted, and the ticket list was built starting from email messages rather than from tickets - so a ticket with no email against it was counted in every folder, listed in none, and impossible to open even if you knew its number. Both are fixed, and every folder count now matches the list it opens.

That one has its own write-up if you like this sort of thing: The folder said 99 and the list showed 96.

If the grouping does not behave the way you expect on your install, or you would like the tree to remember what you had expanded between visits, say so and I will take another look.