<< Click to Display Table of Contents >> Navigation:  Enterprise > Users > Permissions

 

With EQuIS Enterprise permissions, administrators can assign and manage user privileges for tools and data within the application. To accommodate various users’ needs, the permissions infrastructure supports a wide range of possibilities ranging from open access to a precisely controlled and secure system with each user having specific permissions to specific objects. EQuIS administrators must review, define, and actively manage user permissions to ensure data security.

 

To effectively use the permissions infrastructure, it is important to first understand the basic components therein. This article describes each of the components of the permissions infrastructure and how each permission applies to Objects (e.g., an administration dashboard, a specific facility, specific reports) and Object Types (e.g., dashboards, facilities, and reports) within EQuIS.

 

Permission Types

 

There are four types of permissions that control how a particular user may interact with particular object types and individual objects: Owner, Editor, Viewer, Creator.

 

• Owner – An owner of an individual object has all permissions on that object, including the ability to edit the object (i.e., editor), view the object (i.e., viewer), and delete the object (requires Professional access depending on object type). An object may have multiple owners. A user that creates an object is assigned as an owner of that object (but that permission may later be changed or removed by an administrator).

• Editor – An editor of individual objects may edit and view the object. Editing an object may include changing the properties of an object (e.g., changing report parameters). An editor may not delete an object nor share the object. An object may have multiple editors.

• Viewer – A viewer of individual objects may view or use the object, such as viewing a dashboard  or downloading a report. A viewer may not edit, delete, or share the object.

• Creator – Creator is a special permission granted on object types that applies to creating an object. Creator permissions cannot be granted or denied on a specific object (e.g., ABC facility) — only on object types (e.g., facilities). For example, a user with creator permission on dashboards may create new dashboards. When the user creates a new dashboard, they automatically receive Owner permission on that dashboard. However, they do not have creator permission on that dashboard, as the creator permission applies only to the action of creating dashboards. This permission does not apply to specific individual objects that have already been created.

 

As indicated above, Owner is inclusive of Editor and Viewer, and Editor is inclusive of Viewer. However, none of the other permissions includes Creator, nor is Creator inclusive of any other permission.

 

Examples of interactions controlled by permissions include editing a dashboard or viewing a facility map or report. A user may have permission to many objects; an object may have permissions assigned to many users (i.e., many-to-many relationship).

 

When changing a user's permissions, the user should log out and then log back into the Enterprise site for all of the permissions to refresh and take effect.

 

 

 

Object and Object Type Permissions

 

Permissions assigned to specific objects apply only to that specific object, and have no effect on other existing or future objects.

 

Permission granted on an object type (e.g., facilities) applies to all current and future objects of that type (e.g., the ABC facility). When granted to users who should not have this level of full access by object type, the related object permissions must be manually denied as appropriate.

 

Since the object types differ inherently, there is variation in the way each permission translates into user privileges. The following tables describe the object type privileges included with the four permission types.

 

 

 

 

 

 

 

 

 

 

Users vs Roles

 

All of the permissions discussed above may be granted to individual users. In many cases, there are groups of users with highly similar permissions. For convenience, a role can be created (see Role Manager widget) and permissions assigned to that role. When a user is assigned as a member of a role, he/she assumes all permissions that are granted to or denied from that role. In addition to assuming permissions via role membership, users may also have specific roles assigned.

 

For example, suppose a role called Central States Project Manager is created and editor permission is assigned to a dozen facilities. A user is designated as a member of that role and has the editor permission on those 12 facilities via membership in the role. There are two other facilities not included in the role permissions, but that user also needs permission to these facilities. The user may be assigned as editor for those two specific facilities, giving the user permission to 14 facilities. If the user is later removed from the Central States Project Manager role, the user will continue to have permission to the two specific facilities (but will no longer have permission to the original 12 facilities).

 

Grant vs Deny

 

Administrators may grant and/or deny each of the permissions described above to a user for a given object or object type. In all cases, an explicit "deny" takes precedence over a "grant".

 

For example, suppose the database contains 20 facilities and a user has been granted viewer permission on facilities (as an object type). The viewer permission on facilities gives the user the permission to view all existing and future facilities. However, suppose one facility is highly confidential. That user may be denied the viewer permission on that one facility. The user will still have permission to view the other 19 facilities (and future facilities), but will not have permission to view that one highly confidential facility.

 

A deny always overrides a grant of a permission, regardless of whether it is through a role or at the individual user level, assuming that the permissions are equal (e.g., deny viewer overrides grant viewer, but deny editor can still allow grant viewer). While a deny always overrides a grant of a permission, a role does not override a user, nor does a user override a role. The Permissions Grid is used to display and modify (i.e., grant or deny) the permissions that a user or role has within EQuIS.

 

Denies for Admins

 

Folder Permissions

 

EQuIS 7 includes the ability to grant permissions on folders via the Explorer widget. This capability is limited to users with administrator rights. Each user will only see a folder if they have permission to that folder. To add or remove an item to/from a group/folder, the user must have Owner permission on both the item and the group/folder.

 

There are two ways in which a user may receive permission on a given folder:

•Explicit Folder Permission – An Administrator may right-click the folder (in the Explorer Widget) and grant/deny permission on that folder to a user or role. When permission is explicitly granted/denied on a folder, the permission includes all objects within that folder (recursively through all subfolders). If an object is later added to the folder (via the Explorer Widget or some other way), the same permission will automatically be applied to the user for access to the newly added object. For example, explicitly granting viewer permission on a folder will automatically grant viewer permission on all of the facilities shown. If any file is added to the folder (or any of its subfolders) at a later time, viewer permission will automatically be inherited on those files based on their membership in said folder. A granted permission inherited from a folder does not override a denied permission (i.e., deny always supersedes grant).

•Implicit Folder Permission – If a user is granted any permission on an object within a folder, that user will automatically receive viewer permission on all folders that contain that object. The implicit permission on the folder will allow the user to see the folder and then to browse to the object. The implicit permission on the folder is not automatically inherited by all child objects (unlike an explicit folder permission, which is automatically inherited by child objects as described above).

 

The following scenarios help illustrate folder permissions based on the example below:

\Folder1\Folder2\FacilityA

\Folder1\Folder2\FacilityB

\Folder1\Folder3\FacilityC

\Folder1\Folder3\FacilityA

 

 

For scheduled EQuIS Information Agent (EIA) reporting, permission to run the report is determined by checking the agent's owner/creator to see if they have at least viewer permission on the facility specified by the user report. The user report's facility is determined by examining the value of the FACILITY_ID report parameter. If the report has no FACILITY_ID parameter, then the value of ST_USER_REPORT.FACILITY_ID is checked. A null value for either of these is interpreted as the group of all facilities. If a facility group is specified, then the user must have at least viewer permission on all facilities in the group.

 

For EDD and Trigger EIA reporting, permission to run the report is determined by checking the agent's owner/creator to see if they have at least viewer permission on the facility specified by the EDD that caused the reporting event.

 

EQuIS Information Agents have an option to report for any facility or only the facility specified by the user report. In this case, the user report's FACILTY_ID parameter value is used as a filter to determine if the EIA should be run for a given EDD. If the EDD's facility equals or is a member of the facility specified by the user report, then the EIA applies and should be run, otherwise the EIA is skipped without any notification.

 

For all EDD and Trigger reports, the EDD's facility is passed to the user report via the FACILITY_ID parameter at run time.