kindred/silo
1
1
Fork 0
Code Issues 30 Pull Requests Actions Packages Projects Releases Wiki Activity

feat: folder and state-based permissions #89

New Issue
Open
opened 2026-02-14 14:53:09 +00:00 by forbes · 0 comments
forbes commented 2026-02-14 14:53:09 +00:00
Owner
Copy Link

Ref: docs/ROADMAP.md § Multi-User Enablement

Add granular permissions beyond the global role model, allowing control over who can read/write/delete items based on project membership and revision state.

Requirements

Project-Level Permissions

  • Each project can have per-group permission overrides: read, write, admin
  • Users inherit the most permissive grant across their groups
  • If no project-level permission is set, fall back to global role

State-Based Transition Guards

  • Revision status transitions (e.g., draft->review, review->released) can require specific roles or group membership
  • Configurable per-schema via YAML (e.g., only release-approvers group can transition to released)
  • Blocked transitions return 403 with reason

Database

  • Add project_permissions table: project_id, group_id, permission (read/write/admin)
  • Add transition_rules table or embed in schema YAML

API

  • GET /api/projects/{code}/permissions — list permission grants
  • PUT /api/projects/{code}/permissions — set permission grants (project admin)
  • Existing write endpoints check project permissions before global role

Web UI

  • Project settings tab: permission matrix (groups x access levels)
  • Revision status change shows blocked reason if user lacks permission

Dependencies

  • Requires #88 (user and group management) for group-based grants
Ref: docs/ROADMAP.md § Multi-User Enablement Add granular permissions beyond the global role model, allowing control over who can read/write/delete items based on project membership and revision state. ## Requirements ### Project-Level Permissions - Each project can have per-group permission overrides: `read`, `write`, `admin` - Users inherit the most permissive grant across their groups - If no project-level permission is set, fall back to global role ### State-Based Transition Guards - Revision status transitions (e.g., draft->review, review->released) can require specific roles or group membership - Configurable per-schema via YAML (e.g., only `release-approvers` group can transition to `released`) - Blocked transitions return 403 with reason ### Database - Add `project_permissions` table: `project_id`, `group_id`, `permission` (read/write/admin) - Add `transition_rules` table or embed in schema YAML ### API - `GET /api/projects/{code}/permissions` — list permission grants - `PUT /api/projects/{code}/permissions` — set permission grants (project admin) - Existing write endpoints check project permissions before global role ### Web UI - Project settings tab: permission matrix (groups x access levels) - Revision status change shows blocked reason if user lacks permission ### Dependencies - Requires #88 (user and group management) for group-based grants
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
forbes
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kindred/silo#89
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?