How to Disable Activity Stream Mentions in Helsinki

[Nia McCash]

Is there anyway to disable Activity stream mentions in Helsinki?   It's a bit of a security hazard for us as we do not want users/requesters to be able to browse the entire ServiceNow users list just by experimenting with the @ mentions.   Currently, they can see the users' full names and not much else, but we would still like to be able to limit this ability.

[Trevor Muhl]

Hello all,

Just to provide an update to the accepted answer, "before query" business rules are no longer permitted on globally-scoped tables (such as incident) within Jakarta.

Attempting to make an activity stream mention within Jakarta Patch 1 Hot Fix 1 completely ends the user's session. This is why I am currently seeking to disable this feature. I have contacted HI regarding this issue and will provide an update if they determine a workaround or fix.

- Trevor Muhl

[LaurentChicoine]

Hi Trevor,

I don't know if you are working on the Global scope or in a scoped app but from the Global scope I have no problem doing a before query business rule on incident in my developer Jakarta instance (on patch 0). I also have no problem for the sys_user table discussed in this ticket.

However, the GlideTransaction object seems to have been protected as there is a warning for illegal access to method getURL when trying the proposed solution (you need to catch the error and log it).

I did look into trying to restrict the Rest API call using an ACL (which seemed more clean) but it didn't work.

So instead here is the use of another undocumented/supported object that allows you to block the API call, would be much easier if ServiceNow provided a system property.

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

       try{
               if(gs.action.getGlideURI().toString().startsWith('api/now/form/mention/record/')){   
                       current.addNullQuery('sys_id'); //All records have a sys_id so we are filtering out all records   
               }   
       }   

       catch(e){   
       }   

})(current, previous);

Warning: gs.action is an undocumented Java object, ServiceNow could decide to retire it or to change it's behavior without any notice.

[Trevor Muhl]

Hello Laurent,

You are correct. One may create a before query business rule if you select a table prior to enabling the "Query" field under the "When to run" tab. When I was attempting this myself, I selected a table after the "Query" field was already checked. This sequence produces the error I was referring to. I believe we just discovered a bug/easy workaround.

There is a client script called "No query for out-of-scope tables" that executes on change of the "Table" field. ServiceNow should create a similar script for on change of the "Query" field to catch the sequence you used to create a business rule.

I understand the necessity of this restriction, though this is a valid use-case, I believe.

- Trevor Muhl

[LaurentChicoine]

So they only enforce it on the client side, they must not be really serious about this restriction. The biggest example of a query business rule on a Global table is the active user query business rule on the sys_user table. I just don't see how they could remove that knowing that ACLs are creating Security constraints messages.

[Trevor Muhl]

Agreed. The client script also has this within the description, recognizing that certain business rules are exceptions, such as the base rule that you have mentioned:

Before-query business rules are not allowed on out-of-scope tables. Before-query rules can be added to tables within your same scope. This prevents things like setting the table to one in your scope, setting the Query flag, and then changing the table to an out-of-scope one. There are exceptions for BRs that existed before this restriction was in place.