- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-28-2022 08:14 AM
Has anyone else run into this issue, where Knowledge Blocks do not apply their security settings properly when a User has contribute rights to the knowledge base. I.e. They can view all blocks no matter if they are placed on the can not view list.
If a member of L1 is on the contribute list for the knowledge base they can read the knowledge block even if you specify that you do not want them to see it. Is this a flaw in the knowledge blocks? I attempted the manual ACL of the Knowledge blocks and was still unable to get the results I desired.
Is there a process to setting these up manual in a way that prevents those with contribute access from seeing the knowledge blocks if they are not allowed too? Note L1's require contribute access due to we want them to always be able to create articles even from cases.
Solved! Go to Solution.
- Labels:
-
Knowledge Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-01-2022 09:37 AM
Disregard I found the issue:
Turns out you have to enable the proprieties on this to get it working.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-27-2022 05:59 AM
Hi my topic was based on article level, we are currently using both, and for warning we made a lot of major ACL changes to get things to work the way we wanted. This was due to we upgraded so OOTB options where not a option for us. We had to figure things out as we went along. I will not be able to walk you thru all of the changes made as they are unique to our system.
Aside from those changes this was the only other option in regards to using knowledge base them selves.
You may need to do many more changes based on your system. Also ensure you have started/migrated to using "User Criteria" to manage visibility. Note one thing they don't state is to ensure your only using one of the applied "can read" or "can contribute" per user criteria as they do not require to be assigned to both which causes some confusion for user and also breaks the ACL process. Here is the servicenow link in regards to ACLs.
Hope this helps you moving forward on the journey to finding which method will work for you.
Understanding User Criteria and ACLs in Knowledge v3: v3:https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0550924
Migrating Knowledge ACL:
https://docs.servicenow.com/bundle/sandiego-servicenow-platform/page/product/knowledge-management/reference/r_MigratingKnowledgeAccess.html
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-21-2022 12:01 AM - edited 12-21-2022 12:12 AM
Hi LeChara
Thanks for pointing to that property, I will definitely remember that, but I just also wanted to share this support article from ServiceNow themselves on this matter, that I came across.
Perhaps they should update the article I linked to, to include the property you mention here, as they do not really provide any solution to it other than stating "The shown behavior is expected." I have suggested that on the support article.
One aspect that is that in larger organizations, overriding contribute access, based on Can Read and Cannot Read user criteria at article level, is perhaps not something that everyone want to have. Different departments could have different view points on this. Just an afterthought to keep in mind.
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0747389