Add condition on UI action- check if logged in user is part of a group

Varun Sai · ‎04-06-2024

I have a requirement to make the UI action visible only when logged in users group is part of certain groups. I created a system property which stores the sys_ids of the groups and want to call this system property in a script Include which I can add on a UI Action.

Note: The reason I am not adding the condition on UI action is it has a character limit of 40 char on UI action condition and I have other conditions as well along with group visibility it was not fitting all the conditions here.

Script Include:

getCheckCondition: function(curRec) {

var userGrp = gs.getProperty('sn_user.groups');

answerGrp = 'sys_idIN'+userGrp;

var grIncRec = new GlideRecord("incident");

grIncRec.addQuery('sys_id', curRec.sys_id);

grIncRec.query();

if (grIncRec.next()) {

if ((grIncRec.state != '7') && (grIncRec.correlation_id == '') && (grIncRec.correlation_display == '') && (grIncRec.u_transfer_id == false) && gs.getUser().isMemberOf(answer)) {

return true;

}

},

In the UI action I just want to call 'getCheckCondition' function from the Script Include to on the UI Action.

For the above script it's not working as expected for the groups for the logged in user. Would really appreciate any pointers or where I am going wrong.

Jim Coyne · ‎04-06-2024

Whereas that may "work", it is far from being efficient. You are looping through and making a query for each Group sys_id. A better script would be something like this:

(function() {
  var user = gs.getUserID();
  var ids = gs.getProperty("whatever_name_it _is");
  
  var ga = new GlideAggregate("sys_user_grmember");
  ga.addEncodedQuery("group.sys_idIN" + ids + "^user=" + user);
  ga.addAggregate('COUNT');
  ga.query();
  while(ga.next()){
    gs.print(ga.getAggregate("COUNT"));
    gs.print(ga.getAggregate("COUNT") > 0);  //is the User in any of the Groups?
  }  
})();

One query to get the number of records returned. The result would be:

But again, would not do it this way. Look at my response to the original post on what I believe is a much more elegant solution.

View solution in original post

Varun Sai · ‎04-07-2024

Hi @Rajesh_Bhise ,

I tried your solution however I am getting an error when I run in the background script. it not returning true only for the last if statement.

Sumanth16 · ‎04-06-2024

Hi @Varun Sai ,

var ShowCloseTask = Class.create();
ShowCloseTask.prototype = Object.extendsObject(AbstractAjaxProcessor, {

	initialize: function(current){
	},

	checkCondition: function(current){

		if((gs.getUser().isMemberOf('Testing & Quality') || gs.getUser().isMemberOf('IT ServiceDesk & EUS') || gs.getUser().isMemberOf('Problem Manager')) && current.request_item.cat_item == '325ada7adbac8490d71941efaa9619bb' && current.short_description.indexOf('Task 2 : Test')){
			return true;
		}
		else {
			return false;
		}

	},

	type: 'ShowCloseTask'
});

UI Action condition:

new ShowCloseTask().checkCondition(current);

If I could help you with your Query then, please hit the Thumb Icon and mark it as Correct !!

Thanks & Regards,

Sumanth Meda

Varun Sai · ‎04-07-2024

Hi @Sumanth16 ,

I was initially going for the same 'isMemberOf' Function, but there are more than 10 groups that we need to add, and I created a system property to call it in the script include because those 10 groups will be used in other scripts too so that we can reuse.

Jim Coyne · ‎04-06-2024

What I would do is:

create a new Role to allow users to see the UI Action
add the Role to the "Requires role" embedded list on the UI Action form (you might have to add it if your form has been customized)
Add the Role to the appropriate Groups

Now the UI Action will only appear if your Condition evaluates to true AND the user has one of the Roles listed. This makes more logical sense in terms of security. Groups are just meant to assemble users into logical teams and Roles should be what allows things to appear or happen.

A benefit of doing it this way is your developers/ops people can see the conditions for it to appear in the one form instead of having to decipher some code, based on a System Property. No need for messy code nor the System Property. You just made it simpler to troubleshoot.