Roles - Users picking up permissions depending on the role they are are assigned to

Infos:

Important:
If you are a Zammad Support or hosted customer and experience a technical issue, please refer to: support@zammad.com using your zammad-hostname / or company contract.

  • Used Zammad version: 2.9
  • Used Zammad installation source: (source, package, …) package
  • Operating system: CentOS 7

Expected behavior:

  • If I create a role such as IT agent and assign permissions to that role, then map users via LDAP to those roles then those permissions as defined in the role should automatically be assigned to those users.

Actual behavior:

  • Role is created and permissions assigned. LDAP role mapping is created and a sync run. The user is mapped to the role but the permissions set do not apply.

Steps to reproduce the behavior:

  • Create role, assign permissions, create LDAP mapping, run LDAP.

It seems logical to me that permissions would apply from the role and then all users assigned to that role. At present I have around 70 agents in zammad across a number of helpdesk departments and need to assign permissions manually for every single one of them after import. This is error prone and time consuming and shouldn’t work this way. Any way I can get some help to get it resolved?

Sully

We’re talking about group permissions in this case, right?
Because if you expect ticks to appear within the user, this won’t happen.

However, the user rights will be applied.

As I guess that your problem is about group access (in my opinion the only valid case where your role setup might be tricking you) I’ll be jumping on that train:
Ensure that your role has the tick “agent - Access to Agent Tickets based on groups access”, because other wise the below set access rights will not be applied.

image

If this is not what your problem is, please be a bit more specific about what does not work.
Also check your ldap integration page as it should tell you if it updated accounts or just e.g. skipped them.

Hmm, is it possible that this is slightly bugged? I used roles to grant elevated group permissions to certain users, e.g.:

  • I created a group Management.
  • I granted the Agent role “create” permissions to the Management group so that normal agents are able to move tickets into it, but not read or write tickets inside it.
  • The Agent role has “full” permissions to non-critical groups such as Support and Sales, but only “create” permissions to critical groups like Management.
  • I granted the Management role “full” permissions to the Management group.
  • All our agents have the Agent role.
  • Only some specific agents have the Management role.
  • Only the Agent role has the ticket.agent permission.
  • I didn’t re-grant the ticket.agent permission to the Management role because I assumed that all agents already have this permission due to the Agent role.

This seemed to work fine at the first glance, because users with the Management role are now indeed able to access the Management group (whereas normal agents cannot):

  • They can create new tickets in the Management group.
  • They can see and edit tickets in the Management group.

But there is one thing that doesn’t work:

  • They cannot choose an owner for tickets in the Management group. All owner selection fields of tickets in the Management group will only show “-” as the list of possible owners.

I was already looking through the code to figure out how Zammad determines the list of eligible ticket owners before I realized that the missing ticket.agent permission might be at fault, and indeed granting it fixed the issue. IMO:

  • Granting group permissions should either work without granting the ticket.agent permission, when agents already have this permission due to the Agent role (as I initially assumed) or
  • the admin user interface should make it impossible to grant group permissions when the ticket.agent permission hasn’t been granted, or it should prevent me from saving my changes before I’ve granted the ticket.agent permission too.

Also, the documentation should probably mention this.

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