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

feat: pessimistic check-out locking for CAD files #87

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

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

Implement pessimistic (exclusive) locking so two users cannot simultaneously edit the same part file.

Requirements

Database

  • Add locks table: id, item_id (FK unique), locked_by (user ID), locked_at, expires_at, comment
  • Migration to create the table

API Endpoints

  • POST /api/items/{partNumber}/lock — acquire lock (editor+)
  • DELETE /api/items/{partNumber}/lock — release lock (owner or admin)
  • GET /api/items/{partNumber}/lock — check lock status (viewer+)
  • GET /api/locks — list all active locks (viewer+)

Behavior

  • Lock is exclusive per item — only one user can hold it
  • Locks have a configurable timeout (default 24h), auto-expire after that
  • Write endpoints (PUT /api/items/{partNumber}, POST .../file, POST .../revisions) should reject with 409 Conflict if item is locked by a different user
  • Lock holder can perform all write operations normally
  • Admins can force-release any lock
  • SSE event item.locked / item.unlocked emitted on state changes

Web UI

  • Lock icon indicator on item detail header and item table rows
  • Lock/unlock button on item detail (visible to editors)
  • "Locked by {user} since {time}" tooltip
  • Active locks list accessible from a toolbar or settings page

FreeCAD Integration

  • silo checkout CLI command should acquire lock
  • silo commit should release lock on successful upload
  • silo lock / silo unlock explicit commands
  • Warn if attempting to edit a file locked by another user
Ref: docs/ROADMAP.md § Multi-User Enablement Implement pessimistic (exclusive) locking so two users cannot simultaneously edit the same part file. ## Requirements ### Database - Add `locks` table: `id`, `item_id` (FK unique), `locked_by` (user ID), `locked_at`, `expires_at`, `comment` - Migration to create the table ### API Endpoints - `POST /api/items/{partNumber}/lock` — acquire lock (editor+) - `DELETE /api/items/{partNumber}/lock` — release lock (owner or admin) - `GET /api/items/{partNumber}/lock` — check lock status (viewer+) - `GET /api/locks` — list all active locks (viewer+) ### Behavior - Lock is exclusive per item — only one user can hold it - Locks have a configurable timeout (default 24h), auto-expire after that - Write endpoints (`PUT /api/items/{partNumber}`, `POST .../file`, `POST .../revisions`) should reject with 409 Conflict if item is locked by a different user - Lock holder can perform all write operations normally - Admins can force-release any lock - SSE event `item.locked` / `item.unlocked` emitted on state changes ### Web UI - Lock icon indicator on item detail header and item table rows - Lock/unlock button on item detail (visible to editors) - "Locked by {user} since {time}" tooltip - Active locks list accessible from a toolbar or settings page ### FreeCAD Integration - `silo checkout` CLI command should acquire lock - `silo commit` should release lock on successful upload - `silo lock` / `silo unlock` explicit commands - Warn if attempting to edit a file locked by another user
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#87
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?