Skip to content
English
  • There are no suggestions because the search field is empty.

Permission Overview

PROEVER offers flexible access control tailored to your organization's needs.

Core Concepts

User access rights are determined by combining the following elements:

  • Licenses: Your contracted license plan defines the available features and overall resource limits.

  • Permission Groups: These are units that gather users. Each group is assigned a role, granting access permissions to resources. If needed, you can set permissions directly for specific resources.

  • Roles: These define the scope of operations a user can perform. Each role can be configured by combining four types of operational permissions:

    • Add: Allows creation of new resources.

    • View: Permits viewing of existing resources only.

    • Edit: Allows modification of existing resources.

    • Delete: Permits deletion of existing resources. You can set up custom roles in addition to the default system roles. Roles must be assigned when users are assigned to programs, projects, or tickets.

  • Resources:

    • Program: A unit that groups multiple projects.

    • Project: A unit for individual activities or tasks.

    • Ticket: A unit for recording tasks or issues within a project.
      Note: Attachment permissions are linked to ticket permissions.

Relationship Between Licenses and Permissions

Your license defines the scope of service usage based on your contract. Permissions, on the other hand, define the specific functions each user can access within that service scope.

  • Upper-level Restriction: Your contracted license plan determines the maximum available features and resources across the entire system. For example, if a feature isn't available in your plan, you cannot grant permissions related to that feature.

  • Granting Permissions: You can only grant specific permissions to individual users or roles within the scope allowed by your license.

License Role Actual Access Permission
Edit Edit Edit
View View View
View Edit View (Role Limited)
Edit View View (License Limited)

 

Even if a license grants access permission, you must explicitly grant the corresponding function permissions (Add, View, Edit, Delete) within the role settings to perform actual operations.

Think of it this way: a license defines the "available range", while a role controls "what you can actually do" within that range.

 

How Permissions Work

  • Permission Management with Permission Groups and Roles: Users gain permissions to resources specified by their role through the group they belong to.

  • Private Resource Permission Management: Resources like programs, projects, and and tickets can be made private as needed. For private resources, permissions are granted directly to specific users or groups.

  • Priority Rules:

    • In principle, higher-level permissions are inherited by lower levels.

    • However, you can set individual permissions for lower-level resources if needed.

    • When permissions are at different hierarchical levels, the lower-level permission takes precedence.

      • Example: If a program is editable overall but an individual project within it is set to view-only, then only viewing will be allowed for that project.

    • When permissions are at the same hierarchical level, the broader permission takes precedence.

      • Example: If both edit and view permissions are set for the same project, edit permission applies. However, if permissions are granted collectively to all programs/projects, and then individually to specific programs/projects, the individual program/project permissions take precedence.