Getting Action Not Authorised Info message and redirected to same Assignment Group page.

[VadlamaniJ]

Hello Everyone,

I have one scenario where I am getting stuck need suggestions on this

Scenario:
There are three assignment group  Assignment group 1 , Assignment group2  , Assignment group 3.

Assignment group 1 has - pipeadmin role
Assignment group 2 has - pmgadmin role
Assignment group 3 has - ptatadmin role

1.If a logged in user is mapped with Assignment group1 and has pipeadmin role then he should not be able to edit Assignment group 2 and assignment group 3 which means button at AG 2 and AG 3 Edit  button  should be hidden in related list of assignment group 2 and 3 for group members .

2. If a logged in user is mapped with Assignment group 2 or Assignment group 3 and he has (pmgadmin role or ptatadmin role ) then user with these roles should have editability access for AG 2 and AG 3 , since the user  don’t  have pipeadmin role then user shouldnot edit Assignment group1 as per requirement , we need to hide edit button

3. if user has is mapped with Assignment  group1, Assignment group 2 , assignment group 3
and has all three roles then edit button should be visible to the user in all three assignment groups for editing group members


I have written a code in script include where function is checking on roles and return true or false on the basis of  roles , and we are calling that function in omit edit condition of sys_usergrmember list control in omit edit condition
I have hardcoded the sysids of the group which we want edit button should be enabled or disabled

Script include function:
 

 restrictofgroups: function(gr) {

        var pipeRole = gs.hasRole('pipeline_globalAdmin');

        var pmgAdmin = gs.hasRole('pmg_admin');

        var ptatAdmin = gs.hasRole('x_amspi_acn_bctapp.admin');

        var restrictedGroups = [

            'd52a7fd33bdf9610ff65dc9c24e45ad5',

            '5d046b9f3b1b9610ff65dc9c24e45a46',

            '00da77d73bdf9610ff65dc9c24e45a35',

            '38aa7b973bdf9610ff65dc9c24e45ac8',

            '60897fdf3b9f9610ff65dc9c24e45a5e',

            '0d0b3f1b3bdf9610ff65dc9c24e45ae4',

            '107a7b573bdf9610ff65dc9c24e45aa5'

        ];

        var groupSysId = gr.getValue('group') || '';

        var isRestrictedGroup = restrictedGroups.indexOf(groupSysId.trim()) !== -1;

        if (pipeRole && pmgAdmin && ptatAdmin)

            return false;

        if (pipeRole)

            return !isRestrictedGroup;

        if (!pipeRole && (pmgAdmin || ptatAdmin))

            return isRestrictedGroup;

        if(pipeRole && (pmgAdmin || ptatAdmin)){

            return false;

        }

        return true;

    },

Calling this function in Omit edit condition in sys_user_grmember list control

answer = new acn_PipelineUtils().restrictofgroups(current);

Issues:

case 1. I am able to hide the edit button for the AG2 and AG3 when user has logged in role as (pipeadmin role or belongs to AG1) edit button is visible to AG1 and when I am trying to edit group members in AG1 I am getting an info message as "Action not Authorized" and redirected to same page

case 2. When i am logging in with user which is member of AG1 and AG2 having both roles then edit button is visble only to AG1 not visble to AG2 and on clicking on Edit button in RL i am getting Action not authorized message and restricted for editing the group members.

case 3.For third scenario when user is member of AG1,AG2,AG3 then edit button is visble to at RL of all three assignment group and edit action is also working i am able to add or remove group members in all three AGs.

Can any one help me on this why Edit button is not working for Assignment group1  in case 1 and case 2 or any workaround for this.

 

[danmjunqueira]

You're facing a classic discrepancy between UI-level visibility and ACL-level enforcement in ServiceNow. The issue stems from the fact that you're controlling the visibility of the Edit button via the Omit Edit condition — but not the actual permissions required to perform the operation, which are governed by Access Control Rules (ACLs).

Root Cause of the “Action Not Authorized” Error
Even though your button is visually shown or hidden correctly, ServiceNow still checks the ACLs when a user tries to edit the sys_user_grmember records. If ACLs deny access, you’ll get:

“Action Not Authorized” and be redirected.

What You Need to Fix To avoid this issue, you must:

Step 1: Align ACLs with Your Script Logic
Table: sys_user_grmember
You need to write or modify ACLs on this table — especially on write and update operations — to match the same logic you're using in your script include.

Create or update a Scripted ACL:
Type: record

Operation: write

Table: sys_user_grmember

Condition: Leave blank

Script:

(function() {
var utils = new acn_PipelineUtils();
return !utils.restrictofgroups(current); // if the function returns false, allow access
})();

Your current logic returns true to restrict edit access, so the ACL must return false in that case — meaning: “don’t allow write.”

Step 2: Ensure Role Checks Are Accurate
Make sure the roles used in gs.hasRole() exactly match the roles defined in your system:

'pipeline_globalAdmin'

'pmg_admin'

'x_amspi_acn_bctapp.admin'

Even a typo or case mismatch will cause gs.hasRole() to return false.

Step 3: Validate Role-to-Group Mapping
In Case 2, when a user has multiple roles and is in multiple groups, but the edit button doesn't appear:

Double-check that the user is truly mapped to the Assignment Groups (sys_user_grmember)

Verify that all expected roles are directly assigned to the user (not just via group roles, unless inherited properly)

Step 4: Debug the Return Values
Temporarily log or test return values in your Script Include:

gs.info('Group: ' + groupSysId + ' | pipe: ' + pipeRole + ' | pmg: ' + pmgAdmin + ' | ptat: ' + ptatAdmin + ' | Restricted: ' + isRestrictedGroup);

This will show if the logic is resolving correctly.

Consider Reversing the Logic for Clarity
Right now, restrictofgroups() returns true to omit edit access. It might be clearer to create a function like canEditGroup(gr) and have it return true when allowed — then use !canEditGroup(current) in Omit Edit and ACL.

[VadlamaniJ]

Hi @danmjunqueira 
I tried implementing the solution which you provided i have create a write ACL and written the exact same function suggested by you and i am calling the script include function in the acl script although ACL scripts return true but still due to omit edit condition script again i am getting an info message as "Action not Auhorized". It is not working please give me suggestions on this.

But when i commented my code in omit edit condition then i found that edit button was working fine for AG1 but button was visble to other two Assignment groups, AG1 and AG2  if user is having only pipeadmin role only.

As per my requirement if  user belongs to only AG1 can i make edit button disabled for AG2 and AG3 using acl without using omit edit condition approach. 

[danmjunqueira]

Thanks for the detailed context. Based on your explanation, you're facing a common conflict between UI-level visibility (managed by omit edit condition) and data-level access control (managed by ACLs).
Let me clarify a few key points and guide you toward the best approach.

Key Observations
Your write ACL returns true, and the script include logic is correctly enforced.

However, the edit button is still visible when using only the ACL approach — this is expected because:

ACLs control access, not button visibility.

omit edit condition controls whether the button is shown.

If you comment out the omit edit script, the ACL correctly blocks unauthorized writes, but the button still appears, leading to "Action not authorized" when clicked. That message is from the ACL rejecting the backend write.

Answer to your main question
Can I make the edit button disabled for AG2 and AG3 using only ACLs without using omit edit condition?

No, ACLs alone cannot hide or disable UI buttons like the "Edit" icon in related lists.

ACLs prevent access, but the button will still be rendered unless you hide it using omit edit condition.

If you want a clean user experience (i.e., don't show the Edit button where the user isn't allowed to edit), you must use omit edit condition.

Recommended Solution (Combined Approach)
To meet both your security and UI experience goals, use both ACLs and omit edit conditions together, with consistent logic.

1. Use a Script Include Function
Ensure it returns true when the user should not see the button.

restrictofgroups: function(gr) {
var pipeRole = gs.hasRole('pipeline_globalAdmin');
var pmgAdmin = gs.hasRole('pmg_admin');
var ptatAdmin = gs.hasRole('x_amspi_acn_bctapp.admin');

var groupSysId = gr.getValue('group') || '';
var restrictedGroups = [ /* your group sys_ids here */ ];
var isRestricted = restrictedGroups.indexOf(groupSysId) !== -1;

if (pipeRole && !pmgAdmin && !ptatAdmin) {
return isRestricted; // true = omit edit
}

if (!pipeRole && (pmgAdmin || ptatAdmin)) {
return groupSysId == 'AG1_SYS_ID'; // disable for AG1
}

if (pipeRole && pmgAdmin && ptatAdmin) {
return false; // full access
}

return true; // deny by default
}

Call this in Both:
Omit Edit Condition:

answer = new your_script_include().restrictofgroups(current);

Write ACL Script:

answer = !new your_script_include().restrictofgroups(current);

Use Logging to Debug
Add gs.info() in your script include to confirm exactly which block is being triggered, and validate that groupSysId is what you expect during execution.


Try it and reach me out if solve it please