User Criteria not working as designed on Knowledge Block

[Kim Tillano]

I created an article with a knowledge block in our test instance.  The article is in our self service knowledge base which is not restricted at all, but the knowledge block has a restricted audience.  I set "can read" on the block to only for members of our IT group since the knowledge block contains technical info.  I tested it by impersonating a user who has zero ServiceNow access besides our service portal and it worked fine.  I sent the article link to my manager and he impersonated someone who is not part of the IT group and reported that she was able to see the knowledge block even though she shouldn't. 

I ran user criteria diagnostics, which confirmed she does not have access to the knowledge block, and yet when I impersonated her, the block did appear in the article.  There were a couple other weird things when I impersonated her.   She had strange access in ServiceNow - for example she was presented the checkout button on the article although she should have zero access to do so.  In addition, her user menu/name did not appear on the banner.  I checked her groups/roles, and she does not have any knowledge or itil type role. 

I tested a couple other users and experienced mixed results.  It seems folks who have access to any knowledge in any capacity other than the service portal can see this knowledge block even though user criteria diagnostics say they don't have access. What am I missing? 

We do not have any ACL's or user criteria in place at the article level.  All restrictions are at the knowledge base level and/or knowledge block level.  This makes no sense to me.

 

[Niklas Peterson]

Hi,

In the past I have had some issues with impersonation and User Criteria. My admin rights seemed to overrride the impersonation. Check if the problem persist if you log in as the user rather than impersonate.

Regards,
Niklas

[Kim Tillano]

I actually figured out something else just in the last hour.  I had no restrictions on the "can create" for our self service knowledge base and this user had some roles in ServiceNow.  I instead locked it down to users with the knowledge role and now when I impersonate her she can not see that knowledge block because she does not have the knowledge role.  Unfortunately anyone with contribute access to that knowledge base can still see the knowledge block and they shouldn't. 

It is evident that "can create" permissions at the knowledge base level currently supersede any "can read" restrictions at the article/knowledge block level.  I submitted a suggestion on the idea portal to create an override checkbox that would allow us to specify permissions at the article/knowledge block level should override the knowledge base permissions.

In addition, I think we need to submit a HI ticket because user criteria diagnostics should accurately determine that she could see it and why.  Instead it returned a result of no access, which was not correct.

[Sarup Paul]

In Paris, we are working on adding a global property that will allow you to override the KB level UC with the Article level can read / cannot read UC. 

[Kim Tillano]

That's great news!  I assume this would apply to knowledge blocks as well?