I am trying out the Zammad demo and really like it so far. What I would like to know is, how would one replace the Subqueues coming from OTRS?
I saw that there is the possibility to use tags or even create own attributes like the tree-selection. As we divide our queues a lot, I miss the possibility to have a queue (group) selection beside having the views. According to the documentation, it would be imperformant to have that many views.
Yet the option to write a search string every time seems quite time consuming for me. Let’s say I would like to see every open ticket with the Tag “Mail”, then I would have to search for: tags: mail and state: open
Is there a more comfortable way that is supported to go with this? How have other people coming from OTRS dealt with this problem?
usually a migration is a good time to think about old structures again.
As in terms of: Is this structure really still needed and if so why?
-Personally- I think that on many systems all these sub queues get terribly confusing. They’re just too much.
So one approach most of our customers do take is to reduce their queues (groups).
If they then need to qualify something more specific, they’d either use tags or, more preferably a select or tree select field to do so.
Which object type to use is often a topic of that and what you want to achieve.
You can either search for tags ( tag: tagname) or, if you don’t want to use tags, simply for article types. This will return tickets where the type “email” for any article applies. (article.type: email)
You are right about trying to flatten the structure, yet the lowest level we could go is with a parent node and a child node. We could obviously implement that in Zammad too, using the tags as you already said or even with custom attributes.
However the big problem, which makes it troublesome for me to convince other colleagues, is the search function itself. It is really troublesome, mostly for older colleagues, to write search queries every time.
It doesn’t have to be a queue and subqueue really, but people are used to be able to klick on something that has the role of a parent structure, let’s say “first level support” and then to see the next hierarchy like maybe “accounts” in order to see all the open tickets in front of them that they have to work on. That is basically two klicks for them instead of writing ( tag: accounts ).
Personally I really love the functions of the search function and how Zammad is designed etc. but if you can only have like 20 Views before performance loss it loses a lot of user usability in my eyes. Also the fact that you can not structure views in like a tree structure makes it impossible to use it in a bigger IT-Department.
I can also understand that you guys want to keep a flat structure in Zammad. Maybe a solution could be that a user can save search queries and then trigger a search via klick? Let’s say you add a tab on the left side like “Knowledge Base”. When the user clicks on the menu, it drops down and shows saved search queries that the user can rename. It could be something like “Accounts” that triggers a “tag: accounts” and whatever the user initially searched with).
I hope that you guys understand where I am coming from and would really like to see a solution for this “problem” one day, given that you find enough development capacity.
I can understand that.
The Migrator from OTRS to Zammad will handle sub queues like so: Parent::Child::Child-of-Child
So your original structure isn’t entirely lost!
The hint with the overviews in the documentation is a rough idea of what you could aim.
It’s to ensure that administrators are aware of potential performance issues.
The documentation always expects minimum requirements to be full filled.
So if you throw masses of hardware ressources at your machine (so like really over the top of the actually would need), you could performance tune around and thus eliminate those issues with power.
I’m sure we have fitting feature requests for your idea on this board somewhere. At least it rings a bell when talking about “remember past searches” or something like that. I failed to find it, but well.
I totally get your points.
Sometimes it’s a bit tough especially when you come from e.g. OTRS.
You’ll be missing functions if you used them before.
We’ll see what the future brings and how we can combine it with our desire to keep the UI simple
