New Object Manager Attribute Type "JavaScript"

Feature requests
1

When talking about generic approaches for integration Zammad with external systems (e.g. Asset Management, DMS, etc.) it would be great to have a generic approach beyond the REST API. To enable the Community for contributing and conceptioning new integrations, a generic attribute type “JAVA Script” could be a game changer.

Example:
When trying to implement a CMDB database solution in Zammad, the current product capabilities only offer limited integration depth by using the object attribute format “external data source” and for content syncronizations there is only Webhook/API or Email available. CMDB databases usually have a quite generic solution and database design but the process details in combination of CMDB and Zammad often have the requirements of:

  • Enabling search and assignment functionalities beond “user<->asset”
  • Enabling change process logics and ticket<->CMDB synchronisations

For this pupose the solution could be:

  • providing a dedicated “JAVA Script” (text input field), that simply execute/submit the entered code on foreseen destination to modify the screen/results delivered in the UI in Zammad

This general approach may have positive sideeffects in the Community, where all “integration codes” can be published and shared easily the the community contribution is enhances. Thinking this to an end, Zammad could generate a public library of easy custom integrations to 3rd party solution.

Possible benefits:
The CMDB database integration in Zammad in the logics/designs of the “idoit” integration can be easily adapted and re-used for all other CMDB databases (Snipe IT, Baramundi, etc) by simply utilizing the “external database” and “Java Script” attribute formats in individual combinations.

OS: any
Size of implementation: any
Use Cases: any
verticals: any

2

Would be nice to explain much more about the different problems that need to be solved for this kind of integration, because before someone can talk about any solution, the different situations need to be clear.

3

I‘d personally prefer better Package support with easier entry to extend Zammad. If you‘re coding JS, then you‘re fairily deep already.

4

The idea comes from a similar feature in i‑doit. There one has the possibility to define so-called custom categories which are roughly similar to user-defined objects in Zammad. If a custom category with a field of the type JavaScript is added and assigned to a specific asset class (object type in i‑doit terminology), the code gets embedded into the DOM when such an asset is viewed.

Here is a screenshot that shows how information from Zammad can be queried, displayed, and linked with such a custom category.

ScreenshotZammadExternalData
ScreenshotZammadExternalData1523×566 98.2 KB

In Zammad, such an embedded JavaScript code could add a button to tickets that, when clicked, fills the search field in order to find tickets with the same external data linked (like it does for tags), or view a modal with information from external data in a more elaborate way than the default view allows. It could even query the Zammad API itself …

Btw, it would be helpful to have multi-select fields as objects of the type external data in order to link more than one external subject to a ticket.

Let me know if I can contribute in any way.