Title: Allow Group assignment to non-agent users
Hi!
I would like to petition for the ability to assign regular users (customer, not agent) Group permissions.
This is currently not possible, as the ticket.agent permission is necessary to do so. This, however, creates several unwanted side-effects - assigning users this permission also modifies the ticket creation interface, for example.
My specific usecase for this Feature would be to enable presenting users with a list of know issues after login - this avoids unnecessary tickets for bigger issues by making all authenticated users aware of them.
Additionally this would help us fulfill requirements for Incident Documentation and Publication.
Our specific idea works as follows:
- The user role is assigned read permissions to the “Public Issue” group
- This enables the User to view the Overview “Known Issues”, which Agents use to notify and document Issues affecting bigger groups of users. This Overview is set at position 1 so it is selected by default.
Zammad environment:
- Average concurrent agent count: 3
- Average tickets a day: 20
- What roles/people are involved: Agents: IT-Department and Application Groups, Users: All
So you‘d actually look for some kind of news ticker / status page?
For my Usecase? Yes.
This is the best way I could think of to try and build something like this using the functionality available in Zammad.
Since its still all Tickets, agents can still benefit from Objects and Core Workflows.
That said, the Ability to grant customer-users Group permissions would also enable further customizability and usecases for Overviews.
Here is a hypothetical example:
Department A has a subordinate Department B. A would like to see Bs tickets for some reason.
As is right now, I can think of the following resolution to this requirement:
- A is granted ticket.agent permissions. This enables granting A ‘read’ permissions to tickets of B, which extends to any overviews.
This has the drawback of all users of A now viewing the more complicated agent interface.
- A is granted reporting rights, and a Reporting Profile is created to filter for Bs Tickets.
Since Reporting Profiles cannot be locked behind permissions, this presents a potential Data Privacy risk. And if I understand Reporting right, this still does not enable A to view Bs tickets. See: Reporting> Allow role limitation of reporting profiles · Issue #5708 · zammad/zammad · GitHub
- A and B are assigned an Organization with the share tickets permission active.
This is poorly automatable with the current LDAP and SAML implementation. It also causes B to view As tickets, which is likely not desired.
