Project - Edit vs Project - Edit Management

Products

• Clarity PPM SaaS

Issue/Introduction

The official documentation description of each:

"Project - Edit": "Allows resource to edit all parts of a project except for Document Management, Calendar, Action Items and Discussions"

"Project - Edit Management": "Allows user to edit the general and management properties, staff and tasks for any project that has been enabled for management. This includes the ability to add sub-projects to that project as well as to edit it in Microsoft Project and Open Workbench. This right also allows the user to create processes on any project and to edit the processes that he or she creates."

Based on documentations, Project – Edit Management historically covers more specific management capabilities, such as working with MSP, Workbench / scheduling features, sub-project management, etc. However, testing of Modern UX, it seems that many (or all) of these capabilities are already available when the user has the Project – Edit right.

 

Could you please confirm whether, in the Modern UX, those management-specific capabilities (MSP integration, scheduling actions, Workbench-related functionality, sub-project handling, etc.) are fully included within Project – Edit? 

 

Or is there any concrete functionality that is still exclusively granted by Project – Edit Management and not by Project – Edit?

 

This confirmation would help correctly design a security model and avoid assigning redundant rights.

Environment

Clarity 16.4.1

Resolution

Project - Edit 

This right is checked at the ODF layer — it governs whether the project record itself can be modified. Specifically:

• Saving project properties (general ODF fields, name, description, OBS, non-management fields)
• The overall "readOnly" flag on the project properties page
• Editing/deleting project notes
• Project dependency/links editing
• Estimating page actions (top-down, bottom-up estimation 

A user with only "Project - Edit" cannot do any of the management-specific operations listed below

Project - Edit Management

This right is checked by specific business-logic services:

• Management-only property fields on the Properties page
  Fields affected include: schedule start/finish, baseline dates, project format, version flag, open/lock flag, charge code, tracking mode, imposed dates, CPM type, as-of date. Without ProjectEditManagement, these render read-only even if the user has "Project - Edit".

• Creating and editing tasks (WBS)
  Clarity uses Project - Edit Management as the authoritative edit policy for tasks. This applies to both the Classic UI and the REST API (the Modern UX task grid calls go through the same delegate).

• Adding and editing team members / staffing
  Clarity explicitly maps Project - Edit Management as the edit policy for project-type investments and Allocation editing.

• Sub-project management (add/remove sub-projects)

• Scheduling: creating and publishing tentative schedules
  Clarity users require Project - Edit Management access right to acquire the scheduler lock and publish

• Auto-schedule publish

• MSP and Open Workbench — write-back (non-read-only open)
  OWB/Scheduler services uses Project - Edit Management to determine whether a project can be opened in read/write mode. The project list for MSP/OWB also marks each project as ReadOnly based solely on Project - Edit Management.

• Project access rights management (staffing access tab)

 

Why the Modern UX Appears to Blur the Boundary

The Modern UX frontend contains no direct references to either Project - Edit or Project - Edit Management — security is enforced entirely on the backend. The reason the distinction appears invisible during testing is likely one or more of the following:

1. Users tested as project managers. When a resource is designated as Project Manager on a project, Clarity automatically assigns them Project - Edit Management at the instance level. A tester who is the PM will have both rights simultaneously, making it appear that "Project - Edit" alone is sufficient.

2. Global right assignment. The "Project - Edit Management - All" global right gives Project - Edit Management on every project the user can view, so a user with this global right plus any ability to view a project can perform all management operations — they aren't relying on "Project - Edit" at all.

3. Separate code paths per area. The Modern UX calls dedicated REST APIs for tasks, team, assignments, etc., each of which is independently secured by the relevant delegate. The system doesn't surface a single "you lack right X" message when permission is denied — it silently disables buttons or returns empty data, which can make it appear that a broader right is responsible.

4. Project - Edit  is primarily a Classic UI concept. The ODF update is a Classic UI mechanism. For the Modern UX project properties, the OData/REST API goes through the ODF object model's edit Instance policy which uses Project - Edit , but this is transparent to the user who just sees a save button that works or doesn't.

Practical Guidance for Least-Privilege Assignment

• Do not assume "Project - Edit" implies "Project - Edit Management" or vice versa. The backend enforces them independently.
• A user who only needs to view and lightly update project metadata (general properties) needs "Project - Edit" (instance) on the specific projects.
• A user who needs to manage the plan (tasks, staffing, schedule, sub-projects, MSP/OWB) needs "Project - Edit Management" — either globally ("All") or per-project.
• A full project manager role requires both rights. Assigning only "Project - Edit Management - All" without an instance or global "Project - Edit" means the user cannot save general property changes via the ODF update service (Classic UI). Assigning only "Project - Edit" means the user cannot manage the plan at all.
• Where roles should be tightly scoped (e.g., a read-only observer who can update a status field but not reschedule), assigning only "Project - Edit" with no "Project - Edit Management" is the correct approach.

To conclude, Neither Right Includes the Other andThey are orthogonal, independent rights.

Additional Information

KB 261211: Secure subpage edit rights without instance edit rights

Secure subpage edit rights without instance edit rights This article explains that in the Classic UX, users cannot edit secure subpage attributes without Project - Edit Management rights, even if they have specific subpage edit rights. This demonstrates the "Management" right's role in governing deeper administrative attributes beyond the standard project shell. 

KB 258079:Rights Required to see all Action menu under Task Timeline View

Rights Required to see all Action menu under Task Timeline View This article specifies that Project - Edit Management is one of the mandatory rights needed to access scheduling actions such as "Create tentative schedule," "Auto schedule," and "Compare to Baseline" within the Task Timeline View.