User can't GlideRecord the Incident table

rrincon · ‎03-12-2014

Hi all,

I created a custom role to handle a custom table, similar to out-of-the-box Incident table.

So, a normal user can create an incident, and if it is assigned to the group where the user is member, it creates a new record on the custom table. So that user (or any of the group) can solve this incident on the custom table, not the OOTB Incident table.

Once the record is Resolved or Closed, it needs to update the parent one on the OOTB Incident table to assign to another group. I did this with a business rule.

Well, it turns out that this is not happening.

Even the user has read/write ACL permissions on the OOTB Incident table (incident & incident.* ACL's), it doesn't work.

Can someone guide me through here, please?

Thanks in advance!

Jim Coyne · ‎03-13-2014

It would probably be best to deactivate the current Business Rule, and create a copy of it, calling it "Custom - incident query" and the script would look like:

(function(){


         if (!gs.hasRole("itil") && !gs.hasRole("your_role_name_goes_here") && gs.isInteractive()) {


                   var u = gs.getUserID();


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


                   gs.print("query restricted to user: " + u);


         }


})();

Change "your_role_name_goes_here" with your new role.

This would essentially give your new role read access to all your Incidents, assuming ACLs do as well. Now I suggest this without knowing any of your processes or business requirements.

View solution in original post

TJW2 · ‎03-13-2014

Try:

var incNum = current.u_incident_number.sys_id;

OR

var incNum = current.u_incident_number.toString();

Jim Coyne · ‎03-13-2014

Before we go any further, can you wrap your code within a function like so:

(function() {




...insert your code here...




})();

I just want to make sure we are only dealing with your code for this particular Business Rule. See this section of a wiki article - https://wiki.servicenow.com/index.php?title=Business_Rules#Business_Rule_Variables_are_Global.

Once you get the hang of it, the format I'm suggesting above is a little simpler, I believe - https://community.servicenow.com/people/jim.coyne/blog/2013/06/22/2394

rrincon · ‎03-13-2014

Hi Jim,

I did it as you suggested, but I found something:

This user just has access to 3 records on the Incident table: the records where the Caller is himself. So he can't access to the related Incident he solved.

I checked the ACLs on Incident table, and watched that "incident" and "incident.*" read ACLs grants the custom role I created for this user.

Am I missing something?

Jim Coyne · ‎03-13-2014

So you hit the next thing I was going to check. There is a "before query" Business Rule called "incident query" that limits the Incidents non-itil users can see. Basically, if a user does not have the "itil" role, they can only see an Incident if they are the caller, they opened it or are on the watch list.

rrincon · ‎03-13-2014

Ok, I found that BR.

What do you suggest? Create another BR where we can grant access to that custom role? Or modify that BR to include the custom role?