Using variables in ACLs [SOLVED]

[dstover]

Hi. I am trying to have different ACL settings based on the responsible field. Basically, I would like to restrict the values of a drop down dynamic field if responsible is the same as the logged in OTRS user. However, I cannot figure out how to get the current logged in OTRS user from within an ACL.

Can anyone help? Thanks...Dan.

[crythias]

http://otrs.github.io/doc/manual/admin/ ... -reference

[crythias]

before you tell me you looked there...

You asked about the currently logged in user...
You want to match Responsible => { UserLogin => (currently logged in user) }

Because, for some reason you want to restrict values only when the currently logged in user matches responsible for a ticket.

You can either create the acl for
User => { UserLogin => "bob" }
Responsible => { UserLogin => "bob" }

Is it really imperative to restrict on User = Responsible?

[dstover]

Crythias, what I am trying to do is restrict the values of a dynamic field based on whether the currently logged in user is the same as the responsible person or not. I am trying to use an ACL for this purpose. The ACL example that OTRS provides shows how to restrict the values in a drop down list to only certain ones based on where you are in a process.

For example, within an OTRS process, on activity dialog data entry screen with entity ID AD30 only two of four values are displayed for selection in a given drop down list (which is a dynamic field that contains four entries). On another activity dialog data entry screen, say AD29, the other two values are displayed for selection. So, theoretically, if I can get the currently logged in user or the ticket ID or even the session ID from inside an ACL program (using Perl code if necessary), I can assign that value to the responsible field and restrict the values displayed to the user if they are the responsible person.

Thanks in advance for your assistance. I appreciate your willingness to tackle difficult issues.

Have a nice day...Dan.

[crythias]

Is there any reason Agent Bob should have access to the values when he is not listed as the Responsible?

[dstover]

Not in the current scenario.

[crythias]

So the issue is simplified: Are you Agent Bob? This is what you're restricted to.

[dstover]

I am talking anyone who is listed as responsible would only see those certain values. It could be anyone out of 40 people at my company. So I would have to identify the current user and add it to the ACL. Maybe I am misinterpreting the use of ACLs. Other code that I have written is executed on a ticket basis and contains values from the current ticket. Is this not the case with ACLs?

[crythias]

contains values from the current ticket. Is this not the case with ACLs?

It is. But the ACL tests current values against fixed values or regular expressions. It doesn't test current values against other current values.

[dstover]

So, theoretically would it be possible to use a Perl variable for the fixed value that responsible is checking against in the ACL? If so, I would just need to be able to get the current ticket ID or session ID to be able to get the value of the currently logged in user. I have subroutines that are based on ticket ID but could also use session ID. Or is there some sort of special variable that I can access to get either of those fields?

Thanks...Dan.

[crythias]

theoretically would it be possible to use a Perl variable for the fixed value that responsible is checking against in the ACL?

I guess so. Config.pm is perl, not just a .ini file.

The problem is that the Config.pm is processed without being aware of the ticket's information. What I mean by that is that the ACL in Config.pm is static: "UserID => Bob" (invalid example) always looks for a known field "UserID" and a known value "Bob" and Ticket ACL says, "Read Config.pm and check for a field in an ACL (ie, 'UserID") and check the current ticket's field (UserID) for the Config.pm's ACL value ("Bob").


If you want to create a ticket-aware ACL, you'll need to make one. Kernel/System/ACL/DB.pm is an example.

[dstover]

Thanks for the reply. Sorry for the delay in responding.I will look at that.

[dstover]

Just now getting back to this one. I have looked for Kernel/System/ACL/DB.pm and am not finding it. Am I missing something?

Thanks in advance...Dan.

[crythias]

Sorry for the misspelling: https://github.com/OTRS/otrs/blob/rel-3 ... /DB/ACL.pm

[dstover]

Thanks. That one I found. I will look at the code and see if I can do what I need.

I appreciate it...Dan.

[RStraub]

Sorry for digging this up, but if you have a working example, please share it

Looking for a dynamic acl aswell right now.

[crythias]

> I would like to restrict the values of a drop down dynamic field if responsible is the same as the logged in OTRS user.

This is rather specific.

The standard workarounds are group based or user based.

It really should be like this. If bob is or tends to be a responsible agent instead of an owner agent, set him up with group membership of (a new group) "Responsibles" and provide acl that way.

[dstover]

I did not find a good way to do dynamic ACLs like I wanted. I was going to use ACLs to provide context sensitive menu options (Activity Dialogs within Process Management) based on whether the logged in user was the owner or the responsible person. So I figured out all the combinations I wanted for one user and then wrote a perl script (attached) to generate an ACL file that contained those combinations for all users. Each time a new user is added, the script is run to generate the ACL file, then you rebuild the configuration (/opt/otrs/bin/otrs.RebuildConfig.pl). This allows for context sensitive menus options (Activity dialogs) on various Activities within Process Management. I have done this based on my own entity IDs so you would have to figure those out from your own Process Management work flow.

This may be overkill for what you are looking for but might help a bit. Obviously I do not support this code but am only offering it as an example.

See you...Dan.

[dstover]

Sorry my previous attachment did not attach. Apparently you cannot upload something with file extension .pl. So I changed the extension to .txt, but it is a perl script.

You should be able to see the code now in the attachment. There was a question sent about a generic way to do ACLs. I was not able to figure one out due to other pressing priorities so I just do it via scripted hard-coding.

Have a nice day...Dan.

[RStraub]

Wow, yeah, this surely does seem like overkill

Glad you found a solution for yourself though. For us, it wouldn't be generic enough.

[kellko]

Sorry my previous attachment did not attach. Apparently you cannot upload something with file extension .pl. So I changed the extension to .txt, but it is a perl script.

You should be able to see the code now in the attachment. There was a question sent about a generic way to do ACLs. I was not able to figure one out due to other pressing priorities so I just do it via scripted hard-coding.

Have a nice day...Dan.

Hello,

how do you call the script, when a new user is created? Manually?

Thank you

Andrej

[dstover]

Yes, as part of the new user process. You run it like any other Perl script. It creates a file named DanPM4.pm in /opt/otrs/Kernel/Config/Files/ with all the appropriate ACL code (only for my particular configuration needs for now), based on the contents of the users table. You then run /opt/otrs/bin/otrs.RebuildConfig.pl to rebuild the configuration, which activates the DanPM4.pm file. I also stop and start otrs.scheduler.pl but am not sure if that is necessary.

Have a nice day...Dan.