The crux of the issue is (while testing in a non-prod instance):
- Added a reference varable to the sys_user table called 'Default Group' (u_default_group), which refers back to the Group Member list (sys_user_grmember).
- In the User form, when I click the magnifying glass, the popup list that opens up only shows sys_id
Things I've done in trying to make the popup list show actual group names:
- In Dictionary Entries > Table = sys_user_grmember, found 'Group' and set 'Display' to true
- In Dictionary Entries > Table = sys_user_group, found 'Name' and set 'Display' true
Those changes did have one effect: When I start typing a value into the 'Default Group' variable box now, the auto-complete/suggested, human-legible group names actually do show up (see below 1), but it's still showing only the sys_id if I click the magnifying glass icon (see below 2).
"below 1"
"below 2"
Additionally, when the auto-complete options show up (as I start typing a value), they show multiple values for each group (Note: I understand *why* multiple values are showing up--because the table referenced holds many-to-one (group-to-user) values. I just need it to only show unique group names if possible.
And some background on why I'm doing this (in case someone can think of a better way): The end goal here is to be able to employ a script that sets the 'Assigned to' on an Incident to the current user if its state is changed to Active and that field is empty.
- Presently this script does not (cannot) work because
- If 'Assigned to' is not empty, then 'Assignment group' must not be empty (I don't want to change this), and
- The 'Assigned to' field is dependent on the 'Assignment group' field (i.e., the individual must be a member of the group selected).
So I did some research and found someone recommendations to create a 'Default Group' variable in the sys_user table, which I was working on testing, in order to be able to set up some additional script logic that will change/set the 'Assignment group' to the current user's default group where applicable (if current user is not a member of the current assignment group or if the assignment group is empty).
PS - This is my first post in the community. I've only been administering SN for my company since Sept. last year. Thank you all in advance for your help here.
You can create a new Business Rule on the Incident table to do what you are looking for without the extra field:
Name: Custom - Set Assigned to
Table: Incident
Active: Checked
Advanced: Checked
When: Before
Order: 200
Insert: Checked
Update: Checked
Filter Conditions:
Condition: gs.isInteractive() && gs.getUser().isMemberOf(current.getValue("assignment_group"))
Script:
(function executeRule(current, previous /*null when async*/) {
//assign the Incident to the user who just updated the record
current.assigned_to = gs.getUserID();
})(current, previous);
The Condition field adds to the Condition Filter and ensures the update is being done by someone logged into the system (isInteractive) and checks to make sure they are a member of the current Assignment group (isMemberOf).
The only potential issue here is the "isMemberOf()" method returns true if you select an Assignment group that the user is not actually a member of, but is the Parent of another Group the user is a member of. For example, the OOB "Database" and "Database San Diego" groups. If the user is a member of "Database San Diego" and "Database" is selected as the Assignment group, the BR will run and assign the Incident to the user, even if technically they are not a member of "Database". It's one of those quirks in the system. Should not be an issue if you are not using the Parent relationship.
This method saves you from maintaining an extra field on the User record.
And welcome to the Community!
