Add conditions to the web notification (Zammad bird)

[skip]

Title: Add conditions to the web notification (Zammad bird)

1. What is your original issue/pain point you want to solve?
   The web notifications shown in the Zammad bird are valid for all roles/users that have permissions on certain groups.
   This behavior can bring to notification spam when an agent is part of a group but can only see articles (tickets) filtered by their organization membership (as in, customer and agent are part of the same organization, primary or secondary).
2. Which are one or two concrete situations where this problem hurts the most?
   In our setup it is required to set up 450 roles to make sure that the agents only get notification for the organizations they are a part of.
   As explained here Export/Import Overviews using the rails console - #3 by skip
3. Why is it not solvable with the Zammad standard?
   There is no way to add conditions to the web notification system. (Unless someone knows a workaround/hack)
4. What is your expectation/what do you want to achieve?
   Be able to get only notification for different conditions, like e.g. is member of current user organization

If there is any more useful information, feel free to share it all (e.g.: mockup screenshots, if something is UI related, or the API URL/documentation URL for a service you need a connection to).

Your Zammad environment:

• Average concurrent agent count: 25
• Average tickets a day: 20
• What roles/people are involved: IT technicians, managers, customers

Anything else which you think is useful to understand your use case:
Most is explained here:

OTRS 6 migration to Zammad (test instance for evaluation)

I delved into the various setups within Zammad, exploring its configurations involving groups, organizations, roles, users, permissions, and notifications. From what I understood, what was previously termed a “queue” in OTRS now corresponds to a “group” in Zammad. Although direct connections between groups and users or roles aren’t feasible, group permissions can be established at either the role or user level. The organization setting serves purposes such as user filtering, trigger definition…

and here:

Export/Import Overviews using the rails console

Hi! Thanks for the questions. The issue is pretty interesting. There is a public organization with 450 sites. Single sites have a group and two or more sites can be part of a district and have a common group. Every site is treated independently as it’s own entity and agents are responsible for around 12 sites each and there is a backup agent which is not always the same for the 12 sites. Which means around 24 mixed sites per agent. There is a group for every site or district. There is an o…

Thank you,
Skip

[YetAnotherGerrit]

Usually, notifications can be configured on a “per-group-basis”. When I want agents to be able to select what tickets they want to have notifications for, I divide the tickets into different groups. Then every agent can configure that themself.

[skip]

Thanks you for the feedback.

That is absolutely valid, the issue in our use case is that a (zammad) group is a school district, where two or more schools can be part of one district. An agent can be responsible for a district, only for a single or subset of the schools within a district, additionally to that every agent can have access to a mixed subset of up to 30 schools (main tech and backup tech).

To make this work I have:
a) created a group for every district (or sometimes school)
b) created a role for every school and given that role access to the group (~450 roles)

Only this way I was be sure that agents are not spammed by notifications for groups they should not have access to.

The overviews are set to only show tickets from the organization(s) the agent is member of (secondary organizations). Which means that this way I can also make sure that if an agent has to manage a single school within a district, they do not see the tickets from other schools within that district.

To further filter the notifications by organization would further make this situation cleaner.

This is because even though it is all one big public organization, every school is managed as it’s own entity/site/organization on a support level (one tech, one school), and you can imagine how long it would take to change that to a 1st level/2nd level general support system where multiple agents work on all the schools at an organizational level