Anyone using read/cannot read User criteria on Knowledge Articles?

[Cameron Wilson]

With Istanbul came the ability to have read access or restrictions at the Article level based off of User Criteria. I was excited to use this and not have to build KB after KB for every group and instead have a Global Knowledge Base that all could use and if there were articles that needed to be restricted this would accomplish that. However how the system is setup is that the KB level access is still the end all be all for access. 

Our goal is that if I have X amount of teams and our end users using a single KB but I have article A that I don't want a certain team to see that I use this new functionality to do so. What happens though is the team that I don't want to see this article has contribute access at the KB level as we want them creating and managing articles so applying Article access User Criteria does nothing.

Has anyone started to use this and found a good way to use the article level options by way of ACL's or scripts? Any advice or suggestions would be greatly appreciated. 

[Eric Viets]

One solution we did: We added a new field (not reference field) called Author Group field.  The author field and this field is only updatable by the KB owner or KB managers (very few people). Upon creation, the Author Group defaults to the author's default group (which may not be the best fit, which is why someone needs to be able to update it).

We also added the functionality that only the KB Owner, KB managers, and anyone who is in the Author Group is able to edit the article.

The reason the new Author Group field is not a reference field is because if the author moves to another department, he or she should no longer be updating that article (unless he or she is still a member of that group).

Caution: Before implementing this, make sure the Author Group field is filled out for existing articles. Otherwise, only the owner and managers will be able to update the articles (until the author group is saved in the kb_knowledge record). Also, it may seem like a good idea to script the Author Group to the existing author's default group, but that may not be a good idea. For employees who are no longer there (who don't have a default group) or employees who have moved to another department (and have a new default group), this will not work. So, be careful how you update the Author Group before restricting the write access by it. It may take some significant manual work (depending how long you've already been using SN Knowledge Management), but having clean data is worth it.

Good luck!

[Cameron Wilson]

Thank you Eric. I will look into trying something like this as I think I will have to go down a route similar to this. The logic is there so I thank you for sharing, much appreciated!