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]

Hi Joshua,

We didn't get around that issue. We actually don't have many tickets that are restricted and most of our users use the default filters from the modules so they only see tickets that they would normally see anyway.

Thanks,

Joshua Anderson

[Joshua Cassity]

Our issue is that we are essential a service provider and we have about 20+ departments that use the system and they all want to only see their stuff.. so we have a ton of folks who could potentially see about 95% empty / security constrained records... doh!

[TrevorK]

The empty rows would be from the lack of a record level ACL would it not? I believe this is how we solved the empty row problem, but it's been quite a few months so I would really have to go over our code a lot closer. But I just looked and we only get the "rows removed by security constraints" issue and not the empty rows (which I know we had at first).

The security constraint one is a bit tougher. I believe you can achieve what you are looking for if you are willing to put in the overhead of a before query Business Rule on the table. This runs every time the table is queried of course, but you should be able to structure it NOT to include certain Incidents if it meets your criteria. Again, this has overhead to it but if it makes management happy then perhaps it is justifiable. We did not go this far ourselves, but I think the theory is sound and should work.

[Joshua Cassity]

I may have to look into the row ACL. We had to use an Incident.* and a plain incident row level ACL because our service desk can see limited amounts of data on everything. Not for sure if that's what's causing the empty row issue.

The problem is we have two different sets of criteria for the Before Query BR and it severely impacted our system performance negatively.

We went that route and had issues with it. We also found out that you can't use an encoded query with a '^NQ' condition due to the way ServiceNow handles those in a business rule — which leaves us in quite a quandary.

The answer we got from HI was the following:

PRB565444 - Filtered rows due to security constraints make finding accessible records a painful experience which is closed as a product enhancement and will be implemented in one of the future releases.

Not exactly a solution… at least not yet.

~ J ~