Server folder Permission

Modified on Mon, 12 Apr 2021 at 11:27 AM

Omniscope has a built-in permissioning system, which allows the administrator to control who has access to different files, as well as which individual user can edit reports or only view them.

The permissioning system of the application is split into two distinct parts: 

  1. Authentication - how the user is authenticated to access the projects.

  2. Permissions - what the user can do, once they have been successfully authenticated.

In order to configure permissions you need you will need to have permissions. This is enabled for users logged in using the secure local account (i.e. accessing Omniscope on the machine that is running on, or if your user has Admin permissions enabled.

If you have permission you can configure permissions from Project listing page by going to three dots (top right hand corner), and then clicking on "Edit permissions" button.

If a folder doesn’t have a permission set, Omniscope will try to find the permission for the folder by recursively going up to the parent folders, until it finds the first folder that has the permissions set. If there are still no permissions found, then the “Default” permissions are used.

NOTE: This approach allows you to organise your folders in such a way that multiple folders share/ inherit the same permission.

Default permissions

The default permissions will take effect when there are no other permissions found for a given folder.

To configure them go to "Project listing" page (index page), and then click on three dots > Edit permissions (as in the first image shown above).

Folder permissions

These are permissions that take effect when you explicitly set a permission on a folder.  

To configure per-folder permissions, go the folder you want to set the permission, and then go to three dots and choose edit permissions.


There are three main sections to the permission dialog which is shown when you click on Edit permissions.

1. Anonymous / Public permissions

The first section you see is the Anonymous section. This section allows you to configure the permissions for non-authenticated user. If you want to force the user to login, you should use "No to All", this will force the user to authenticate based on the super group / group authentication.

2. Groups

The second section of the dialog shows the group based permissions. 

This section is about managing multiple authenticated user groups. Each group can have their own permissions and authentication mechanisms e.g. client A, or Department C.

Group permissions

Define the permissions for each user within the group. The order of "Groups" defined is important as the first matching group is used for authentication.

Authentication mechanisms

Authentication mechanisms allow you to specify the authentication method:

  • List of users - this method is relying on a list of usernames and passwords.

  • LDAP Query - this type allows you to authenticate against your company’s LDAP server.

  • Spnego (Single sign on) - authenticate against your company’s Spnego mechanism.

  • OpenID Connect - OpenID connect settings for the given group.

3. OpenID Connect

The last section of the dialog allows you to define OpenID Connect settings. This allows you to define your own list of "Providers" which should be used to authenticate the user. 

NOTE: OpenID Connect providers are defined for the whole folder, and you can then individually customise the settings per-group to further control the authentication. The order you define the providers is important as the first one in the list is used for automatic login (if configured). 

For more information on different providers and how to configure them see here.

Super groups

Super groups are special groups who will be present in this folder and all sub-folders, irrespective of sub-folders defining their own permissions or not. If a super group is defined, it will take effect (and take precedence over normal groups), in the folder where you are defining them, and all child folders. You would typically used this to define server-wide administrators.

NOTE: Super-groups cannot be overwritten in sub-folders.


Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select atleast one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article