Trying to create a private group Version Yokohama

Trabuzaid
Tera Contributor

7 hours ago

I am tasked with creating a private group for sensitive incidents/request. I have created a group and a role successfully and two ACLs but it is not working properly for me. I am self-taught and still learning.

For my ACL's I have one for incidents- read and incidents-list.

I tried both ways with a required role and without and tried both of these scripts with no luck.

 

if(gs.hasRole('private_group_role')){answer=true;}else if(!current){answer=false;}else{var u=gs.getUserID();if(current.assigned_to==u||current.caller_id==u||current.opened_by==u){answer=true;}else{var g=current.assignment_group;if(g){answer=gs.getUser().isMember(g.toString());}else{answer=false;}}}

 

 

// Privileged override role (use technical role name, no spaces)
if (gs.hasRole('private_group_role')) {
  answer = true;
} else if (!current) {
  answer = false;
} else {
  var userID = gs.getUserID();

 

  // Direct stakeholders
  if (current.assigned_to == userID ||
      current.caller_id == userID ||
      current.opened_by == userID) {
    answer = true;
  } else {
    var ag = current.assignment_group;
    if (ag) {
      answer = gs.getUser().isMember(ag.toString());
    } else {
      // strict default deny when no assignment group
      answer = false;
     
    }

 

 

0 Helpfuls
  • 313 Views
1 REPLY 1

Matthew_13
Kilo Sage

5 hours ago

You’re very close my Friend!

but two things are tripping you up.

First, ACLs can’t reliably protect “private” incidents unless the record tells ServiceNow it’s private. Right now your logic is based on assignment_group, which means any incident assigned to a group the user belongs to may still be visible. Add a simple boolean like u_private (or a u_private_group) so the ACL knows which records are sensitive.

Second, list access is controlled by a query ACL, not just answer=true/false. Your script works better for form access, but for lists you must filter rows using current.addQuery(...); otherwise incidents will still appear in lists and searches.

Also, small fixes i see to be done:

  • Use current.caller_id.toString() == gs.getUserID() (reference fields can be flaky without toString()).

  • Keep the override role check first, then evaluate stakeholders (caller, opened_by, assigned_to), then private-group membership.

Once you:

  1. Add a u_private flag

  2. Use one read (record) ACL for form access

  3. Use one read (query) ACL to filter lists
    The behavior will be consistent and predictable.

 

@Trabuzaid - Please mark as Accepted Solution as Thumbs Up if you found Helpful!!

0 Helpfuls