
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-28-2018 09:37 AM
Hello, I'm working on creating a new dynamic filter option using a script include to populate a list of users matching certain criteria into a filter condition. For any user with an admin role, it works exactly as expected. For any non-admin user, it seems to bomb out and return far too many results, almost as if it is not being passed the current user's sys_id like it should be.
Anybody happen to have any idea why that would be?
Note: The script include I would rather not change if possible, as it is used for generating approval requests.
Dynamic filter condition on the user table:
Script include (client callable):
function GetChangeCoordinators(userObject) {
// Get itil group type
var groupType = new GlideRecord('sys_user_group_type');
groupType.get('name', 'itil');
// Get groups the submitter is a member of
var groups = new GlideRecord('sys_user_grmember');
groups.addQuery('user', userObject);
groups.addQuery('group.type', groupType.sys_id); // Filter groups to get team groups by checking Type
groups.query();
// Get members of those groups
var users = [];
while(groups.next())
{
var otherMembers = new GlideRecord('sys_user_grmember');
otherMembers.addQuery('group', groups.group);
otherMembers.addQuery('user', '!=', userObject); // Filter users to exclude submitter
otherMembers.query();
// Add members's sys_id's to array
while(otherMembers.next())
{
users.push(otherMembers.user.sys_id.toString());
}
}
// Filter array of users for unique entries
var arrayUtil = new ArrayUtil();
users = arrayUtil.unique(users);
// Check which of those users have the Change Coordinator role and add them to an array
var changeCoordinators = [];
for (var index = 0; index < users.length; index++)
{
var userHasRole = new GlideRecord('sys_user_has_role');
userHasRole.addQuery('role.name', 'change_coordinator');
userHasRole.addQuery('user', users[index]);
userHasRole.query();
if (userHasRole.next()) { changeCoordinators.push(users[index]); }
}
return changeCoordinators;
}
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-28-2018 01:32 PM
Check to see if the affected users have read access to all the tables you are querying in the script include.
It seems I had the same issue at one time when I was trying to use sys_user_grmember for some users that did not have the itil role.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-28-2018 01:32 PM
Check to see if the affected users have read access to all the tables you are querying in the script include.
It seems I had the same issue at one time when I was trying to use sys_user_grmember for some users that did not have the itil role.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-28-2018 01:53 PM
I checked that out, and even gave a test user the user admin role, but it still did the same thing as previously. (Acted as if nothing was passed to the function, which caused it to return 70-something matching entries instead of just the users from the current user's matching groups).
A while back, our user_admin role was modified so it could see both inactive and active users, as it wasn't that way out of the box for whatever reason. For what its worth, the only thing standard ITIL users wouldn't be able to see on the user table is inactive users.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-28-2018 02:15 PM
It shouldn't be because sys_id is limited to admin only would it? If that was the cause, then one would think dynamic filter options such as is(me) that uses gs.getUserID() function wouldn't work.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-28-2018 02:26 PM
I wouldn't think so...
What seems odd is your symptom of it returning TOO many results. It seems like it would not return anything if it wasn't working.
So if I am understanding correctly, an itil user gets zero results, a user_admin gets more than they should, and the admin gets the correct values...
Since you are piggybacking off of another process (the the script include), you might just create a brand new one for testing and add some log statements just to allow you to see what it is in fact returning in different sections of the code. That would keep your original safe, but allow you to experiment and step through and find the issue. Worse case, you find an issue and you just create a specific include for this filter (to preserve your existing functionality).
The other idea is to disable the business rule (I assume you modified the query business rule on the user table) and see if you get different results between itil and user_admin.