Skip to content

project Roles

What is a Project Role?

A project role is grouping of users who have access to a particular project. For e.g. if user has access to Project A but does not have access to Project B, then he/she can only view Project A and will not be able to see Project B.

What are the project roles?

  1. Team Leader : Individual who will be owning the projects. Project timesheets will be approved by team leader. For every project, there has to be team leader.
  2. Team Member : A normal user who can just enter or edit timesheets.

Permission Matrix

Feature Global Administrator Team Leader Team Member
Create Projects ✅ ✅ ❌
Edit Own Projects ✅ ✅ ❌
Edit Any Project ✅ ❌ ❌
Delete Own Projects ✅ ✅ ❌
Delete Any Project ✅ ❌ ❌
View All Projects ✅ ❌ ❌
View Assigned Projects ✅ ✅ ✅
Manage Team Allocation ✅ ✅ ❌
Approve/Reject/Reopen own team Timesheet ✅ ✅ ❌
Approve/Reject/Reopen any team Timesheet ✅ ❌ ❌
Export Own Project Data ✅ ✅ ❌
Export Any Project ✅ ❌ ❌

User Role vs Project Role

User roles determine the maximum project roles that can be assigned to a user. Project roles define specific permissions within individual projects, while user roles control overall application access and capabilities.

User first need to have application/user role in order to be assigned project roles. For e.g. if user is assigned normal User role, then individual can only be assigned a Team Member as a project role. He/she cannot be assigned role of a Team Leader. Similarly if user is assigned user/application role of Project Administrator, then indivdual can be assigned a Team Leader for one project and Team Member in another project. In such a scenario, user will be having Team leader level access for one project and team member level access for another project.

Note

For application/user level permissions, refer to the topic "User Permissions and Roles" under User chapter.

Key Principles

1. Hierarchical Assignment User role determines the ceiling of project roles available to that user.

2. Multiple Project Roles Users can have different project roles across different projects simultaneously.

3. Project-Specific Permissions Project role determines actual permissions within each specific project.

4. Application Prerequisites Must have appropriate user role before any project role assignment is possible.

Role Assignment Matrix

User Role (Application Level) Team Member (Project Role) Team Leader (Project Role)
Normal User ✅ Allowed ❌ Not Allowed
Project Administrator ✅ Allowed ✅ Allowed
Global Administrator ✅ Allowed ✅ Allowed

Legend - ✅ Allowed: Can be assigned this project role - ❌ Not Allowed: Cannot be assigned this project role

Note

Can a team leader of Project A view project B if he/she is not part of project B?

If the individual is having an user/application role of Project Administrator, then he/she can only manage Project A. The individual will not be able to see any details about project B. However, if the individual has user role of Global Administrator, then he/she can view, edit and delete details about both projects A and B.

Permission Flow Process

Step 1: User Role Assignment User is assigned an application-level user role (Normal User, Project Administrator, Administrator)

Step 2: Project Role Eligibility Based on user role limitations, user becomes eligible for appropriate project roles

Step 3: Project Role Assignment User is assigned specific project roles for individual projects within their eligibility

Step 4: Effective Permissions User's effective permissions = intersection of user role capabilities and project role permissions

Note

  1. Role Inheritance: Higher-level user roles can always be assigned lower-level project roles.
  2. Project Scope: Project roles only affect permissions within that specific project.
  3. Cross-Project Flexibility: Same user can have different project roles across multiple projects.
  4. Security Boundary: User role acts as a security boundary preventing privilege escalation through project role assignments.

Practical Examples

Example 1: Normal User

  • User Role: Normal User

  • Available Project Roles: Team Member only

  • Project A: Team Member ✅

  • Project B: Team Member ✅
  • Project C: Team Leader ❌ (Not allowed due to user role limitation)

Example 2: Project Administrator

  • User Role: Project Administrator

  • Available Project Roles: Team Member, Team Leader

  • Project A: Team Leader ✅

  • Project B: Team Member ✅
  • Project C: Team Leader ✅
  • Project D: Team Member ✅

Same user has different levels of access across different projects based on assigned project roles.

Use Cases

Small Organization

  • Most users have Administrator or Project Administrator user roles
  • Flexible project role assignments based on project needs
  • Same person can lead some projects and participate as member in others

Large Organization

  • Clear role hierarchy with many Normal Users
  • Managers and Project Administrators handle leadership responsibilities
  • Strict role boundaries prevent unauthorized access escalation

This matrix ensures proper access control while providing flexibility for project-based work assignments within the Timesheet application.