Feature Request

As an Admin, I need to be able to check that certain roles and permissions are functioning as I expect without having to have someone else test these for me. Example 1: I'm an Admin. I set up a contributor role that does not allow publishing. As an Admin, I can see and use the Publish button. I want to confirm that the contributor role does not have access to the publish button. I want to click on my Profile icon within Doc360 and select "Impersonate" and select a role or specific user to impersonate. Example 2: I am an author. I add a private note in an article I'm working on. I set the permissions of the note only to other authors. I want to preview the article and impersonate a Reader of the knowledge base to ensure that they cannot see this private note.

One of the customer has mentioned that they are reporting a moderate vulnerability because the sub resource integrity (SRI) checks are not being performed on Document360 for their hosting at support.nvoq.com . The customer would like to include the SRI checks in our testing process.

I would love to see multi-factor authentication using either Google or Microsoft authenticator.

It would be more understandable to replicate to the reader user card the attributes (specifically Content Access) given to the Reader Group. If a user belongs to a Reader Group, the Content Access displayed in the reader user card is not the one from the Reader Group, and this creates confusion. One should know very well which Content Access is given to the Reader Group to know also the reader user Content Access. There is discrepancy. In my case, the Group had Content Access Complete, but the reader user had None.

Currently, when access to a page-type category is restricted for a specific Reader or Reader Group, the associated articles under that category are also restricted and become inaccessible to that Reader or Reader Group. Since the system treats a page-type category as an article, the customers expect the restriction on the page-type category to apply only to that specific category and not to cascade to the related articles.

We would like to have an option to embed Document360 via an iframe instead of injecting the widget script. Currently, the script-based integration makes it hard to work in environments with stricter CSP or isolation requirements. An iframe-based solution (e.g., a hosted HTML endpoint) would allow better separation and simpler integration on our side. This should support full widget functionality within the iframe, without relying on access to the parent window. Related requests: “iframe option - Private projects” and “Support for Document360 Widget in Nested Iframe Scenarios” Those highlight similar needs, but this request is for a more complete and supported iframe-based integration approach.

To be able configure SSO for the "open article" link in the knowledge base assistant so that user do not need to sign in again to the knowledge base after clicking the link.

It would be good if new categories which are added to the knowledge base portal are added to the Reader Group(s)( content access) automatically. With this, we can make sure that all the contents are visible to the readers and we can save a lot of time.

We cannot export any content unless it is published. Since private publishing is unfortunately limited to enterprise accounts, we cannot share any private content with our customers. This requires us to export content in PDF. Yet it requires extra effort too. We need to publish the article very quickly, export it and unpublish it without anyone seing it. This entire process must be optimized.

Hello! Is there a way to give clients access to a specific article or category for a pre-defined period of time? (for example, from Jan 1st 2023 to Dec 31st 2023?) It's like setting an expiry date after which the content will not be available in the client's account. This would be very crucial as we scale our project. Otherwise, it will be very challenging to manage user access. Thank you!