Infos:
- Used Zammad version: 6.3.1-1718620481.9d65e987.centos8
- Used Zammad installation type: package
- Operating system: Rocky Linux 8
- Browser + version: Firefox 115.6.0esr (64 bits)
Zammad is hosted on a VM with the following hardware :
- 4 VCPUs (~2Ghz) (Intel)
- ~ 8 GB RAM
- 25 GB of total storage capacity (38% usage)
Summary of the need :
We use Zammad internaly to our business to trace real persons’ access to physical locations.
The classic scheme is one coworker (customer in Zammad) creates a ticket to another coworker of a different team (agent in Zammad) to punctualy authorize several others persons (technicians, mostly) to access to certain parts of a building on defined date and hours. There is a strong need for security and reliability.
This is a simplified summary.
In terms of scale, we have about 200 “customers”, coworkers who create tickets.
Theses tickets are destined to an handfull of about 20 “agents”, other coworkers who accompany and authorize access to technicians inside our buildings.
And we have around 3000 “technicians”. Persons who punctualy access our buildings and who needs their access traced and archived.
With approximatly 27 additionnal objects and 40 core workflows (all for tickets), Zammad has been largely modified to suit our needs.
There is still however an unsolved issue regarding the technicians.
We need to be able to reliably trace who access where, and when.
What we tried or though of to handle thoses 3000 “technicians” (from most to less original) :
- Creating a clone of the Client field
Via API, we tryed to create a field just like the client, but named “Technician”.
The object type was user_autocompletion
With slight modifications such as “multiple”: true so that said field can take several persons.
Pros : It’s based on the Users table and work like a charm when you create a new ticket.
Con : The object doesn’t appear on existing tickets. Invisible, basicaly.
It was fairly obvious that it wouldn’t work. The documentation and Zammad itself made pretty clear that user_autocompletion was NOT meant to be used via this API trick. Still tryed it for science.
- Making a list of technicians as a multi_tree_select
Through a bit of Python scripting, we managed to turn a ~ 3000 lines of technicians from a database export in csv into a usable json payload.
The tree and parent / child relation is built as : SOCIETY/FIRST NAME/NAME
Exemple :
ZAMMAD::MERKEL::Angela
Pros : It works. The quick search allow to find existing technicians.
Cons : Zammad lags very much.
To try and measure the impact of the multi_tree_select on the response time, I did the following test :
I had 10 existing tickets openned on the left side of the sreen aswell as one advanced search and a new ticket that I didn’t finish creating.
I would then refresh Zammad’s page and start a timer.
The timer stops when all of the openned tickets on the left finish loading.
The timer was my phone, so the result are approximate. Also, there are ~ 90 tickets existing on Zammad at the time of the test.
Also, I was the only person actively using Zammad during the test. No other user was doing anything.
The results can be seen in the chart below.
| Nomber of persons | Time to load (seconds) |
|---|---|
| 0 (Object not created) | 7,5 |
| 500 | 10 |
| 1000 | 16,5 |
| 1500 | 21 |
| 2000 | 25 |
| 2500 | 29 |
| 2837 | 34 |
As you can see, thoses numbers aren’t good.
On top of that, after the long initial loading time, core workflows in tickets are noticeably slower. And the overall experience is not smooth.
- Using an external data field
For another need, we already use an external data field to fetch an entity in a database of more than 10 000 entries. It works very well and we’re happy about it.
The problem that denies us from using that solution for technicians is the fact that external data field can only choose or select one entry. While we need to select one or more.
Pro : Would be technicaly amazing
Con : Can’t select more than one entry
- Plain Text in a textarea
That’s the last of the backup plans. Instead of having a list of persons saved in Users or anywhere else, we get our “customers” to write the “technicians” names directly as text.
Pros : It works
Cons : Very poor ergonomics, easy to make mistakes
It would be difficult and painfull to make usable report charts and know who access where and when, as a typing error on the name can mess the search.
Technical assistance may not be the best place to ask for this particular issue, and I may not have done a great job at explaining my issue, but thanks to anyone and everyone who helps with this problem.