This content has been marked as final. Show 3 replies
Welcome to the forums.
Any functionality related to restricting access needs to be taken care of by developers or server admins.
You can create your KB articles as topics in RH and then apply conditional build tags based on what should be viewed by someone with each level of access. You would probably have one output for each tag/level of access, so if you have 5 tags/levels, you end up with 5 versions of your KB.
Your 5 versions go out on the server, but you need a developer or admin to place restrictions on the different folders. Permissions for level 1 access would be granted on the folder with version 1 of the KB, and so forth.
It may sound a little complicated, but how easy juggling the conditional tags is probably depends on how much overlap you have between the levels of access.
Hope this makes sense,
I maintain two flavors of Knowledge Base using RH7. We have an internal Knowledge Base, and one that our clients can see. All is maintained in one project, but I use conditional build tags and Exclude Build Statements to create the two different KBs. Each is published in a different location on our server, and our staff has the URL for their KB, the clients have a link from our website.
You can do the same thing, just sounds like it would be more build tags to manage. But it's doable.
And now, for something compleatly different (intended misspelling)
Instead of Build Tags, you could simply create a merged setup. In this setup you would create different projects. One project for the Dwarves. One for the Elves. One for the Hobbits. Each project goes into its own folder. Then you create one project to bind them together and rule them all (bwa ha ha ha haaa)
As Ben said earlier, you would then have the server admins restrict or control access at the folder level.
There is more information on merging at the link below:
Click here to view the articles