Fine-Grained Access Control (FGAC) Design Proposal

[mcassaniti]

This proposal expands on the discussions in #3298 and #3299 by moving from coarse 4-tier permissions to a compact, bitmask-based Fine-Grained Access Control (FGAC) system. This is a proposal, and I'm hoping to get a discussion around the backend model first before implementing. After that we can tackle any frontend details.

---

1. Database Storage & Project Access Model

In Vikunja, project sharing is mapped through users_projects (user shares), team_projects (team shares), link_sharings (public shares), and direct ownership (projects.owner_id):

• projects Table: Add use_fine_grained_acls BOOLEAN DEFAULT false.
• users_projects, team_projects, link_sharings Tables: Add fine_grained_acls BIGINT UNSIGNED DEFAULT 0.

Read Access Rule (Project Access)

• Row Existence = Project Read Access: The presence of a record in users_projects or team_projects grants Project Read Access (canRead = true). A user with a mapping row can fetch and view the project and all its task properties.
• fine_grained_acls = 0: Represents Read-Only Project Access (0 field write bits set, writable_fields: []).
• fine_grained_acls > 0: Grants Project Read Access + specific attribute write permissions (writable_fields: [...]).

---

2. Permission Hierarchy & Inheritance

Permissions are resolved hierarchically using Bitwise OR (|), creating an additive permission model:

effective_acls = user_acls | team_acls_1 | team_acls_2 | parent_project_acls

• Additive Model: A user receives a field write permission if any assigned role, team, or parent project grants that bit.
• Coarse-Grained Fallback: When use_fine_grained_acls is false for a project, standard 4-tier permission levels map to default bitmasks:
  • PermissionRead (0): 0x0
  • PermissionUpdate (1): TaskFieldState | TaskFieldComments
  • PermissionWrite (2): All defined task field bits enabled (TaskWriteAllBits), granting full write access to all task attributes without project admin rights.
  • PermissionAdmin (3): 0xFFFFFFFFFFFFFFFF (All 64 bits enabled as a universal wildcard).
• Forward Compatibility (WriteAll Dynamic Expansion):
  • To prevent administrative burden when updating Vikunja, permissions configured with full task write access (TaskWriteAllBits) automatically inherit write access to newly introduced task field bits in future software versions.
  • TaskWriteAllBits is dynamically evaluated as the Bitwise OR of all registered task field bits in the running version.

---

3. PATCH-Based API Semantics (/api/v2)

Currently, task updates send full task payloads. Under FGAC, task mutations transition to PATCH /api/v2/tasks/{id} HTTP semantics:

1. Partial Body Validation:

   • The backend unmarshals only the fields explicitly present in the PATCH JSON body.
   • Permission authorization checks Task.CanUpdateField ONLY for the fields included in the request payload.

2. Targeted Forbidden Responses (All Failed Fields):

   • If a user sends a payload containing multiple fields they lack permission to modify, the API evaluates all patched fields and returns a single 403 Forbidden response listing all unauthorized fields:

     {
       "code": 403,
       "message": "You do not have permission to update fields: due_date, priority",
       "unauthorized_fields": [
         "due_date",
         "priority"
       ]
     }

3. API Capability Export:

   • /api/v2 endpoints export permission capabilities as a list of strings so frontend Vue components and external clients know which fields can be patched:

     {
       "id": 42,
       "title": "Migrate Database Schema",
       "due_date": "2026-08-15T00:00:00Z",
       "writable_fields": [
         "state",
         "title",
         "description",
         "due_date",
         "comments"
       ],
       "is_admin": false
     }

---

4. DB Query Impact & Performance Analysis

FGAC permission validation takes place in Go memory using project-level bitmask caching (map[int64]uint64), avoiding un-indexable bitwise SQL queries.

Use Case	Execution Model	DB Query Impact
Bulk Project ACL Resolution	checkPermissionsForProjects (Recursive CTE in pkg/models/project_permissions.go)	Evaluates BIT_OR(...) per project. Zero row-level overhead.
Task Search & Filtering	dbTaskSearcher.Search (pkg/models/task_search.go)	Scoped by project ID (WHERE tasks.project_id IN (...)). Zero bitwise SQL WHERE clauses.
Task Collection Loading	TaskCollection.ReadAll (pkg/models/task_collection.go)	Loads full task rows. Computes writable_fields array per task payload in Go.
Kanban Bucket Moves	TaskBucket.CanUpdate (pkg/models/kanban_task_bucket.go)	Validates bitmask.CanUpdateField(TaskFieldState) in Go memory.
Task Mutation Validation	Task.CanUpdate (pkg/models/tasks_permissions.go)	Compares modified struct fields against effective bitmask in Go memory.

---

5. Suggested Mapping of Permission Bits

Bits 0 through 63 are reserved strictly for feature and field write capabilities. 0xFFFFFFFFFFFFFFFF represents Admin / Full Access:

Bit Position	Enum Constant	Covered Attributes / Capabilities
1 << 0 (1)	TaskFieldState	Completion status (done, done_at) and bucket transitions (bucket_id).
1 << 1 (2)	TaskFieldTitle	Task title / summary.
1 << 2 (4)	TaskFieldDescription	Rich-text description.
1 << 3 (8)	TaskFieldDates	due_date, start_date, end_date.
1 << 4 (16)	TaskFieldPriority	Priority level and task color.
1 << 5 (32)	TaskFieldAssignees	Adding or removing assignees.
1 << 6 (64)	TaskFieldLabels	Adding or removing labels.
1 << 7 (128)	TaskFieldAttachments	Uploading or deleting file attachments.
1 << 8 (256)	TaskFieldComments	Adding comments.
1 << 9 (512)	TaskFieldReminders	Setting reminder triggers.
1 << 10 (1024)	TaskFieldRelations	Subtasks and task relationships.

---

6. API Data Visibility & UI Enforcement

• Full API Data Return (Read vs. Write):
  • Read Visibility: Governed at the project level (a user with project read permission can fetch and view all task properties). Fine-grained ACLs do not redact or hide fields from the API payload.
  • Write Mutability: Governed by writable_fields: []string. The API returns all task properties alongside the writable_fields list.
• UI Responsibility:
  • The frontend uses writable_fields to render non-writable task attributes in read-only mode (e.g. static labels, disabled datepickers, read-only text fields) so users can view details without being given edit controls. An empty field may be omitted if not writeable and empty.
  • Action buttons (e.g., Delete Task, Move Project, Share Project) remain hidden if the corresponding capability is omitted.

[mcassaniti]

@kolaente I'd very much like your feedback on this. If it's insufficient in its current state then let's work together on getting something suitable.

[kolaente]

I see this as having two tiers:

1. fine-grained permissions per entity. This would allow setting things like "can read comments" "can read attachments" "can write attachments" etc per user with the existing read/write levels. Would not apply only to tasks.
2. per field permissions for the task. Essentially what you proposed here, but I wouldn't implement it with a bit shift because that makes it pretty hard to filter via database queries. And we're not exactly running Vikunja on a microcontroller so that we need to squeeze ever last bit of performance out of it.

Either of those is a pro feature on the roadmap. It will take time though because these are delicate features that have a huge blast radius if things go wrong.

I'll be off on vacation until 2026-08-17, will check back after that.

[mcassaniti]

Thanks for the feedback. I'll see what I can come up with while you're away. I'll be making some assumptions about what per entity permissions means, so I'm likely to need to roll some things back.

[mcassaniti]

Below is the second attempt at fine grained permissions and includes an inheritance model which will be needed if permissions are getting this fine grained to the task level. I did have AI assist in finding the edge cases and to make things clearer. Yes it's long and detailed, but it needs to be long and detailed.

---

Fine-Grained Access Control (FGAC) Design Proposal - v2

1. Executive Summary & Design Principles

This v2 design proposal defines the Fine-Grained Access Control (FGAC) architecture for Vikunja, addressing the above feedback and establishing performant, relational database storage with robust permission rules.

Core Principles

1.1 Universal Project Read Baseline:

• Any member of a project can view all tasks and related entities (comments, attachments, relations, labels, reminders, time_entries, views). Resources are never hidden or redacted from project members.

1.2 Unified Capability Allow-List Table (resource_write_allowed):

• All write/mutation capabilities (both task attributes like due_date and related entity actions like comments, attachments, or project_labels) are stored in a single, clean resource_write_allowed table.
• Row presence = write permission. Absence of a capability row means it remains read-only. Supports an ALL wildcard capability for full write access.

1.3 Simplified Project Administration (is_admin BOOLEAN):

• Pre-existing coarse permission enums (Read, Write, Admin) are replaced with a single is_admin BOOLEAN flag on resource_acls. Project Admins have universal write/configuration access across all project capabilities. Non-admin write capabilities are resolved via resource_write_allowed.

1.4 Additive-Only Permission Model with Boolean Inheritance Breaking:

• Explicit DENY rules are intentionally avoided in favor of an additive-only (Union / MAX) model combined with a boolean break_inheritance flag.

1.5 Hard-Coded Owner Invariance:

• Project Owners (projects.owner_id) and Instance Admins (users.is_admin = true) are hard-coded Admins at the top of all permission check routines. They retain full Admin rights across all projects and tasks under their ownership, regardless of ACL tables or inheritance settings.

1.6 Auto-Seeding Admin ACLs on Inheritance Break:

• When a non-owner user (who derived Admin access via parent project share or team membership) sets break_inheritance = true on a child project or task, the backend automatically seeds an explicit resource_acls row for that acting user with is_admin = true. This prevents accidental access lock-outs.

---

2. Relational Database Schema

-- 1. Primary Resource ACL Table (Header)
-- Note: The presence of a source actor record in resource_acls implicitly grants read access to the resource.
CREATE TABLE resource_acls (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    
    -- Target Entity
    resource_type VARCHAR(20) NOT NULL, -- 'project', 'task' (links are subjects, not targets)
    resource_id BIGINT NOT NULL,        -- project_id or task_id

    -- Source Actor
    subject_type VARCHAR(20) NOT NULL,  -- 'user', 'team', 'link'
    subject_id BIGINT NOT NULL,         -- user_id, team_id, or link_id

    -- Simplified Project Admin Flag
    is_admin BOOLEAN DEFAULT false NOT NULL,

    -- Inheritance Control Flag
    break_inheritance BOOLEAN DEFAULT false NOT NULL,

    created DATETIME NOT NULL,
    updated DATETIME NOT NULL,

    UNIQUE INDEX idx_res_subj (resource_type, resource_id, subject_type, subject_id),
    INDEX idx_subj_lookup (subject_type, subject_id),
    INDEX idx_resource_lookup (resource_type, resource_id)
);

-- 2. Unified Resource Write Allowed Table (Allow-List)
-- Presence of a row explicitly allows writing/mutating capability_name. Absence = Read-Only.
CREATE TABLE resource_write_allowed (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    resource_acl_id BIGINT NOT NULL,     -- FK to resource_acls.id
    capability_name VARCHAR(50) NOT NULL, -- 'ALL' (wildcard full write), Task fields, Entity actions, or Project capabilities

    UNIQUE INDEX idx_acl_capability (resource_acl_id, capability_name)
);

Complete Inventory of Capability Names

(Note: Capabilities are context-aware. If a capability doesn't apply to the resource level it's granted on—e.g., granting project_labels on a single task ACE—it is safely ignored during evaluation.)

Category	Capability Name	Granted Write/Mutation Action	Read Behavior (When Absent)
Wildcard	ALL	Full write access to all task attributes, entity actions, and project capabilities.	Controlled by fine-grained entries
Task Lifecycle	create_task	Creating new tasks within a project.	Cannot create tasks
Task Lifecycle	delete_task	Deleting tasks within a project.	Cannot delete tasks
Task Field	state / done	Toggling task completion and moving kanban buckets.	Readable
Task Field	title	Modifying task title text.	Readable
Task Field	description	Modifying rich text description.	Readable
Task Field	due_date	Modifying task due date.	Readable
Task Field	dates	Modifying start date, end date.	Readable
Task Field	priority	Modifying priority level and task color.	Readable
Task Field	assignees	Adding or removing task assignees.	Readable
Task Field	labels	Adding or removing task labels.	Readable
Entity Action	comments	Posting new comments or deleting owned comments.	Read existing comments
Entity Action	attachments	Uploading or deleting task file attachments.	Download/view attachments
Entity Action	relations	Adding or removing subtasks and task dependencies.	View subtasks/relations
Entity Action	reminders	Adding or editing task reminder alerts.	View reminders
Entity Action	time_entries	Logging time or editing time tracking entries.	View logged time
Entity Action	views	Creating, updating, or deleting saved project views/buckets.	View project views/buckets
Project Scope	project_labels	Creating, editing, or deleting project-level labels.	View project labels

---

3. Read Access & UI Enforcement Rules

3.1 Project Membership = Universal Read Visibility

• Rule: Any user with project access can view all tasks and sub-resources within that project. Fine-grained ACLs govern write/mutation capabilities (resource_write_allowed).
• Task Inheritance Break Read Invariant: If a task within a project has break_inheritance = true, the task remains fully readable by all project members. Setting break_inheritance = true halts write ACL inheritance from parent containers, but does not hide or redact the task from project members. The alternative is hiding tasks when break_inheritance = true, which can create confusion and is not user-friendly.

3.2 Sub-Project Listing Invariant (File System Traversal Model)

• Rule: If a parent project is readable, its child projects are always listed in the project tree, even if break_inheritance = true on the child blocks full read traversal into its contents.
• API Impact:
  • The legacy MaxPermission model will be removed entirely, as permissions are now granular.
  • The /api/v2/projects endpoint must be updated to yield child projects of accessible parents rather than fully filtering them out.
  • The models.Project API structure will introduce a new can_read boolean flag. Restricted child projects will be returned with can_read = false.
  • To prevent data leakage, projects returned with can_read = false will have their embedded sub-resources (like views and buckets) omitted from the API payload.
• Web UI Impact: The frontend sidebar will consume the can_read flag. It will render the names of restricted child projects (keeping the filesystem-like tree intact), but display them as visually distinct (e.g., disabled/greyed out) and prevent navigation into them.
• Alternative: Hiding child projects entirely when break_inheritance = true is possible, but it creates a confusing UX where users cannot see the existence of sub-projects they cannot access. The filesystem traversal model is likely more intuitive.

3.3 UI ACE Editor Requirements

• In the frontend Access Control Entry (ACE) editor, Read must be rendered permanently selected/checked and disabled (non-removable).
• Rationale: Creating an ACE row for a source actor implicitly grants Read access. Making the Read checkbox non-removable in the UI makes this behavior clear and intuitive to administrators.

---

4. Rationale: Deny ACLs vs. Additive Model with Boolean Inheritance Breaking

A key architectural question when designing access control is whether to introduce explicit DENY rules (e.g. ALLOW vs. DENY permissions).

Core Assumption: Under the assumption that explicit DENY rules take precedence first over all ALLOW rules across all inheritance levels (a common standard in access control systems like AWS IAM), we evaluate the trade-offs below.

Theoretical Benefits of Deny ACLs

• Allows an administrator to explicitly block a specific user or team from performing an action on a child resource without creating a separate team or breaking inheritance for all other users.

Pitfalls & Complexity of Deny ACLs (Even with Deny Precedence)

1. Unintended Side-Effects Across Teams:
   • Because DENY takes precedence over all ALLOW grants, if User A is granted direct ALLOW write access to Project P, but User A is also added to Team X which has a DENY write on Project P, Team X's DENY instantly strips User A's explicit personal permission.
   • Joining a team can silently revoke permissions a user previously held elsewhere, creating confusing and non-deterministic side-effects for administrators.
2. Auditability & "Why Can't I Edit This?" Troubleshooting:
   • Troubleshooting why a user is blocked requires scanning all parent containers and all team memberships for any active DENY rule. A single DENY buried deep in a team share overrides all explicit grants.
3. Severe Database Query Performance Penalties:
   • In database-driven permission filtering (such as filtering tasks in SQL via XORM), evaluating DENY precedence first requires executing negative existence queries (NOT EXISTS subqueries or LEFT JOIN ... WHERE IS NULL) across all team memberships and parent project levels.
   • This destroys SQL index performance and prevents simple recursive CTE batching.

Why a Boolean break_inheritance Flag is Superior

• Strictly Additive (Union / MAX): Without DENY rules, permissions are calculated simply by taking the Logical Union of all granted capabilities across direct user shares, team memberships, and parent containers. Permissions can only grow as you traverse the graph.
• Controlled Scope Break: When a sub-project or task requires restricted access, setting break_inheritance = true halts parent hierarchy traversal. The child resource starts with a clean slate, granting access only to the explicitly specified subjects.
• Deterministic & High-Performance SQL: Allows standard SQL JOINs and indexes without costly negative subqueries or ambiguous precedence side-effects.

---

5. Permission Evaluation & Inheritance Rules

Hard-Coded Owner Gate

Every permission check evaluates Owner & Instance Admin status before querying ACL tables:

// Standard evaluation entrypoint in pkg/models/
func (p *Project) CheckPermission(s *xorm.Session, a web.Auth, requiredPerm Permission) (bool, error) {
    // 1. Hard-coded Instance Admin gate
    if isInstanceAdmin(s, a) {
        return true, nil
    }

    // 2. Hard-coded Owner gate
    u := &user.User{ID: a.GetID()}
    if p.isOwner(u) {
        return true, nil // Owners are ALWAYS full Admins
    }

    // 3. Resolve FGAC via resource_acls table & inheritance tree
    return p.resolveResourceACL(s, u, requiredPerm)
}

Inheritance Breaking & Non-Owner Seeding Logic

// Toggling break_inheritance on a project or task
func SetBreakInheritance(s *xorm.Session, a web.Auth, resourceType string, resourceID int64, breakInheritance bool) error {
    // 1. Verify acting user currently has Admin access
    canAdmin, err := CheckResourceAdmin(s, a, resourceType, resourceID)
    if err != nil || !canAdmin {
        return ErrGenericForbidden{}
    }

    // 2. Fetch project/resource details
    project, err := GetProjectByID(s, resourceID)
    if err != nil {
        return err
    }

    // 3. If breaking inheritance and acting user is NOT the project owner, auto-seed Admin ACL
    if breakInheritance && project.OwnerID != a.GetID() {
        err = SeedExplicitAdminACL(s, resourceType, resourceID, a.GetID(), true /* is_admin */)
        if err != nil {
            return fmt.Errorf("auto-seeding admin acl: %w", err)
        }
    }

    // 4. Update break_inheritance flag
    return SaveResourceBreakInheritance(s, resourceType, resourceID, breakInheritance)
}

---

6. Detailed Example: Traversal & Permission Resolution Walkthrough

To demonstrate how the resolution algorithm handles multi-level hierarchies, multi-team memberships, task-level ACE overrides, and break_inheritance flags, consider the following scenario:

Scenario Setup

[ Root Project P1 ] (Top Level)
       │
       ▼
[ Child Project P2 ] (break_inheritance = true)
       │
       ▼
[ Sub-Child Project P3 ] (break_inheritance = false)
       │
       ▼
  [ Task 101 ] (break_inheritance = false)

• User: Alice (member of Team A and Team B).
• Target Operation: Alice sends PATCH /api/v2/tasks/101 requesting to update the due_date field.
• Resource ACL Assignments:
  1. Root Project P1:
     • Team A: is_admin = false, resource_write_allowed: ['title', 'description'] (does not include due_date).
     • Team B: is_admin = false, resource_write_allowed: ['due_date', 'priority'].
  2. Child Project P2:
     • break_inheritance = true (Halts traversal up to P1).
     • Team A: is_admin = false, resource_write_allowed: ['title'].
     • Team B: No ACL entry on P2.
  3. Sub-Child Project P3:
     • break_inheritance = false. No explicit ACL entries on P3.
  4. Task 101:
     • break_inheritance = false.
     • User Alice (Direct User ACE): is_admin = false, resource_write_allowed: ['priority'] (does not include due_date).

---

Step-by-Step Traversal Execution

flowchart TD
    Start[User Alice requests write on Task 101 due_date] --> Step1[Step 1: Task 101 ACL Check]
    
    Step1 -->|Direct User ACE on Task 101| Accum1["Accumulated Capabilities: ['priority']\n(break_inheritance = false)"]
    Accum1 --> Step2[Step 2: Move to Container Project P3]
    
    Step2 -->|No ACLs on P3| Accum2["Accumulated Capabilities: ['priority']\n(break_inheritance = false)"]
    Accum2 --> Step3[Step 3: Move to Parent Project P2]
    
    Step3 -->|Team A ACE on P2| Accum3["Accumulated Capabilities: ['priority', 'title']\n(break_inheritance = true)"]
    Accum3 --> Stop{"P2 break_inheritance = true?"}
    
    Stop -->|YES: HALT TRAVERSAL| Result["Final Writable Capabilities: ['priority', 'title']\nRoot P1 (Team B with due_date) IGNORED"]
    Result --> AuthFail["Check 'due_date' in ['priority', 'title'] -> FORBIDDEN (403)"]

Loading

Detailed Execution Log

1. Step 1 — Hard-Coded Owner / Admin Check:
   • Check if Alice is Project Owner or Instance Admin. Result: False (proceed to ACL resolution).
2. Step 2 — Evaluate Target Task 101:
   • Query resource_acls for resource_type='task', resource_id=101.
   • Match found for User Alice (Direct ACE): resource_write_allowed contains ['priority'].
   • Accumulated writable capabilities: ['priority'].
   • Task 101 break_inheritance flag: false. Continue traversing up to container Project P3.
3. Step 3 — Evaluate Container Project P3:
   • Query resource_acls for resource_type='project', resource_id=P3.
   • No explicit ACLs found for Alice, Team A, or Team B on P3.
   • P3 break_inheritance flag: false. Continue traversing up to parent Project P2.
4. Step 4 — Evaluate Parent Project P2:
   • Query resource_acls for resource_type='project', resource_id=P2.
   • Match found for Team A (Alice's team): resource_write_allowed contains ['title'].
   • Team B is not shared on P2.
   • Accumulated writable capabilities (Logical Union): ['priority'] ∪ ['title'] = ['priority', 'title'].
   • Project P2 break_inheritance flag: true.
   • HALT TRAVERSAL! Traversal stops immediately at P2. Root Project P1 is never queried, so Team B's write access to due_date on P1 is completely ignored due to P2's inheritance break.
5. Step 5 — Final Authorization Evaluation:
   • Effective writable capabilities set for Alice on Task 101 = ['priority', 'title'].
   • Requested patch field due_date is NOT present in the effective set.
   • Outcome: Authorization fails! API returns 403 Forbidden with payload {"unauthorized_fields": ["due_date"]}.

---

7. Open Questions for Maintainer Review

Assignee state Capability UX

When a project member is assigned to a task but lacks the explicit state capability (meaning they cannot mark the task as "done"), it creates a UX friction point. Two primary solutions are presented for maintainer decision:

A. Frontend Warning & Explicit Grant

• When a manager assigns a user who lacks the state capability, the UI displays a warning: "This user does not have permission to change the task status."
• Trade-off: If the manager wants to fix this, the UI flow must decide where to place the new ACE (at the Task level, Project level, etc.), introducing complex permission management directly into the task assignment flow.

B. Backend Implicit Rule (Zero Friction)

• The backend permission evaluator enforces a hard-coded implicit rule: "If a user is currently an Assignee on a task, they implicitly possess the state capability for that specific task."
• Trade-off: Bypasses the explicit FGAC database tables for this one specific edge case, but perfectly aligns with user expectations (if you are assigned to a task, you can close it).

Rejected Option (UI Filtering): We strongly advise against filtering the Assignee dropdown UI to only show users who already possess the state capability. This leads to user confusion ("Why is Bob missing from the assignee list?"), and causes severe performance degradation, as the backend would need to resolve the full FGAC inheritance tree for every project member against the specific task just to render a dropdown.

[mcassaniti]

Nudging @kolaente for another review

[kolaente]

I think we're too early to talk about implementation details. Let's take a step back:

What do you want to achieve with the end result? What should it look like from an end user perspective? What non-technical problem are you trying to solve? Why?

Also, please read this: https://gruhn.me/blog/2026-08-03/

[mcassaniti]

I have no intention of being a meat proxy. The AI and I did work hard on why deny ACLs for example were not a good idea. I do think file system like ACLs are intuitive enough from an administrator perspective, so that was my guidance. I also pushed and guided the detailed example so the inheritance model was clear. I know it has that AI verbosity in the response text, and that I can work on.

Issue/problem: Vikunja has a 3 tier permission model of read-only, read-write everything and admin and it is rather course.
My use case: Allow a user who has had a task assigned to them the right to mark the task done. They should probably also be able to add comments, but that is not a hard requirement.
Previous attempt: Have a four tier permission model (#3298, #3299) but this was rejected and responded with "The proper solution is fine-grained permissions". I do agree.

This is a fine grained permission proposal with a worked example, no bitmaps/bit-shifts as requested. It limits writing fields but does not limit reading fields. It's a proposal so I'm more than happy to adjust it based on the requirements for Vikunja.

What I don't have is an understanding of what your requirements are or what you'd like to see in practice. Without that or some practical examples to work from I'm left to fill in the blanks. I don't mind doing that, but I think that's the source of issues. Let's start with what's wrong with my proposal (I'm sure it has problems), and let's work out what it should do instead. If you can give me some bullet points to work from I can flesh out a design with the design caveats highlighted.