We have Clients who administer our product, and they have Customers who use our product.
We need to provide restricted, Client-Customer access to Knowledge Base articles (Client-Customers see how-to articles but not administration articles) and we need to provide un-restricted access to all articles (our Clients see the restricted how-to and un-restricted administration articles).
We don't need to restrict or hide parts of articles (although we could handle this that way), only whole articles.
In Confluence I think we would use the Unlicensed Access Global Permission for Clients (Administrators) and Annonymnous Access Global Permission for Customers (Users).
In Service Desk I think we can use Portal Only access for Clients (Administrators) to match to Unlicensed Access in Confluence (all articles). Client-Customers (users) generally don't accees Service Desk.
The Knowledge Base space would be linked to Service Desk for access by Portal Only users and the Knowledge Base space would accessable outside Service Desk for Client-Customers (users).
Our issue is that, other than Annonymous Access (public), the Confluence Space Permissions do not include an Unlicensed Access level, only individual and group. The View permission seems the same for both Users and Annonymous; they both see all the articles. So there seems no way to restrict View access by Annonymous to only some articles.
In another solutiuon, tagged articles in the Knowledge Base are only viewable by similarly-tagged Service Desk Organisations and Customers, with the public view of the Knowledge Base restricted to only un-tagged articles. This works for us.
In Confluence we can label articles, so that covers a core requirement.
What we need is the Service Desk Organisation to be labelled to provide access to similarly-labelled articles in the Knowldege Base space (as well as to all un-labelled articles). Linking the Service Desk Customer to labelled articles as well would be even better (then we can differentiate between our various Clients as well).
We want to move to Service Desk, but would also need to move the Knowledge Base to Confluence a well, and this issue will stop both those things happening.
