Feature Request

When assigning permissions to users, selecting the top-level category does not automatically select its subcategories. This results in having to manually check each subcategory, which can be time-consuming and inefficient. It would be beneficial if selecting a parent category automatically applied the same permissions to all nested subcategories to streamline the process.

While creating a reader group, we will be selecting the categories and articles for the content access of the reader group. It would be helpful if we could differentiate which of the given categories or articles are hidden.

As permission inheritance doesn't work with reader accounts like it does with team account you have to check off ALL of the categories and multiple layers of sub categories you want them to have access to. If this is hundreds of categories this takes an extremely long time, and is actually broken if you try to select more than 45 categories at one (I have a support ticket in for this). It would literally save hours if we either had a check box for select all and then just uncheck the categories we don't want them to have access to or we could click the first box then hold shift and click the last box. Preferably child permission inheritance would be preferable so we wouldn't have this issue to begin with but if we do have to check these off manually, especially if down the line new categories are made and we have to go into each reader and modify their permissions an easier and quicker way of selecting nearly all would be preferred

Usecase: I would like to associate a reader to be a part of multiple reader groups. I have three categories: Category A, Category B, Category C. Reader group 1 has access to Category A, Category B. Reader group 2 has been denied access to Category B. If a reader is being added to a reader group 1, he will be able to access both Category A & Category B. If I add the reader to reader group 2, then Category B will not be visible as it is denied for group 2 and denial takes higher precedence. In such cases, while adding the reader to second group (with denied access to some components) it would be great if we could have a popup window which provide the below warning message. Please note that this reader will have the more restrictive permissioning across all reader groups to which they belong;

Currently, we have the option to map the reader group according to the domains for the standard reader account. Similarly, if we have this option for SSO, it will be easier to manage readers with different content access. Use case: I have a Mixed Knowledge Base with external customers and internal employees. The Domain filtration will help us automate this process rather than manually updating the reader level content access.

I often get asked to provide a list of Readers that belong to a specific Group, but I'm currently unable to filter them by that group or export them. I think this would be valuable to many customers.

In case Readers belong to a Reader Group that have access to sensitive information, there is a need to have a check box on the Landing Page (and maybe even at individual Category / Article level), by which the Reader is enforced to confirm that the NDA has been understood. In such case, only when checked the Category or Article should become visible to the Reader.

it seems to me counter intuitive to opt-into something that removes a default action from ocurring. I would expect to opt into adding a feature and unticking a box to remove that feature / action from happening. It would be more natural if the box was by default ticked and the message "send invitation email" was displayed if you, as a company, want the email to be sent by default, OR the box was left unticked and the message "send invitation email" was displayed to allow the user to tick the box in order to send the email. thank you.

Feature to Bulk import e-mail domains.

It would be great to have the possibility to update reader users in the reader tab in bulk. Right now, to edit or delete, a lot of manual work is required to singularly change each user.