Support

There is a reason why these are different. They are designed for very different use cases.

My tickets: it displays all of the tickets you have filed (owned by you, a user), of any status, ordered with the most recent ticket first. This is how your clients can find their old tickets for reference.

Assigned tickets: it shows you the tickets that are assigned to you, a manager, as long as they are open and ordered with the oldest ticket first. This is your personal to-do list: these tickets are assigned to you and you have to reply to them. The intention if for each support agent to use this as their work queue.

Latest open tickets: it shows you, the manager, all tickets (assigned to you or not) as long as they are open and ordered with the oldest ticket first. This is the global to-do list: these tickets must be replied by the support staff. The intention is to let the supervisor assign tickets to support agents based on their skills OR (in lack of a supervisor) for agents to assign tickets to themselves.

Support category: displays a timeline of tickets in this support category. They are ordered based on the last post's timestamp. The intention is to act as an archive.

As you can understand, there's no point showing the category in the support category (it's right there, at the top of the page, duh) but it is required in Assigned and Latest views to provide context to the support staff.

Likewise, there's no point showing the time since the last reply to non-manager views. It also makes no sense showing the New Ticket button in anything other than the support category view since it would be impossible to predict which category you want to file your ticket in, therefore impossible to implement custom fields.

The only reason we have a title search in My Tickets is because some of our clients with many tickets couldn't figure out that they can simply use CTRL-F on their browser to search their tickets :D

BTW: all headers include title, assigned to and status. The category is displayed only when it makes sense. We did miss the My Tickets page, we'll have to add it there. It makes no sense adding this header in the support category page, though. It's right there, at the top of the page. Why make things slower and cluttered without a reason?

The only real improvements I can see based on our comments are:

• Managers should be able to display the My Tickets page of any users, i.e. a "User X's Tickets" view. This would make sense since most of the times I find myself in the back-end is because I'm trying to figure out what a user means with "as I said in my other ticket...". What other ticket? Since they're ordered based on last reply time and you can search their titles I think you've got all you need to not visit the back-end all the time.
• In fact, I'm thinking that I can link to this "User X's tickets" page from the username displayed under each user (of course the link is visible and possible to visit ONLY if you're a manager, for obvious privacy reasons).
• Show the Category in the My Tickets page. It never occurred to me until you pointed it out.

What do you think?

I don't agree. We can have many tickets in a category and they are not all in the same page. So filtering is basically needed.

I agree with you, that's why there is no search field in the category page. And I'm sure that you think I'm drunk or kidding you. I am not. Please let me explain in detail.

We could implement the search in three different ways which all suck at locating tickets:

• By title. Our experience is that the title and the content of a ticket have little relevance and by no means are adequate to locate a ticket.
• Simple content search (using a LIKE query or MySQL's full text search). The LIKE queries are notoriously slow, especially if you have over 120,000 posts like we do. Displaying the page would take ~30 seconds with huge CPU/memory usage. It's basically acting as a denial of service attack and it can only search for exact phrases. Even with MySQL's full text search which is much faster we still have the problem that it only works with text in proper English and needs too much space to build the index.
• Joomla!'s Search and Smart Search. We've implemented both. Search is a simple LIKE query search with the drawbacks we mentioned. Smart Search uses its own work stemmer which also only works with English. Also, because of the vagaries of J! search, it can only work with public tickets. Both are implemented and you can use them anytime you want (hint, hint)

Then we figured that the answer to our problem was Google. See on our site: we have a custom Google Search box. It is much better at finding (public) tickets than any other search method we can implement.

As for a user's own tickets –which was the context of my reply regarding the search box– yes, they can span multiple pages but I bet they're not more than a few hundred. That's why there's a title search. It stands to reason that one person is intrinsically aware of his/her use of language and can correctly guess the terms they've used when creating their tickets. This makes it easy for them to find their own ticket by title.

And why doesn't this work when someone else is searching for tickets? Because different people will use different terms for the same thing. I say "subscription", some people say "license". I say "component", some people say "module". I say "update" some people say "upgrade". Given in context, they can be interchangeable. Think of the following two titles:
– Can I update the component when my subscription has expired?
– Can I upgrade the module when my license has expired?
For us humans both "feel" the same. For the computer searching for the terms "component", "subscription", "expire" these are entirely different. It will find the former and completely miss the latter. Search engines, on the other hand, use complex machine learning algorithms to figure out the context of the question and whether some words are interchangeable. That's why you can google one term and get back a top result which has none of the words you searched for but does apply to the question you had in mind. This is something we can't possibly reproduce in a component –even if we had the necessary neural network code we'll just never have the required data volume to train it– so we decided to let you use a Google Custom Search instead.