Feature Request

Currently, the Reader List is only accessible when a project is configured as Private or Mixed. If readers were initially added while the project was in Private/Mixed mode and the project is later changed to Public, admins can no longer access the Reader List. To convert these readers into users, administrators must temporarily change the project back to Private/Mixed, perform the required actions, and then switch it back to Public. This workflow is cumbersome and impacts usability. Please consider making the Reader List accessible for Public projects as well, allowing administrators to manage existing readers without changing the project's access mode.

In the Edit Reader Group window, when a user searches for a reader using the Search email field and then removes one of the matched readers, the list and count do not retain the search/filtered context. Instead, the view resets to the default (unfiltered) list, and the count reflects total group membership rather than the remaining filtered results. Example: Search returns 4 matching readers ("1 to 4 of 4"). User removes 1 reader. Expected: "1 to 3 of 3" (remaining filtered results). Actual: count resets to "1 to 20 of {total group membership}." Additional issue: The modal window obscures the name of the reader group being edited, making it difficult to confirm which group is being modified, particularly impactful for customers working across multiple groups in parallel (e.g., split-tab workflows for moving readers between groups).

Problem Statement: After migrating to inherited permissions, categories and articles that existed before the migration retain their access but do not visually appear as "selected" in the Reader Group settings screen. Admins must manually re-select these items to make the UI match actual access, which is a manual, error-prone workaround for a display inconsistency that the product itself creates. Suggested Enhancement: Automatically update the Reader Group UI so that any category or article to which a reader group has access (whether granted before or after migration) is shown as selected, without requiring manual re-selection by the admin. Customer Benefit: Removes a confusing, support-generating discrepancy between actual permissions and what the UI displays, and eliminates the manual clean-up step admins currently have to perform after migration.

Customer requested an option to bulk update content access for multiple reader groups at once. Currently, access needs to be updated individually for each group, which is time consuming when managing many groups. A bulk update option would help administrators manage reader group permissions more efficiently.

I need to be able to filter the list of readers in the "Readers & Groups" section of the "Users & Security" tab. This would help me know who has already logged in from that reader group and who I need to re-send the activation email to so that they can activate their accounts. Currently, I have to scroll through the whole list of readers or search by a portion of their email address but I can still miss some.

Currently, when a reader belongs to multiple Reader Groups, access permissions are inherited across all groups. This makes it difficult to restrict access to specific categories when users are part of multiple groups. Customer would like to have block inheritance for readers as well, allowing administrators to enforce access control such that only explicitly assigned Reader Group permissions apply. This would enable scenarios where a category can be restricted to a single Reader Group, even if users belong to other groups with broader access. This enhancement would provide more granular and flexible access control for Knowledge Base content.

This request was created on behalf of Eric We are assigning content access by selecting 'Category' for a reader group. Whenever we create a new category under a parent category which is being used in a reader group, the new category isn't getting automatically added to the reader group. We expect the new category to be added if the parent category is already added under a reader group. Thank you.

For our internal audits, we need to be able to identify readers not only by name and email, but also by the company they work for and/or their position. To do this, we would need the following: One or more additional data fields in the reader account where we can add custom information. An extension of the filter functionality to filter for custom information, such as a company name.

We would like to suggest adding an option that allows assigning specific reader accounts access to articles with inheritance blocked. If an article has been blocked for their inheritance in the portal, it is restricting the logged-in reader accounts from accessing the article on the site, even if it is a public article.

The selection process is missing one key element. It is the same when selecting the categories for reader groups or for export or probably other areas. If you choose workspace, then the everything down the structure is immeidately selected. If instead you start by slecting the language, it selects everything below it but not the workspace. in real it should becuase that is the only path it can be. If you unselect at the workspace level, then everything below it is unselected. If you unselect a language, then everything below it will be unselected. If you select a first level category, it automatically selects the langauge and workspace by default. Same for unselecting. The problem comes in when slecting ANY sub-category. It does not behave the same. If you select a second level or below category, it does NOT select everything below it. It does however select the workspace and the langauge for you but not the categories leading up to the langauge and workspace.