How to reference more than two persons in a ticket ?

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.

Hello there.

An additional experiment has been tryed : a multiselect list.

Said list doesn’t lag at all, seemingly no impact on performance even when it has 2800 entries.
From a user standpoint though, the ergonomy is a big no.

Does anyone have an idea about this problem ? It is a big problem for us.

Hi again.

After more investigations, it appears we may have found a solution.

We tryed that :

Reminder that the tree fits ~ 3000 persons.

And it we couldn’t consider it a working solution due to the heavy impact on performance.

However, we tryed to concatenate the SOCIETY/FIRST NAME/NAME part into one long text string in order to erase any notion of parent / child relation.

So like : ZAMMAD | MERKEL | Angela
and each person is a line, no parents, no children, nowhere.

Ergonomicaly, from a user standpoint, you loose the ease of use of browsing through a tree. Browsing through first names to find names may have been overkill however browsing through the societies, that group dozens of persons, was usefull.

From a performance standpoint, a multitree select without any parent and child appears to have very little impact. Almost as little as a multiselect list.

While the user cannot browse through the tree anymore, as the ~ 3000 persons displays all at the same time when you click on the object when you create the ticket, you can still use the search by writing, which was the main point.

This “light” multitree select or a simple text inbox were are last solutions, we don’t see other options. So I guess we will happily set with the light multitree select, although it’s not totaly official yet.