Limit visibility of Assignment Groups to see only their assigned RITM and REQ

[Russell Abbott]

I have a requirement to test limiting the scope of what each Assignment Group can see.

I have managed to get this to work for Incidents, limiting to only see Incidents that they are the customer, or on the watchlist, or Incidents assigned to their 'Assignment Group' field on the Incident Record

I have managed to get this to work in the same manner for SC_Tasks

However, i haven't found a way to propagate that upward through the RITM and REQ level, we do not have the 'Assignment Group' field on those records and there is no desire to add it

Is it possible to script this in my BR?

Pseudo:

Can view REQ = True

Can view RITM = True

IF i am the customer

IF i am the creator

IF RITM contains SC_TASK where 'Assignment Group' is DYNAMIC 'one of my groups'

IF REQ contains RITM containing SC_TASK where 'Assignment Group' is DYNAMIC 'one of my groups'

Here is my current BR code running on SC_TASK

Condition:

!gs.hasRole('admin')||gs.getUser().isMemberOf("IS-SECURITY-BADGES")

(function executeRule(current, previous /*null when async*/ ) {

if (gs.getSession().isInteractive()) {

//Restrict to caller, watchlist, or members of assigned group...
var u = gs.getUserID(); //Get the sys_id value of the current user
var g = getMyGroups(); //Get the list of the current user groups
var q = current.addQuery('request.requested_for', u).addOrCondition('assignment_group', g).addOrCondition('watch_list', 'CONTAINS', u); //Modify the current query on the sc_task table
}
})(current, previous);

[-O-]

You're welcome!

Thinking about it more, there are potential solutions to this problem. There is field group_list on all task tables, thus on Requested Item and Request too. You could create an after BR on sc_task to copy its Assignment group to that field (group_list) of both the parent Requested Item and the parent Request. Then you can add almost the same logic as for the sc_task, to sc_req_item and sc_request. Instead of expressing [ where assignment_group is one of my groups ] the query would express the condition [ where group_list contains "my group 1" or group_list contains "my group 2" ... or group_list contains "my group n" ].

I believe it is doable.

[Russell Abbott]

Ok, this might work for any RITM with only 1 sc_task. But some of them have multiple tasks going to different groups. I can't see how that would be able to work in that case. Does that sound reasonable?

[-O-]

That is why I proposed that field: it is a field of type List which allows saving very many sys_ids in it. Thus if a Requested Item has 3 Catalog Tasks, it will be able to "hold" all 3 assignment groups. That means that the BR that adds the assignment group of the Catalog Task to the Group list field of the parent Requested Item must make sure to append the sys_id to the field, nu simply replace the current value.

[Russell Abbott]

Ok that makes more sense. I'm not sure how I'd script that but ill do more research this afternoon.

[-O-]

You could also write a Flow. It might work like this:
- select all Catalog Tasks that have the same parent Requested Item (and/or parent Request) as the current/flow trigger one and have an assignment group.

- loop through the records found and build the list of group sys_ids (separated by comma!) with the help of a flow variable (a kind of scratchpad).

- update the parent Requested Item's (and/or parent Request's) Group list field with the compiled list.

The only problem is that in this case assignment groups that were, but no longer are on any of the Catalog Task belonging to a Requested Item (and/or Request) will "loose" access as soon as a Catalog Task is reassigned (unless a different Catalog Task of the same Requested Item (and/or Request) still is assigned to that replaced group.

All in all for sure this can be done using Flows without any code.

The variant where the assignment group history is retained is also doable but some code might be necessary to obtain the functionality where assignment groups are appended to and do not overwrite the Group list field.