Permissions on folders and resources determine what users see in the repository and what actions they are allowed to perform. In the following table, the actions granted for each permission include all of the actions granted for permissions above it, except for the No Access permission. The actions granted for each permission strictly exclude all of the actions granted for permissions below it.
Permission | Actions Granted on Repository Folders and Resources |
No Access | Users can never see or access the folder or resource either directly in the repository or indirectly when running a report, and dashboard. |
Execute Only | Users can never see the folder or resource in the repository, but the reports, dashboard, or OLAP views that they run can access them. |
Read Only |
|
Read + Delete |
|
Read + Write + Delete |
|
Administer |
|
Administer and ROLE |
|
Permissions apply when browsing or searching the repository, as well as when using any dialog that accesses the repository, such as when browsing folders to save a report.
...
As with all other permissions, execute-only permission is either role-based or user-based, so that certain users may access a resource from a running report, but not others.
 | If you have data or sensitive content in a resource, always set No Access permission for users or roles that must not be able to access it. Hiding a resource with execute-only permission does not protect against access, because malicious users who find the resource ID may be able to create a report, dashboard, or OLAP view that extracts the sensitive content. |
Default User Permissions
For all non-administrator users, the default permission at the root is No Access and any permissions must be explicitly defined. In practice, the default installation of the repository contains sample data with a mix of no access, execute only, read only, and read-write permissions that allow the sample users to access folders and resources. The sample permissions demonstrate a common approach to permissions, allowing users to see the resources they can access and hiding the ones they can’t, while administrators have full access.
...
The Permissions dialog opens. It shows the permissions in effect for the selected object. By default, it first shows the permissions given to roles. Permissions that are inherited from the object’s parent are indicated by an asterisk (*).
 |
Permissions Dialog Showing Permissions by Role |
In the figure “Permissions Dialog Showing Permissions by Role”, you can see the default role-based permissions on the sample Input Data Types folder as seen by the organization admin. Members of certain roles can see and modify the input data types stored in this folder; these roles likely correspond to users such as data analysts. Regular users have execute only permission so they do not see this folder, but the reports they run can access its contents. Administrators cannot change the permission for their administrator role or user name, to prevent them from removing their ability to set permissions.
...
In the figure “Permissions Dialog Showing Permissions by User”, you can see the default user permissions on this folder. In the default installation, all permissions are defined by role; therefore, all user permissions are No Access inherited from the root. The figure shows a read-only permission being granted to the sample end user. This gives the user joeuser the ability to see but not modify the Input Data Types folder and its contents. For all other end users, however, the folder is still execute-only due to the settings in the figure “Permissions Dialog Showing Permissions by Role”.
 |
Permissions Dialog Showing Permissions by User |
6. Click Apply to save your changes. If you toggle between user and role permissions, you must click Apply first to save any changes you made.
...
You can open several permissions dialogs for different resources or folders at the same time, as well as navigate the repository. This helps when trying to set permissions uniformly across several folders or organizations.
 | There are two special cases when setting permissions: •If a resource inherits a permission, for example Read-Only, you cannot set the permission to the same value, at least not directly. You need to temporarily change the permission level on the parent folder, then set the explicit permission, then set the parent folder’s permission back to the original value. When a resource and its parent folder have been set to the same permission in this way, the permission dialog still shows the asterisk as if the permission were inherited. But when the parent is later given a different permission, for example Read-Write, the resource retains its explicit Read-Only permission instead of inheriting Read-Write. •To reset the permission level so that it once more inherits from its parent folder, select a different permissions level and click Apply, then select the permission with the asterisk and click Apply again. |
Testing User Permissions
Once you have configured users, roles, and permissions, Jaspersoft recommends that you test the permissions granted to a few representative users. Testing is also recommended when you add new users, roles, and resources, and when you make any major modifications to your access control configuration.
...