Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 38 Next »

In this article:



Permission Filters and Hierarchy of Privileges

New installations of eplansoft REVIEW are pre-configured with permission settings based on best practices.

Users with an 'Administrator' user role have global access (full privileges) to all REVIEW functionality.

For other user roles, making changes to the default settings may be necessary for view, edit, update and delete privileges of projects, documents and versions, plan review assignments and reviewer comments.

The hierarchy of the Permission filters are shown in the diagram, right.

Permission Filter Hierarchy

Permission Filter Definitions

Global access

This is the least restrictive permission filter. It provides access to data records not dependent on Project team membership. The Administrator user role is granted global access privileges throughout the application.

Project member

Provides access to Projects based on Project team membership. Users who create new projects are automatically made project team members.

Group member

This filter provides access based on project membership and group membership.

  • For users who conduct plan review, the Assignments Page is preconfigured to display unfinished assignments based on project team membership and group membership.
  • Individuals in the Group Manager role typically require edit and delete rights to manage comments, stamps and sketches for staff members within their Group(s).

Own(er)

This is the most restrictive permission filter. It provides access to data records created by the individual, personally.


Best Practices

Notify staff members to logout, clear their cache and login again after permission settings have been changed.



User Role Definitions

User roles determine the permissions for an account within EPR. Since permissions are configured at the user role level, all users with the same role will have the same permissions.

Each User Role is pre-configured with default permissions to match the role's typical expected tasks within EPR, but many role permissions can be adjusted by the Admin. The Admin cannot rename the User Role labels, however.


User RoleDescription
Admin

The Admin role is tasked with assisting in the initial configuration of the EPR portal. This user can update portal configurations that affect permissions, assignment workflow, email, and even portal branding as needed. The Admin can also manager user accounts within EPR.

The Admin role can also perform the functions of every other user role in EPR, including project creation, assignment intake, plan review, and packaging deliverable back to applicants.

Project Coordinator

The Project Coordinator is usually reserved for intake staff/permit technicians.

The main responsibilities for these users are to:

  • Create plan review tasks (“assignments”) for reviewers
  • Update assignment tasks or reassign, as needed.
  • Prepare corrections report letters (typically)
  • Prepare deliverable packages of marked-up or approved plans to send back to applicants at the end of a review cycle.

When all review assignments have been given an approved, rejected, or canceled status, Project Coordinators will be notified so they can prepare a Corrections Report letter with all reviewer feedback and then package files to return to the applicant, either through email or, more commonly, through check-in to an integrated portal.

Reviewer

The Reviewer (or "plan checker", "plans examiner", etc.) is responsible for completing plan review tasks (“assignments”) made either for them specifically or for their Group. Typically, this consists of adding comments and/or marking up issues found on the plans. At the end of a review cycle, they must provide a status - either an approval or rejection - for their assignment task. Reviewers can also create Corrections Report letters, if desired.

The Reviewer role is not configured to perform intake of plans or prepare deliverable packages to send back to an applicant – for this functionality, see Project Coordinator.

Group Manager

The Group Manager is like a Reviewer, but can edit and delete markups created by other reviewers within his or her Group.

A Group Manager cannot edit or delete markups for another Group unless they also belong to the other Group.

Project Manager

The Project Manager is like a Reviewer, but can edit and delete markups created by other reviewers within the project he or she is managing.

A Project Manager cannot edit or delete markups for another Project unless they also manage that Project.

Contributor

A licensed user who has been granted access to view and respond to comments made by Reviewers in one or more projects.


Contributors are prevented from functioning as Plan Reviewers and cannot be granted permissions to the Review page.

The Contributor Role Explained

The Contributor user role is provided for clients who want to invite external customers, or partners, onto a project team for the purpose of collaborating with the plan reviewers.

Contributors do not have access to the Review page and may not conduct reviews. Instead, these individuals can:

  • Become members of a project team. This provides the contributor with project access, as shown below (steps 1-3):

  • View comments made by plan reviewers for those projects (4), apply filters (5) and check whether any are flagged by reviewers as priority comments (6).

  • Respond to comments made by the plan reviewers in a secure, user friendly web page (7-11).

    

    

   

 

  • Download the marked up documents if those privileges have been granted.
  • View the marked up documents using a PDF viewer, such as Adobe Reader.


NOTE: While comments are visible to contributors once they become a project team member, the ability to respond to a comment is controlled by the reviewer who creates the comment ("Response Enabled" feature). At any point during the plan review, if a Contributor is granted access to a project then they will be able to view and respond to comments concurrently with the remainder of the review cycle. Comments added by contributors are placed below the most recent version of the reviewer's comment, and if reviewers update their comment then this updated version will display below the contributor's comment to maintain the chronology of the conversation as clear as possible. Contributor project access can be revoked, if desired, by an agency Admin at any time by removing the user from the project team.



Best Practices for Configuring Permissions for Project Access

Choosing whether to use the default permission filter settings that grant users project member access or to grant users Global Access to projects should be determined before go live.

When the permission filters are set Project Team member, users who open the Projects page will only see records for projects in which they are a project team member as opposed to all projects that may exist globally. In the same manner, users who open the Assignments page will only see open assignment records for projects in which they are a team member, as opposed to open assignments that may exist globally. 

Additionally, project and assignment related email notifications configured in the User's record will also be sent based on project membership or Global Access. 

Choosing whether to set the permission filters to Global Access or Project Member access is your choice.



Permission Dependencies for Project records

The Project Workflow Process

For project team members who participate in one or more processes described below, their user roles require the appropriate view, add, edit and optionally delete permissions, to the following entities shown below.


   

Project Team Membership

  • When a plan review assignment is given to a specific user, that individual automatically becomes a project member.
  • Users who add projects automatically become project members.
  • Administrators are automatically granted membership to all projects.


At minimum, all user roles should have view privileges for Project Management.


Best practices

Project Managers, Group Managers, Reviewers and Contributors should have View privileges as project Team Members. This ensures that users can see their 'own projects', but not projects they are not team members of.



Permissions Dependencies for Plan Review

Plan Review Workflow Process

For project team members who conduct plan review or who manage plan review staff, their user roles require, at minimum, View permissions to Project Management.

permissions to the entities shown in the diagram below, right:


  




Default Permissions for the Review Page

Best practices for project team members who conduct plan review via the Review Page are shown in the screen shot below. Modify the settings as desired.

Note the typical settings for Group Managers and Reviewers.

.


The Contributor user role cannot be granted permission to the Plan Review page. Instead, Contributors may view/download the marked up documents and view/respond to comments for projects they have membership in. Contributors login into a simplified user interface.



Default Permissions for Project Comments

Best practices for team members privileges on the Project Comments Page are shown in the screen shot below. Modify the settings as desired. Note the typical settings for Group Managers and Reviewers and Contributors.

At minimum, permissions to view comment details is required in order to open the Project Comments page.



Default Permissions for Comment Responses

Best practices for team members privileges on the Project Comments Responses Page are shown in the screen shot below.

Modify the settings as desired.

Step-by-step guide

Follow these steps to modify permission settings:

  1. Select Security/Permissions from the Navigation panel
  2. Drill into the appropriate module
  3. Toggle the View, Add, Edit and Delete checkboxes and choose the appropriate filter for the desired User Role(s)
  4. Click Save (required).

Notify staff members to logout, clear their cache and login again if permission settings have been changed.


The Default Permission screen shots above will be helpful if you want to restore the settings to their original (best practices) configuration.







  • No labels