Incidents assigned to someone who is not a member of the group

[Brian Lancaster]

We have found a couple incidents were it was assigned to someone who was not a member of the group.   The user does have an ITIL license.   After some investigation I found that if you put the users name in the assigned to and hit save you get a message that match could not be found.   How ever if you his save again it will save the incident in that person name even if they are not in the group.   Is there a way to fully prevent someone from assigning a incident to a ITIL user who is not a member of the group that the incident has been assigned to?

[Pradeep Sharma]

Hi Brian,

You may find the below thread as helpful.

Assigned To technician must be a member of Assignment Group

[randrews]

I had a recurring issue with this.. so i created a BR on the incident table that checks the assignment group of the assigned to prior to letting the record save...

this is a before rule on the incident table..

conditions are

current.assigned_to != ''

script is

var ourUser = gs.getUser();

ourUser =ourUser.getUserByID(current.assigned_to.user_name);

if(!(ourUser.isMemberOf(current.assignment_group.name))){

    gs.addInfoMessage(current.assigned_to.getDisplayValue() + ' is not a member of ' + current.assignment_group.getDisplayValue() + ' please correct the assignment group or assigned to and save the record');

current.setAbortAction(true);

}

[Brian Lancaster]

I realized I was unable to reproduce this in dev.   I took a look at the reference qualifier in dev for the assigned to and it was set as roles=itil^EQ.   Not 100% sure what the EQ is and I noticed that in prod it was just roles=itil so I added the ^EQ and now I cannot reproduce this issue in prod.   We recently upgraded to Eureka so I'm not sure if the ^EQ came from that and why it didn't update prod.

[alan_lowrance]

Hi Brian, I think I just replied to you over in my post as well, but yeah it probably just happened from the group changing without clearing the assigned_to.   You had mentioned you created a client script that will blank the assigned_to whenever the group changes but that will only occur when you change it on the record via the form.   If you change the assignment group from a list_edit you would also need a similar Business Rule to do the same thing.

For future searchers, I'll post my client script in here as well:

function onChange(control, oldValue, newValue, isLoading, isTemplate){
   if (isLoading || g_form.getValue('assigned_to') == '') //doesn't run onLoad or if there's no tech assigned
       return;
   if (newValue == ''){ //shortcut to clear tech if clearing group
       g_form.setValue('assigned_to','');
       return;
   }
   var currtech = g_form.getValue('assigned_to');
   var grplist = new GlideRecord('sys_user_grmember'); //this table lists all group-member associations
   grplist.addQuery('group',newValue);
   grplist.addQuery('user',currtech);
   grplist.query();
   if (!grplist.hasNext()) //clear technician if not in the newly assigned group
       g_form.setValue('assigned_to','');
}

This is an onChange client script on the Task table that runs on the Assignment Group field.   Blanks the assigned_to technician if they aren't a member of the group you're reassigning the ticket to

EDIT: g_form.clearValue is different than g_form.setValue to an empty string.   I used to use clearValue and was noticing if you grouped a list by assigned_to, there were multiple groups of empty.   Each NULL value was kind of creating its own sysid reference to nothing where if you set assigned_to to a blank string they grouped nicely into the "(empty)" group.