My question is perhaps going to sound unusual to many, but I would like to know if there is a documentation about the objects that can be created in Zammad, and their limitations?
Let me explain, we have a system where tickets should be associated to specific references. And those references are hundreds… so the naive idea was to creat a single select tree where they would be sorted by country (for eg.) and let our agents pick the right one.
But I wonder if Zammad is designed to support a select tree that would contain 4 000 items ?
I am kind of intrigued about your use-case. Could you explain more about the nature and purpose of the references and their data-structures? Perhaps give a few specific examples? Would this object/reference be needed on a ticket-based level, or could this also be on a user or organization level? Would it be possible to combine individual attributes (multiple objects) instead of having one huge tree?
I sincerely doubt it would be productive (or effective) for agents to have to scroll through a select tree containing thousands of items though, let alone the possibility of this huge tree causing either performance issues (on default installs), or data-quality issues in the long run (or perhaps both).
No, you would need an ajax based ui element for this, so that you search the items you want to select by individual requests. The current tree select contains all items in the ui. The browser will not be able to handle that amount of elements properly. I guess with that amount of items you would also need some kind of sub search functionality to search in sub trees (countries).
Sure. Let me explain more in details what the strucutre look like (just an illustration):
Let’s say we work with SIM cards, each SIM card has a serial number and is of course associated with an operator, which itself is associated with a country. Tickest are opened in reference to a SIM card (to resolve a problem related to that SIM card)
So the select list would look like this:
SIM Card → Country → Mobile Operator → SIM Serial Number
Other type of objects → Country → Other type of supplier → Object Serial Number
With real data this would look like this:
SIM Cards
→ Germany
→ O2
→ 123456789
→ 123456788
→ T-Mobile
→ 123456787
→ 123456786
We don’t need a seach mechanism, since the way the tree is organised already gives us very quick access to the information we need.
I am thinking these sorts of complex relationships would benefit more from an integration with an external tool, as opposed to extending the Zammad ticket (or customer) objects with such a huge tree.
You might already have a structured database containing the SIM card serials, like a CMDB? Perhaps it would be possible to connect to that tool, either via a simple link templates or something more advanced, similar to the i-doit CMDB integration. It might then be trivial to link a Zammad ticket or a customer to a unique entry (or entries) in the external CMDB tool, which either allows you to quickly view the metadata on the external system, or ideally which pulls and displays relevant metadata concerning the SIM card to the ticket view. You’d “just” need to program the integration, which is probably non-trivial.
This would probably be more responsive in the Zammad UI, easier to maintain, less chance of causing database issues, and more future-proof.
You might want to look into sponsoring Zammad to assist in adding such an integration to be able to support this functionality?
So on the principle Zammad has no issue with such a long list, only the browser would take time to build it for UI?
I have done some tests with +200 items list, and could not see any delay in loading or using in general. Of course this is not 4 000, but I wonder where the limit is?
The limitation technically is not Zammad but your browser.
Every browser reacts differently and one might be “more robust” than the other.
You will not find a fitting answer for your question because it highly depends. If you really have to do what you wanna do without adjustments to the current core you’ll have to fiddle. However, even a developer has warned you with a friendly “you don’t want that”.
