Permissions

<< Click to Display Table of Contents >>

Navigation:  Enterprise > User Administration >

Permissions

Permission Types

Object and Object Type Permissions

oOwner

oEditor

oViewer

oCreator

Users vs Roles

Grant vs Deny

Folder 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.

 

Ent-Permissions-Owner-Icon 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), delete the object (requires Professional access depending on object type), and share the object (grant permissions to other users on that object; requires administrator to access this functionality in Enterprise). 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).

Ent-Permissions-Editor-Icon 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.

Ent-Permissions-Viewer-Icon 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.

Ent-Permissions-Creator-Icon 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., GKM 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 does 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.

 

Note: For Professional Application Level Security (ALS) users, both the database credentials specified in the connection string of the ALS Role and the permissions set in Enterprise apply. Any database access denied from the connection string user will also be unavailable to users via the ALS role. For more detail, see Role Profile Editor.

 

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 Springfield 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.

 

Ent-Permissions-Owner-Icon Owner

Object Type

Enterprise Interactions

Professional Only (ALS)

Dashboards

View, edit, and delete any dashboard—current and future, regardless of the dashboard object creator. Edit options include changes to existing widgets and dashboard sharing (see Dashboard Editor).

 

EDDs

View and download any EDD submittal.

Delete

Facilities

View and edit any facility.

Delete

Files

View, download, and edit metadata of any file stored in DT_FILE.

Delete

Groups and Folders

View all folders (groups). Owner permission on any object in the folders. Required to add or remove objects from a folder in EQuIS 7.21.2 or higher.

Delete

Modules

Currently no access via Enterprise.

Form and button access; edit data with adequate facility permission.

Reports

View and run base reports (ad hoc mode) and any user reports. Edit and delete any user report (regardless of the report object creator).

 

Widget Types

All widget types are available for adding to dashboards.

 

 

 

Ent-Permissions-Editor-Icon Editor

Object Type

Enterprise Interactions

Professional Only (ALS)

Dashboards

View and edit any dashboard—current and future (regardless of the dashboard object owner). Edit options include changes to existing widgets dashboard properties (except sharing).

 

EDDs

View and download any EDD submittal.

Delete

Facilities

View and edit any facility.

Delete

Files

View, download, and edit metadata for any file stored in DT_FILE.

 

Groups and Folders

View all groups/folders (RT_GROUP = UI folders). Editor permission on any object in the folders.

 

Modules

Currently no access via Enterprise.

Form and button access; edit data with adequate facility permission.

Reports

View and run any base report and any user report. Edit any user report.

 

Widget Types

All widget types are available for adding to dashboards.

 

 

 

Ent-Permissions-Viewer-Icon Viewer

Object Type

Enterprise Interactions

Professional Only (ALS)

Dashboards

View any dashboard—current and future

 

EDDs

View any EDD submittal.

 

Facilities

View any facility.

 

Files

View and download files stored in DT_FILE, dependent on the facility and folder permissions for the files.

 

Groups and Folders

View all groups/folders (RT_GROUP = UI folders). Viewer permission on any object in the folders.

 

Modules

Currently no access via Enterprise.

Form and button access; edit data with adequate facility permission.

Reports

View and run any base report and user report.

 

Widget Types

N/A

 

 

 

Ent-Permissions-Creator-Icon Creator

Object Type

Enterprise Interactions

Professional Only (ALS)

Dashboards

Create new dashboards. Copy existing dashboards.

 

EDDs

Upload new EDD submittals (requires editor permission on the target facility).

 

Facilities

Create new facility (Explorer Dashboard).

Create

Files

Upload files.

 

Groups and Folders

Create new folder (if the user has Owner permissions on the parent folder)

 

Modules

N/A

 

Reports

Create user reports and publish crosstab reports.

 

Widget Types

N/A

 

 

 

Note: Users must have Creator permission on the EDDs Object Type to download or upload EDD files on the EDP EDD Upload Widget. Another example is that users must have Creator permission on the Reports Object Type to save new user reports.

 

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.

 

The one exception to this deny rule is the Enterprise Admin role, which intentionally maintains full access for administrators. The Admin role has owner and creator permission on all object types. EQuIS will ignore Denies for users assigned to the Admin role.

 

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

 

Explicit Permissions

Effective Permissions (excluding any other explicit permissions)

Explicitly grant viewer permission on Folder 1

Inherited Viewer permission on Folder2, Folder3, FacilityA, FacilityB, and FacilityC because explicit folder permission is inherited.

Explicitly grant viewer (or editor or owner) permission on FacilityA

Inherited implicit Viewer permission on all three folders because they all either directly or indirectly contain FacilityA.

No Viewer permission on any of the other facilities (the user would not see those facilities) because users only inherit implicit permission on the folders, not on the objects in the folders.

Explicitly grant viewer permission on Folder2 and

Explicitly deny viewer permission on Folder3

Viewer permission on Folder2 from the explicit grant.

No permission on FacilityA because the deny inherited through Folder3 supersedes the grant inherited through Folder2.

Viewer permission on FacilityB inherited through Folder2.

No permission on FacilityC because the deny is inherited through Folder3.

Explicitly grant viewer permission on Folder3

Add FacilityD to Folder3

Viewer permission on FacilityA inherited through Folder3.

Implicit viewer permission on Folder2 because of FacilityA.

No permission on FacilityB.

Viewer permission on FacilityC inherited through Folder3.

Implicit viewer permission on Folder1 because of explicit permission on Folder3.

Viewer permission on FacilityD (added later) inherited from existing permission on Folder3.

 

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.