ACL: Commentaries on the script code breaks ACLs

[felipe_barbosa]

Recently I got involved on rebuilding the ACLs of our current SNOW instances, and I came across several small issues with the ACLs, for example, I created a new one to test a possibility, then, when debuging the security I noticed that my new ACL wasn ´t being considered in the debug results, it only displayed the old set of ACL rules:

PATH = record/sc_task/read RULE = ((((hasRole() AND script=getScTaskReadAnswer(); function getScTaskReadAnswer() { ...) { return true; } else {...; //comments... } ...) AND script=var ra = false; if (root_rule.substring(0,7)=='var__m_') { var wa = gs.getUser().hasRole('workflow_admin'); var wc = gs.getUser().hasRole('workflow_creator'); var fn = gs.getUser().hasRole('normalizer'); if (wa || wc || fn) ra = true; } ra; ) OR (hasRole() AND script=...;)))) RC = false

I didn ´t understand why my new rule was not there, I tried to do a cache.do, tried to wait a bit and see if it got included, and nothing. Then I copied the PATH string and pasted it in my javascript editor to check what was the issue, and I realized that the reminder of the string was as a commentary because, well, I had a commentary in the script.

I took the comment out and boom! It started to work as expected, and I had the new ACL rule listed on the security debug results. I am not sure if this is a bug, a know issue, but anyway, if you're having issues with ACLs consider looking into the script code and check if there is code comments, if so, remove it and you should be fine.

Cheers!

Felipe

[alan_lowrance]

I've been using the debugging and have no roles or conditions, only a script.   And even when the script is literally just: answer = false; or false; the debugger still shows it evaluating journaled field ACLs as being true.   If you put answer = false; on any other type of ACL, tables/fields other than comments/work_notes, it correctly evaluates the script as false.

Journaled Field ACLs are currently being fixed for one of the hotfixes in Geneva (HI: PRB575131) but this could be a related or underlying issue with it.

[felipe_barbosa]

Hi Alan, could you please share a screencap of your ACL? I am curious to know why this is not working correctly.

Mike, great answers and great avatar right there."Hey, I'm over here!" is what I heard in the back of my mind lol

Cheers!

[alan_lowrance]

It's just the read ACL on .comments_and_work_notes field (journal) on an extended table from task.   It affects any of our homemade apps where non-itil roles are trying to be given access to read that field.   They are unable to see work_notes listed in that journal even though they are given access to create new work notes.   So we have to just show them the Activities (filtered) in the meantime cause the way the journal logs are created on the server, it doesn't work for non-itil even if they have read/write permissions on the table they're looking at.   HI Ticket: PRB575131 has been open for years with them aware of the issue but still no fix slated until later (possibly Geneva but looking less likely).

Seems as if the background/script logic that determins if they canRead() the work_notes or not to create the journal entries doesn't use the "Script" portion of the .comments_and_work_notes ACL and instead just looks up to task-level or for itil role instead since it doesn't even process the script.   answer = false; even returns true when you look at the debugger.

[felipe_barbosa]

Understood. Sorry to hear that, hopefully they will address the issue on the next release.

Have you tried to replicate the same ACL on the parent table as well, not just in the child one, as you mentioned you are trying to give/remove permission to a field on a table that extends task. Maybe it could help out.

Best of luck,

Felipe

[alan_lowrance]

Yeah, it might work to give those other roles read privileges on the task table... but would undermine all "privacy" since now all those non-IT roles will be able to read our worknotes on all the IT tickets.   I did try to put some script logic on the task table's ACL that determined what type of task and returned what role was required to read it and checked if the user had that role or not, setting answer to true/false, but that never executed properly either so I think it's just the script box altogether is messed up for journals.   So we're fine just giving them the Activities (filtered) field on their forms instead of the journal one for now until its fixed.