Universal Request 'Restrict' not restricting anything

[castle11]

I have installed the universal request and universal request integration for incident management plugins on my PDI to mess around with but I'm not fully understanding how the restrict functionality works.

What I'm getting from the documentation is that to be able to view or edit a restricted incident/UR, you must have the sensitiveinfo_agent role and be part of the current assignment group, or be the primary ticket agent.

In my PDI, I have a test incident and I am impersonating a user who does not have the sensitiveinfo_agent role, is not part of the current assignment group for the incident and is not the primary ticket agent. The incident and UR have been restricted but I can still see and edit the short description, description etc.

What am I missing?

Thanks

[Ingrid de Cerqu]

I am having the same issue.

I have noticed that there is a read Access Control for universal_request stating:

You can read an Universal request if you opened it, or been assigned to record, or are on the watch list, or have read access to primary ticket, or member of assigment group

Does this mean that if the user already has access to the incident, then restriction won't work???

This does not make sense.

[castle11]

According to the docs (https://docs.servicenow.com/en-US/bundle/tokyo-employee-service-management/page/product/universal-re...)

Only the UR routing agents from the current assignment group with the sn_uni_req.sensitiveinfo_agent role, and the primary ticket agent can view the complete details of the ticket.

So I have created ticket, restricted it, and then impersonated user that is NOT from current assignment group, is NOT primary ticket agent and does NOT have sn_uni_req.sensitiveinfo_agent role, yet I can still see the ticket details (short description etc).

[Steeve]

Same issue here... Understand the concept and the documentation, but no restriction... Please help. Thx

[Vaishnavi K]

@castle11 This functionality is for some specific fields like short_description,description,comments and work notes, and is controlled by field level ACLs which determines if the user has admin role OR if the user has 'sn_uni_req.sensitiveinfo_agent' role OR if the user is assigned_to or a member of the assignment group OR if the user is opened_for OR has the write access to the primary ticket

In any of the above scenario the sensitive  fields will be visible to the user