Permission inheritance should be configurable by project owners

[mdrkrg]

Pre-submission checklist

• I have searched for existing open or closed issue reports with the same problem.

Description

Problem

Note: This is more of a design choice rather than an actual bug.

Currently, when a sub-project is created or moved under a parent project, permissions are automatically inherited from parent projects using a widening-only approach:

• If a user has Read access to a parent project, they automatically get Read access to all children
• If they have Write access to a parent, they get Write access to all children
• Permissions can only widen, never shrink - there's no way to create a "private" sub-project under a "shared" parent

This is currently enforced at the code level in pkg/models/project_permissions.go using a recursive CTE that traverses up the project hierarchy and uses MAX() aggregation to determine the highest permission found.

Current Behavior Example

1. User creates a private project P1 (only they have access)
2. User creates sub-project P2 under P1
3. User shares P1 with Team A (Read access)
4. Team A members now automatically have Read access to P2 (widened from parent)

There's no way to prevent this inheritance. The sub-project automatically inherits and widens parent permissions.

Available Options

Option 1: Explicit Inheritance on Creation

Copy parent permissions to child project at creation time, then manage independently.

• Pros: Explicit, auditable access; child can have different permissions than parent
• Cons: Complex (must copy both user + team permissions); requires migration for existing projects

Option 2: Remove Inheritance Entirely

Only direct permissions on a project matter. Parent permissions have no effect.

• Pros: Simplest implementation; clear model
• Cons: Loses hierarchical permission benefit entirely; re-parenting doesn't grant access

Option 3: Configurable Inheritance Mode

Add an inheritance_mode field to projects with options:

• inherit (default): Current widening behavior

• explicit: No automatic inheritance - only permissions directly assigned to the project

• Add other options to widen or shrunken if needed

• Pros: Backward compatible; project owners choose their preferred behavior

• Cons: Requires new DB field and migration

Option 4: Replace on Re-parent

When moving a project to a new parent, replace child's permissions entirely with parent's.

• Pros: Explicit - permissions always match current parent
• Cons: Overwrites manually configured permissions on child

Recommendation

Option 3 provides the best balance by:

• Maintaining backward compatibility for existing projects
• Allowing project owners to opt into stricter behavior for new projects
• Being a non-breaking change

Vikunja Version

811e5ef

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

Yes

Screenshots

No response

[kolaente]

You've (or more like Claude) explained possible approaches, but why do you want to have this feature?

[mdrkrg]

Imagine a meta project that contains multiple sub-projects as different parallel phases. Intuitively the meta project should be shared among all members to inform them of what's going on, but often there would be some need for having an internal project only visible to a subset of the members.

The current implicit widening permission model would not allow for such usage. We would have to create this internal project at top level, but that would break the mental model of this project being a sub-project.