Hide Reference Field if Reference Qualifier Generates No Choices

[Shawn Dowler]

What is the least redundant way to determine if a reference qualifier is limiting all references in a reference field so that nothing can be selected? I'd like to hide that field for users if it doesn't apply to them.

The background is that I have a requirement to allow a user to limit visibility of a knowledge article to members of their own team. I've added a field to the kb_knowledge table referencing Group. I am using a before query business rule to hide the knowledge article from all groups except for the group in the field I've added (if the field is blank, then users in any group can see it if they have the right role). All of that works great. Now I have a reference qualifier running a script include that limits the groups in the list to groups the current user is a member of, which also works. There are only going to be a few groups that are allowed to do this right away, so most users will not see see any groups if they try to fill in the field. For users who can't select any groups, I would like to not even display the field to avoid confusion.

[Mark Stanger]

There's probably not a simple way to do that based off of the reference qualifier but this would be very simple to do just by giving those users or groups a certain role and then hiding based off of that.

[Shawn Dowler]

Thanks for taking a look at this, Mark.

The issue is that I am filtering the list on type (I put the type I created on three of the groups for testing purposes, so they appear in the list) and then I want to further filter based on the current user. The reference qualifier is calling a script include to do that, but I don't want to call the script include twice, once for the reference qualifier and again in a Business Rule to hide the Group reference field. Here's the Script include for reference. I think I could do it that way, but I didn't want to do that if I could avoid redundancy by checking the currently selectable list generated by the reference qualifier.

var CurrentUserAssignmentGroups = Class.create();

CurrentUserAssignmentGroups.prototype = {



       CurrentUserAssignmentGroups: function() {

               var gp = ' ';

               var a = gs.getUserID();



               //return everything if the user id is empty

               if (!a)

                       return;

               //sys_user_grmember has the user to group relationship

               var grp = new GlideRecord('sys_user_grmember');

               grp.addQuery('user', a);

               grp.query();

               while (grp.next()) {

                       if (gp.length > 0) {

                               //build a comma separated string of groups if there is more than one

                               gp += (',' + grp.group);

                       } else {

                               gp = grp.group;

                       }

               }

               // return Groups where the current user is in those groups we use IN for lists

               return 'sys_idIN' + gp;

       },

       type: 'CurrentUserAssignmentGroups'

}

Here is the Reference Qualifier:

javascript:'active=true^typeLIKE9922d5f60f74310039b14b9ce1050e31^EQ^' + new CurrentUserAssignmentGroups().CurrentUserAssignmentGroups()

I get the feeling like there's something I'm missing that would let me get the list of qualified items before loading the form. Maybe not, though.

[Mark Stanger · Accepted solution]

The problem is that all of this is operating server-side and you need to hide the field client-side.   There's no way to get a list of possible results without calling back to the server via GlideAjax/script include from the client.   Doing it this way you'll have to have a second call in addition to the reference qualifier.

If you could just look at a user attribute (like a role given to those groups and group members) and determine if the field should be shown or hidden for that user then you could do it all client side using 'g_user.hasRole' without any additional messy client-side queries.   Just replace the group type with a role and you're all set.

[Shawn Dowler]

We already have things set up using roles for a couple of teams, but as I'm seeing the need grow, I was hoping to find a way to enable it for all groups in the future so I wouldn't have to create a unique role for each team that wants to have knowledge articles that only they can see.

I thought I could do this in a Business Rule, but I see that field-level changes on the form can't happen server-side, so that makes this a moot point.

I have heard that Fuji will allow for multiple KBs, so teams could conceivably have their own completely separate knowledge base is necessary.

Thanks for your help.