Dynamic Overviews (Is it possible to use variables in conditions?)


  • Used Zammad version: 5.3.1
  • Used Zammad installation type: docker-compose
  • Operating system: Debian 11
  • Browser + version: -

Here, Zammad is used as an internal TTS. All users are part of the same organization. Each user has an assigned department. I’d like to have an overview “All tickets of my department”, which should meet the condition:

#{user.department} == #{ticket.customer.department}
#{user.organization.name} == #{ticket.organization.name}

So the question is: Can we use variables in Overview Conditions? If not, how would a workaround look like?

… My first idea for a workaround was to create multiple overviews with static dept. assignments ("Tickets of Dept #1, Tickets of Dept #2, … ) but i since I want users to only see their relevant overviews (for their dept only), I could not find a way to assign that view to “customers, where users.department == some_string”. I know, I can assign this overview manually to specific single users, but this is not a real option.

As a side question: Can we use more specific comparison than “contains” / “does not contain”. I’m missing “exact match” or - even better - regex support.


Upgrade to the latest version of Zammad as they have added more functionality with the ‘Expert Mode’.

This may help accomplish what you are trying to do.

Hi Sal, thanks for your input. I tried Zammad 5.4, but that didn’t make a difference. In fact, the overview I created (contains string #{ticket.customer.department}) broke the ticket creation process. I could not submit a new ticket and the web gui threw an error. So again: Is there some way to create a dynamic overview? Zammad already has the “Tickets of my Organization” overview, which is very close to what I want. If we could replace “my Organization” with “my variable” then it would be perfect.

I tried to find the overview logic and predefined overviews in the sourcecode, but i must admit, I do not know ruby at all, so I’m having a hard time browsing through the code…

Have you considered creating organisations for every department? Or do you really need them all in one organisation?

Core Workflows doesn’t allow the use of variables.

Thanks for the answers… Meanwhile I looked at the code and think I understand, why this is not easily possible (because the ticket model has an attribute organization_id but not a department_name or other additional “customer” attributes). Never the less, I think it would be good to have more than one possibility to classify a ticket (Organization, Department, maybe a custom field).

Basically, I need something like this: Ticket should be visible for more than one customer · Issue #1307 · zammad/zammad · GitHub. I could swap the current organization with departments and be happy about it, but certain hierachies can’t be modeled with this, e.g.:

I have a head of department, that is responsible for two departments. I’d like that he can see all the tickets of Dept #1 and Dept #2 (but not Dept #3). The company boss should be able to see all the tickets.

Since a customer can not have more than one organization, I can’t build this (or at least I don’t know how). So - for me - it would be nice, if a ticket had a department_name that we could filter on. Also for this use case, it would by super-cool, if a customer could be assigned to more than one department (which is a thing in RL: shared employees, trainees, people with higher responsibility, etc.)

Also from a conceptual type of view, I do not really like to replace an organization with departments . An organization should be the organization and a department should be part of it. Dropping / swapping the organization would also raise new problems like measuring total statistics (How to get data for all “internal” tickets next to the data for every single department?) in particular, if there are other (external) organization in the system as well? Should I write the organization to the department field? :slight_smile: How are others doing this?

But maybe I’m seeing it wrong: Does somebody has an idea on how to solve my use case?

@MrGeneration: Is this a feature you have in mind or is it unlikely to happen?

If you believe this is a missing functionality, feel very welcome to create a feature request here:

Please don’t mention me directly to draw more attention to your thread.
We’re in generally not communicating roadmaps nor ETAs - I can’t and won’t qualify the need of your desired functionality. I’m not even PO.

This topic was automatically closed 360 days after the last reply. New replies are no longer allowed.