1. UI/UX update
We have amended a few changes in the Security menu grouping. Users & Security is the new grouping we have added in the Settings. To get access to feature under 'Users & Security', go to Settings → Users & Security.
Please find below the new menu tree-view and their respective help article links
Users & Security
I. Knowledge base portal
- Team accounts & Groups: Team accounts | Team account groups
- Content role & Access: Project, version, and language level content access
- Roles: Portal role | Content role
II. Knowledge base site
- Readers & Groups: Readers | Reader groups | Readers self registration
- Site access: Public | Private | Mixed
- IP restrictions: Allow/Block knowledge base access for IP range(s)
Earlier the roles of a team account or group can be assigned as Owner, Administrator, Editor, Draft Writer, or Custom role which defines the set of permissions to the project. Now with this update, the roles feature is split into two types of roles.
Team account's access to features in the knowledge base portal
The content role defines the permission for knowledge base content a user can perform in the knowledge base portal.
To explore the Roles feature, go to Settings → Users & Security → Roles
If you are an existing user, you might have already defined the roles in the knowledge base. Please check the below table to get an insight into how the roles have been updated in an effective way
|Existing User Role||-----||New Portal Role||-----||New Content Role|
|Draft writer||=||Contributor||+||Draft writer|
|Custom role||=||Custom role||+||Custom role|
For example, If a team account was assigned as Editor in the project, now with this update: the portal role would be Contributor and the content role would be Editor.
Similarly, If a team account was assigned a custom role, the portal role would be Custom and the content role would be Custom, say you have been assigned the custom role named UX writer and desired set of permissions, now with this update: the portal role would be UX writer and the content role would be UX writer, the set of permissions would be the same as before.
3. Article content security access
Another handy update is the addition of managing content access at an article level. Earlier users cannot manage access to an individual article in a category. Now you can enable article access to any team account(s) or group(s) associated with the project.
Navigate to your desired article in the knowledge base portal, then click on ••• → Security → Knowledge base portal access control (or) Knowledge base site access control. You can manage the content access of the selected article.
4. Deny access
We have added the option to deny access to any team account or team account group (or) reader or reader group at version, language, category, or even individual article level.
When you deny access to any team account or reader, they cannot access the knowledge base unless the access is enabled.
For team accounts and team account groups
The version and language level access can be managed through the Content role & access (Settings → Users & Security → Control role & access). The category and article-level access can be managed at an individual level in the documentation editor section.
For readers and reader groups
The version and language level access can be managed through the Site access (Settings → Users & Security → Site access). The category and article-level access can be managed at an individual level in the documentation editor section.
When you hover the mouse pointer over the items, you would find the Deny access icon on the right. Click on the icon and then Yes in the Deny access confirmation prompt to restrict the access.
5. Mixed site access
Earlier the knowledge base can only have either of the two visibility settings, Public or Private. Now with this update, we are introducing a third site visibility option. The Mixed knowledge base site access.
Mixed is a hybrid site access setting that allows parts of the knowledge base to be public and parts of the knowledge base to be private access only for reader accounts with login credentials.
For example, In a knowledge base project with versions like v1, v2, and v3. The versions v1 and v3 can be set as 'private', whereas version v1 can be set as 'public'.
This mixed site access applies for versions, languages, categories, and even at an article level.
Switching the knowledge base site access
Click on Settings → Site access and select Mixed from the three options available.
If the knowledge base is being switched from Private or Public to Mixed site access, then few changes in the granular level access permissions can be observed.
Similarly, if the knowledge base is being switched from Mixed to Public or Private site access, then all the granular level access permissions would be reset.