Feature Request

When an account manages multiple projects and each project uses its own SSO configuration, a signed-in user only sees the projects tied to the SSO configuration they authenticated with. Projects configured under a different identity provider do not appear on the project list, even when the user has valid access to them. Allow a user who is signed in through one SSO configuration to see all projects they have access to across every SSO configuration on the account, and let them switch to a project under a different configuration without a full sign-out and re-authentication cycle. Benefit: Users managing or working across several projects can move between them in a single session, without needing to know which subdomain or identity provider each individual project requires

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

The website does not send the ‘X-Content-Type-Options’ HTTP header. Please include this in Header.

One of our customers has requested additional account security features. They would like to implement multi-factor authentication (such as an OTP challenge when a user signs in from a new or unrecognized device) to protect reader accounts. Additionally, they require a password expiration policy that prompts readers to reset their passwords after a configurable period of time.

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.

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.

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 am having a reader group with workspace-level access & I have a reader (Reader A) to be a part of the reader group. I have a category called (Category A) which has an article (Article one). For the article, access to the reader group has been denied. For the reader (Reader A) I have provided individual access to the article by allowing him access in the article level. yet the reader is unable to view article one as the denial is taking precedence. I feel reader allowance should take priority over reader group denial.

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.