Restricting incidents based on caller and a specific group

[Chris DeLaPaz]

I have a requirement to hide tickets created by an automation tool to all but a specific group.

I have looked at both ACL's and Before query Business rules and it seems with my requirements Before Query BR's is the most likely.

So, the actual requirement would be something like If caller_id is "autotool" and Assignment group is "Group A" hide Incidents from all except if logged in user is a member of Group A.

I have found results similar to this but sans the caller_id aspect, which is important as they want others to see their other tickets, just not the ones generated from this tool.

I have limited scripting knowledge, and I am hoping someone can help me or point me in the right direction to meet this requirement.

Thanks

[Ankur Bawiskar]

@Chris DeLaPaz 

already there is OOTB query BR "incident query" on incident, enhance that

restrictIncidents();

function restrictIncidents() {
    if (!gs.hasRole("itil") && !gs.hasRole("sn_incident_read") && gs.isInteractive()) {

        if (gs.hasRole('service_viewer'))
            return;
        if (GlidePluginManager.isActive('sn_fsm_itsm_mng') && gs.hasRole('wm_ext_agent'))
            return;
        if (GlidePluginManager.isActive('com.sn_hamp') && gs.hasRole('sn_hamp.ham_user'))
            return;
        if (GlidePluginManager.isActive('com.sn_ot_inc_mgmt') && gs.hasRole("sn_ot_incident_read"))
            return;
        if (gs.hasRole("sn_sow_srm.srm_responder"))
            return;

        var u = gs.getUserID();
        var autoToolCaller = 'PUT_AUTOTOOL_CALLER_SYS_ID_HERE';
        var groupA = 'PUT_GROUP_A_SYS_ID_HERE';

        var qc = current.addQuery("caller_id", u)
            .addOrCondition("opened_by", u)
            .addOrCondition("watch_list", "CONTAINS", u);

        if (!gs.getUser().isMemberOf(groupA)) {
            current.addQuery('caller_id', '!=', autoToolCaller)
                .addOrCondition('assignment_group', '!=', groupA);
        }
    }
}

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Chris DeLaPaz]

I have attempted the solution above, but it has not worked as other ITIL members in different groups can still see these tickets

[Tanushree Maiti]

Hi @Chris DeLaPaz 

Option 1 : Using ACL

Navigate System Security > Access Control (ACL) and click New.

• Type: record
• Operation: read
• Name: incident (or incident.* to include fields)

• Set the Condition to: [Caller] [is] [autotool] AND [Assignment group] [is] [Group A]
• Note: In the Advanced view, check the "Advanced" box to use a script.

ACL Script: 

answer = false;

if (gs.getUser().isMemberOf('<sys_id_of_group_a>') || gs.hasRole('admin'))

{ answer = true;

 }

[Juan Pablo · Accepted solution]

Hi Chris,

Yes, an onQuery Business Rule sounds like a good fit for this requirement since you want to dynamically filter records from list/query results based on multiple conditions.

What I would recommend is:

• Create an Before Query Business Rule on the Incident table

• Check:

  • if the incident was created by the automation caller

  • if the assignment group is the restricted one

  • if the logged in user is NOT a member of that group

• If all conditions match, exclude the record from the query

Something like this should work as a starting point:

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

    var restrictedCaller = 'AUTOTOOL_SYS_ID';
    var restrictedGroup = 'GROUP_A_SYS_ID';

    // If user is member of Group A allow access
    if (gs.getUser().isMemberOf(restrictedGroup)) {
        return;
    }

    // Hide automation generated tickets for everyone else
    current.addEncodedQuery(
        'caller_id!=' + restrictedCaller +
        '^ORassignment_group!=' + restrictedGroup
    );

})(current, previous);

A couple notes:

• Replace both SYS_ID values with your actual records

• Using SYS_IDs is safer than names because names can change

• This approach hides the records from lists and most queries

• If you need full security enforcement (API access, direct record access, etc.) you may still want complementary ACLs later

I’ve implemented similar solutions before and the query BR approach is usually much simpler to maintain for this kind of visibility rule.

Hope this helps!
Regards,
Juan

If my reply was Helpful, please mark the answer as correct.