Permission Grouping and Role Inheritance

Description

For the MVP, all permissions will be explicitly defined within each role in the default policy file.
Permission grouping and role inheritance will not be implemented at this stage to maintain simplicity and predictability.
In the long term, however, grouping and inheritance are essential to improve maintainability, reduce duplication, and enable scalable management of custom roles.

Problem

• Duplication: Roles currently repeat many of the same permissions, making updates error-prone and harder to maintain.
• Scalability: Without grouping or inheritance, adding new roles or permissions will not scale when introducing custom roles or role management APIs.
• User experience: Administrators will find it difficult to understand or manage large permission sets without hierarchical organization.
• Consistency: Roles with overlapping functionality (e.g., admin and author) cannot share a common base definition, increasing the risk of divergence.

Requirements

• Define a clear stance for the MVP:

  • Permission grouping and role inheritance are out of scope for the MVP.
  • All permissions must be explicitly listed per role in the default policy file.

• Plan a long-term path for:

  • Permission grouping, where high-level actions imply lower-level ones (e.g., manage_library_team includes edit_library and view_library).
  • Role inheritance, where roles can extend other roles (e.g., admin inherits from author).

• Ensure future extensibility by keeping the policy structure compatible with eventual grouping (g2) and inheritance (g) relationships.

• Document how this decision will evolve in post-MVP iterations.

Acceptance Criteria

• The MVP defines all permissions explicitly without relying on implicit grouping or inheritance.
• Authorization checks remain correct and predictable with the explicit model.
• The policy format and loading logic remain compatible with future grouping and inheritance extensions.
• Documentation clearly states the rationale and outlines the planned evolution for post-MVP iterations.

Notes

• This issue is related to Custom Roles and Role Management APIs, since both will depend on grouping and inheritance for scalability.
• Permission grouping and role inheritance will become critical once the system supports dynamic role creation through the Console.

Start by reviewing the default policy file, policy format, and policy loading logic described in the issue. Confirm that MVP roles list permissions explicitly and that authorization checks remain predictable, while documenting compatibility with future grouping and inheritance and the planned post-MVP evolution.