
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2014 02:07 PM
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.
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2014 05:36 PM
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2014 06:36 PM
I'm probably missing something, but why would you need to create a separate role for each group? Just create a single role and assign it to any group that needs to be able to work in this way as you move forward. That's no different than the group type you're already using except it's much easier to script around.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2014 06:54 PM
Maybe I'm missing something then. The way we have dealt with this so far is: HR needs to have articles that only HR can see, so I have rules that set the role to hr_knowledge when an HR user creates a knowledge article. Everyone in HR has this role. I have a UI Action that lets a Service Desk user mark an article as Internal and it sets the role to service_desk_knowledge. Everyone in the Service Desk has this role. Now I'm getting a request from the ServiceNow Tech Team (that's my team) to be able to have articles that only we see, so I would think I would need a new role for that that only our team gets.
All ITIL Users get the knowledge role. Anyone with knowledge can see any article with the knowledge role, which they all do unless the author is in HR or someone marked it internal. Finally, if a user clicks Request Public Access a workflow kicks off and following approvals the role is set to public allowing non-authenticated users to read it.
Based on this setup, wouldn't I need to keep creating a role for each team that needs to limit article visibility to just their team?
I was hoping a solution using a before query business rule would let me allow team members limit article visibility to their own team only as each team kept getting requests to be able to do so. Then all I would have to do is add the knowledge type to the group and it would be selectable in the group field on the knowledge form.
I know I haven't explained this very clearly. There's a lot of context around the original question. It's possible that decisions made very early on without my input have painted us into a bit of a corner here. I would love to hear if there's something I'm overlooking that could help simplify this for me.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2014 07:00 PM
That's all fine. The role that I'm talking about would be used strictly for the showing or hiding of the group restriction field. You wouldn't actually set that role on the article.
-Create a role named 'group_knowledge_restriction'
-Create a client script that runs onLoad and hides the group field if 'g_user.hasRole("group_knowledge_restriction") == true'
The rest can remain the same. The new role would simply be added to each group record (and thereby the members of that group) so that the field on the KB form could easily be hidden or displayed.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-10-2014 07:10 PM
Well, that's a simple solution. The reason I was thinking about group types is because that's what I've used up until now to show different Assignment Groups on Incident, Problem, and Change. Thanks for working with me banging my head against the wall to figure out the simple thing you were showing me.