User access rights can be used to limit the access of users to data as per their unique requirements. This support article explains how to configure user access rights using examples based on common scenarios.
Basic Concepts
1. In eResource Schedule, you will hear the term 'user/s' and 'resource/s' on a regular basis, these terms CANNOT be used interchangeably. To achieve flexibility in user access rights, users and resources are technically different.
'User' is an individuals who can access the system using his login ID and password.
'Resource' can be an employees, contractor or a non-human asset like equipment, meeting room that can be scheduled against projects in eResource Scheduler.
Note: A user can also be added as a resource in the system but it's not necessary, there can be people who are users or not scheduled on projects. Similarly, a resource can also be made a user but it's not necessary, there can be employees who are scheduled on projects in eResource Scheduler but do not have access to the system.
2. Adding a user does not automatically add a resource and vice-versa.
3. Depending on requirement, a user can have access to one particular resource or several different resources or a group (E.g. all resources in a team or department) of resources.
4. For flexibility, access rights for once screen do not have any impact on access right of another screen. It's possible that user has not been given access to one screen but has full access to all data on another screen. Access rights for every screen need to be defined separately.
5. When a new user is added, by default he does not have access to any screen or data. Administrator needs to define access rights of new users before they can start using the system.
6. There can be any number of admin users, no restrictions.
7. Users with administrative access can modify their own access rights and access right of other users.
8. Users with billing section can modify all subscription settings.
9. 'Full Access' implies user can view, add, edit and delete data. 'Read Access' implies user can view but cannot add, edit or delete data. 'No Access' implies that user cannot even view data.
Overview of Access Rights Concepts
Requirement Based Examples
We will use examples to demonstrate how user access rights can be configured as per common scenarios. These videos will clarify basic concepts and will enable administrators to configure their own unique scenarios.
Example 1:
User: John Smith
Access Requirement: Should have full access to all the data on all the screens along with administrative and billing rights.
Example 2:
User: John Smith
Access Requirement: Should have full access to all the data on all the screens along with billing rights, but should not have administrative access.
Example 3:
User: John Smith
Access Requirement:
- Scheduling Chart: Should have read access (view) to schedule of resource 'John Smith', but should not be able to access schedule of any other resource.
Example 4:
User: John Smith
Access Requirement:
- Scheduling Chart: Should have read access (view) to schedule of resource 'John Smith', but should not be able to access schedule of any other resource.
- Timesheet Entry: Should be able to log actual time spent by resource 'John Smith' on different projects. Should not have access to timesheet of any other resource.
Example 5:
User: John Smith
Access Requirement:
- Resource Screen: Should have full access (add, edit, delete) to information of resource 'John Smith', but should not be able to access information of any other resource.
- Scheduling Chart: Should have access to Read (view) schedule of resource 'John Smith', but should not be able to access schedule of any other resource.
Example 6:
User: John Smith
Access Requirement:
- Resource Screen: Should have full access (add, edit, delete) to information of resource 'John Smith', but should not be able to access information of any other resource.
- Scheduling Chart: Should have access to Read (view) schedule of resource 'John Smith', but should not be able to access schedule of any other resource.
- Timesheet Entry: Should be able to log actual time spent by resource 'John Smith' on different projects. Should not have access to timesheet of any other resource.
Example 7:
User: John Smith
Access Requirement:
- Resource Screen: Should have read access (view only) to information of all the resources, but should have full access (add, edit, delete) to information of resource 'John Smith'.
- Scheduling Chart: Should have read access (view only) to schedule of all the resources, but should have full access (add, edit, delete) to schedule of resource 'John Smith'.
- Timesheet Entry: Should be able to log actual time spent by resource 'John Smith' on different projects. Should not have access to timesheet of any other resource.
Example 8:
User: Eric Duncan
Access Requirement:
- Resource Screen: Should have full access (add, edit, delete) to information of all the resources that are based in New York. Should not have access to view information of resources based out of New York.
- Scheduling Chart: Should have full access (add, edit, delete) to schedule of all the resources that are based in New York. Should not have access to schedule of resources based out of New York.
- Timesheet Approval: Should be able to approve & reject time entries submitted by resources that are based in 'New York'. Should not have access to time entries of resources based out of New York.
- Reports: Should be able to view following reports for resources based in 'New York'...
- Timesheet Report
- Planned Utilisation
- Planned vs Actual Utilisation
- Planned Availability
- Planned vs Actual Availability
Assumption: Resources have been grouped according to cities they are based in, using a custom field 'City'.
Example 9:
User: Eric Duncan
Access Requirement:
- Resource Screen: Should have read access (view) to information of resources based out of New York. Should have full access (add, edit, delete) to information of all the resources that are based in New York.
- Scheduling Chart: Should have read access (view) to schedule of resources based out of New York. Should have full access (add, edit, delete) to schedule of all the resources that are based in New York.
- Timesheet Approval: Should be able to approve & reject time entries submitted by resources that are based in 'New York'. Should not have access to time entries of resources based out of New York.
- Reports: Should be able to view the following reports for all the resources, irrespective of their city.
- Timesheet Report
- Planned Utilisation
- Planned vs Actual Utilisation
- Planned Availability
- Planned vs Actual Availability
Assumption: Resources have been grouped according to cities they are based in, using a custom field 'City'.
Example 10:
User: Eric Duncan
Access Requirement:
- Resource Screen: Should have full access (add, edit, delete) to information of all the resources that are based in New York. Should not have access to view information of resources based out of New York.
- Rates Screen: Should have full access to billing and cost rates of all the resources that are based in New York. Should not have access to view rates information of resources based out of New York and should not have access to define rates for roles and projects.
- Scheduling Chart: Should have full access (add, edit, delete) to schedule of all the resources that are based in New York. Should not have access to schedule of resources based out of New York.
- Timesheet Approval: Should be able to approve & reject time entries submitted by resources that are based in 'New York'. Should not have access to time entries of resources based out of New York.
- Reports: Should be able to view following reports for resources based in 'New York'...
- Timesheet Report
- Planned Utilisation
- Planned vs Actual Utilisation
- Planned Availability
- Planned vs Actual Availability
- Planned Financials
- Actual Financials
- Planned vs Actual Financials
Assumption: Resources have been grouped according to cities they are based in, using a custom field 'City'.