Can I limit visibility of specific assignment groups to other assignment groups?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-20-2016 11:55 AM
I'm not sure if User Interface is the right category for this.
I've been asked to make 2 or 3 assignment groups VISIBLE to only 2 other groups.
Example:
Group A, Group B, and Group C will only display in a drop down list for people in Group X or Group Z.
This is specifically for Incident Management; the goal is to prevent incidents from being erroneously escalated to Groups A, B, and C.
Any ideas?
Thank you!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-20-2016 01:38 PM
You can do a query business rule on the Group (sys_user_group) table. Something like this might get you close:
//Condition:
gs.getSession().isInteractive() && !gs.hasRole("admin")
function onBefore(current, previous) {
var sdUser = gs.getUser();
if(!sdUser.isMemberOf('Group X') && !sdUser.isMemberOf('Group Z')){
current.addQuery('name','DOES NOT CONTAIN','Group A').addCondition('name','DOES NOT CONTAIN','Group B').addCondition('name','DOES NOT CONTAIN','Group C');
}
}

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-20-2016 01:42 PM
Will an onQuery BR affect a reference list when clicked? Or should he look to an advanced/dynamic RefQual instead? You could use the same basic code you've posted, but as a dynamic filter for refqual, or as an on-demand Script Include to be called by an Advanced RefQual.
-Brian

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-20-2016 01:45 PM
It will affect the list if the rule evaluates to true. Then it will hide those groups. I've used Query BRs in the past without issues. Getting the conditions right, was the hard part.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-20-2016 02:12 PM
I'd do it via a reference qualifier
I doubt you will get it to work in the limits of the existing qualifier length, so what I tend to do in scenario's like this is have a script include called LongReferenceQualifier and inside create all the relevant functions which do all the work
so the reference qualifier is javascript:new LongReferenceQualifier().possibleAssignmentGroups()
and in the script include, (client callable), just make sure there is a function called possibleAssignmentGroups() and the return value should be the fully composed reference qualifier
typically for me it will return a long string line such as
sys_id=0^NQsys_id=234234234234fad2342342^NQsys_id=23423423424^NQsys_id=234234234234fad2342342^NQsys_id=23423423424^NQsys_id=234234234234fad2342342.............. etc
but it can return a very short one where the Script include is performing a number of queries or loops etc.
In the past for a client that did some ebonding, on the group table I added a simple list field and collated what group(s) could see this group in the Assignment Group list (besides working on the types allocated to the group). If this list was blank it was based purely on the type, if the list had a value you had to be a member of one of the groups that could assign as well as the ticket type.
I took it further and on the user table added a new checkbox of "ebonding" if this was chosen a new tab appeared and on that it an option for each type of ticket they used and again you could determine which groups could assign the ticket to that user....
The reason for this was we added a manual group called "Support Partner" which had all the ebonding users.
Quite a few teams could see this
inside there were around 20 odd users. not every team should see the users so we limited those too.
Once the assignments were made, Business Rules fired off the SOAP / Emails required for the partner.