ACL to exclude ActivityDialog from people NOT pertaining to a Role

[stephanej]

Hello

I have been struggling in using the ACLS when it comes to Roles. It works ok, if I want to restrict a menu based on a dynamic field or particular activity, but as soon as I want to restrict processes, or ActivityDialogs from certain roles, it does not work.

With the following I am trying to say that "anyone who does not have the Role Account Manager" should not have access to AD11.
The result is that no one in the organization has access to such dialog, even those who do have the right Role.
If I replace Account Manager by any other string, it produces the same error.

Code: Select all

    Possible: {}
    PossibleNot:
      ActivityDialog:
      - AD11
  ConfigMatch:
    PropertiesDatabase:
      User:
        Role:
        - '[RegExp]^(.(?!Account Manager))*$'
  CreateBy: stephane
  CreateTime: 2015-06-19 17:30:11
  Description:
   ID: '17'
  Name: 0-ACL-AccountManagers-Rights (Copy)
  StopAfterMatch: 0
  ValidID: '1'

I am not too savvy in Regex, and not sure if I can solve this in any other way than Regex. This seems like a basic demand so I am kind of pulling my hair out

In another process for "vacation approval" I had the same issue and had to create a special role with "employee" to which I assigned every one in the organization that is not a manager so that I could put an ACL that says : if Employee then Possible Not Activity X. This is the only way I had it to work so that people do not auto approve their own vacations Unfortunately I am not going to be able to do that for every role or sub Activity in my processes !!

Thanks a lot for your help

[crythias]

Most permission management works best with affirmative permissions. Those left out by default don't have access.

[stephanej]

Thank you very much for your response.
When it comes to roles, is that to say that my team members should have one single role?

The problem I have is a lot of people have several roles : support/Manager/Finance etc.

Thus if I want that only people with the "Manager" role can see the "Approve Vacation" ActivityDialog, then I create an ACL saying "If Role = Manager then Possible : Approve Vacation" ==> but this causes that Managers can thus see ONLY this one ActivityDialog and no other.

If I want them to see the other activity dialogs then I have to devise all the possible scenarios of each single possibility in my organization/rights to processes for people to see the processes they are entitled into.

It seems that rights as given by ACLs are only restrictive : "possible" means "restricted to". is that correct ?

I am sure there should be a better way, is there not ? or should I devise my roles in a different way ?

thank you

[crythias]

Thank you very much for your response.
When it comes to roles, is that to say that my team members should have one single role?

I can't judge for that. Although, it probably would make it nicer to create sufficient roles that have the permission levels that a user should need and be assigned.

Thus if I want that only people with the "Manager" role can see the "Approve Vacation" ActivityDialog, then I create an ACL saying "If Role = Manager then Possible : Approve Vacation" ==> but this causes that Managers can thus see ONLY this one ActivityDialog and no other.

So give them the roles they need. or create a role that has the permissions of both.

[stephanej]

Thank you again for your fast response.

I think there might be a bug in the way OTRS handles ACLs.

Here is the typical situation:

in Process1
- Sales should access AD1 only
- Account managers should access all AD in this process
- Reps should access AD2 and AD3 but not others

in Process 2
- Managers in the organization have access to AD14 which grants vacation approval, others dont.

The thing is that :
- Sales can be managers
- Reps can be managers
- Some Account managers should not have access to AD14

As long as I restrict an AD to a particular role, then I cannot enlarge again this permission to include somethign else.

If I follow your instructions, I should create n Roles :
Role A : Sales who are managers should have AD1 and AD14
Role B : Sales who are not managers should have only AD1
Role C : Account managers who are also managers : all of process 1 and AD14
Roce D : Account amnagers who are NOT managers
Role E : Reps who are managers
Role F : Reps who are not managers

And if I add more complexity to Process1 : I have again to create 2 roles
And if I need to have a Process3 for approving an invoice this multiplies again everything by 2.

>> Am I the only one with this problem ?
>> is there a way to grant ACL based on agent's login ? i could not find the specific key for this

[crythias]

PossibleNot