Support

That would be an impossibly long list where finding anything is almost impossible. That's why we preferred to implement per-category, per-user and Open status lists instead. What is the use case you have in mind? I am pretty sure that if we discuss what you want to do we can find an easier way than listing all tickets.

Is there a reason why you don't want to do that from the back-end of the site? Creating such a feature in the site's front-end has side-effects in routing which we'd rather not have to work around.

After looking a little bit into this, there is an obvious issue: access control and its performance impact.

By showing tickets per category we only have to do access filtering once. If you have access to the category you can, by definition, see its tickets.

If you need to list all tickets, however, things are more complicated. You can not just show a list of all tickets and simply display a 403 Access Forbidden error when someone clicks on a ticket they are not allowed to view. This could leak confidential information ranging from who filed a ticket in which category and when to privileged information which may be visible in the ticket's title.

Solving this requires fetching a list of all possible categories and seeing if the current user has access to each one of them separately. Based on that we need to create a list of allowed categories and use it to generate the ticket list.

However, even that is not enough. A user may be a manager of Category A but have only public ticket view access on Category B. At best we can sort categories in two groups, full access and limited access. This means that we now need to run two queries to get all tickets and join their results.

Despite the MASSIVE performance impact this is still not a good solution because the tickets are no longer globally sorted modification date descending. First you'd see all the tickets from the full access categories, then you'd see the tickets from the limited access categories. Merging these outputs is not possible. Instead, we'd have to load ALL tickets in memory and use PHP to decide which to show. That works great with a few dozen tickets but when you hit around 1000 tickets you'll run out of PHP memory.

There are two ways to avoid these performance show-stoppers.

One way is to display tickets only from categories the user has Support Staff access, just like we do with Latest Open Tickets. However, this is not what you want (a list of all replied tickets).

Thus we are left with the second option, make this feature available only to users with the global, component-wide Support Staff privilege. However, that's the same as creating a new user group with backend access that has Manage access only for Akeeba Ticket System and no other create/edit/delete privileges. A user in that group would be able to log into the backend and use the backend Tickets page to see exactly what you want.

So, after all, what you want to do would either fail or would be equivalent to giving targeted backend access only to ATS and only for listing information. As a result there is no compelling reason to create a duplicate front-end feature. After all, the people who would have had access to this feature are the same people who have full access to ATS anyway.

So, something like "Latest Open Tickets" but with Pending status instead of Open? We could implement that on the same page by having a status drop-down, default set to Open (but you could set it to Pending to do what you are looking for). Does that sound acceptable?

I've added this feature to the latest development release (rev. E896AEFB). You can download and install it on a copy of your site to see if that covers your needs.

You're welcome!