restrict access to tickets

[jna2756]

Hi All,

I am trying to restrict users from being able to read tickets if they are marked restricted(custom true/false field) unless they are member of the group the ticket is in or is the "requested for".

I believe the best method would be to use a on-before Query Business Rule however I am having trouble getting the "addQuery" right.

I want to do the following with addQuery rather than addEncodedQuery as the addEncodedQuery doesn't seem to work right in the script section.

Encoded Query: u_restrict=true^assignment_groupDYNAMICd6435e965f510100a9ad2572f2b47744^ORu_requested_forDYNAMIC90d1921e5f510100a9ad2572f2b477fe^NQu_restrict=false

is it possible to do this with an addQuery statement?

Any help would be appreciated.

Thanks,

Joshua Anderson

[jna2756]

Hey Chuck,

It seems to be someting in specific with the "Or" condition at the end.

The bolded part of the code seems to be messing up

current.addEncodedQuery('u_restrict=true^assignment_groupDYNAMICd6435e965f510100a9ad2572f2b47744^ORu_requested_forDYNAMIC90d1921e5f510100a9ad2572f2b477fe^NQu_restrict=false');

is it possible to right the above query with "addQuery" and "addOrQuery"?

Thanks,

Joshua Anderson

[Chuck Tomasi]

Good detective work Joshua!

Yes, GlideRecord has an addOrCondition() method that can be used. I don't use it much because it gets rather messy with complex conditions.   That's when I usually turn to the addEncodedQuery() method.

You MAY be able to the first part as an encoded query, or series of addQuery calls, then tack on the addOrCondition() at the end since it is pretty simple in that respect.

GlideRecord - ServiceNow Wiki

[jna2756]

Hi Chuck,

Thanks for the suggestion, I will try that.

Also, while digging I did find that "^NQ" part of the encoded query is actually a known problem with no workaround.

ServiceNow KB: PRB647484: Using operator (^NQ) in encoded queries causes incorrect reference links i...

Thanks,

Joshua Anderson

[Joshua Cassity]

Can you provide an example of this?

We're having the same issue and our encoded query is a bit of a beast.. lol.

We're snagging the logged in user's department and putting it into the userDept variable.

Essentially we're trying to achieve the following:

If an Incident is Not Sensitive we want to show the user records to the logged in user where they are the caller, their department matches the caller's department, or the assignment group's department matches their department.

OR

If an Incident is Sensitive we want to show the user records to the logged in user where they are the caller or they are a member of the assignment group currently assigned within the Incident record.

Our Full Code is here: Before Query Business Rule on Incident Management Breaks System

[TrevorK]

I am assuming you have considered this - but why wouldn't you just use an ACL?

I assume with the Business Rule based solution you are more removing them from plain view rather than removing the ability to access them, and if the user were to receive an email with a link to the item, then they would be able to open the item.

Whereas the ACL would lock it down so they could not read the item, no matter how hard they try or what links they have. Not only that, but it would be the fastest solution (performance wise) as well. The downside is that they will receive a message indicating something to the effect of "rows removed due to security constraints".