rk@tigase.net opened 6 days ago
-
Authorization & Granular Permissions – Time Estimate (Raw)
Assumptions:
- Single experienced engineer
- Full familiarity with Sztab codebase
- Post-PAT authentication already completed
- Focus on backend-first correctness, then UI
Week 2 – Core Authorization (Backend)
Design & schema
- ACL / project_members schema
- Role + visibility enums Estimated: 6–8 hours
Persistence & model wiring
- Entities, repositories
- Flyway migrations
- DB constraints Estimated: 6–8 hours
Authorization engine
- Role → permission mapping
- Centralized access checker
- Deny-by-default logic Estimated: 10–12 hours
Git request validation
- Enforce read/write rules in validate-git-request
- clone / fetch / push coverage Estimated: 6–8 hours
REST API enforcement
- ProjectService
- Issue / PR flows Estimated: 6–8 hours
Testing
- Unit tests
- Targeted integration tests Estimated: 6–8 hours
Week 2 subtotal: 40–52 hours
Week 3 – Team Management UI
Backend endpoints
- Add/remove project members
- Assign roles Estimated: 4–6 hours
UI implementation
- Team member list
- Role assignment
- Visibility indicators Estimated: 8–10 hours
Validation & error handling
- Permission denied flows
- UI feedback Estimated: 4–6 hours
Testing
- Backend + UI sanity tests Estimated: 4–6 hours
Week 3 subtotal: 20–28 hours
Week 4 – Granular Permissions
Protected branches
- Model + enforcement Estimated: 4–6 hours
PR approval requirements
- Required reviewers
- Approval rules Estimated: 4–6 hours
Branch-level permissions
- Push / delete restrictions Estimated: 4–6 hours
Testing
- Regression + edge cases Estimated: 4–6 hours
Week 4 subtotal: 16–24 hours
Total Estimate (3 Weeks)
Low estimate: 76 hours High estimate: 104 hours
Recommended issue estimate: ~90 hours (range: 75–105 hours)
-
Previous Value Current Value Project Access Control & Granular Authorization Model
GitHub-style authorization for Sztab
| Type |
New Feature
|
| Priority |
Normal
|
| Assignee | |
| Version |
none
|
| Sprints |
n/a
|
| Customer |
n/a
|
Issue Votes (0)
Watchers (3)
Summary
After completing PAT-based authentication, Sztab needs a project-scoped authorization model that supports internal teams, community contributors, and anonymous read access — without introducing a separate Git user system.
This issue tracks the design and implementation of project access control, role-based permissions, and GitHub-style granular rules for repositories, branches, and pull requests.
The goal is to ensure that every Git and REST action is validated against explicit project authorization rules.
Three distinct audiences should be catered to: 1. Internal team members (full contributors) 2. Community users (read / PR-only access) 3. Anonymous users (optional public read access)
Examples: Project: my-app (PUBLIC)
Team Members (R/W)
Community (Limited)
Public Access
Private Project (internal-tool) Project: internal-tool (PRIVATE)
Team Members
Everyone Else
Roles (Project-Scoped)
Initial role set (GitHub-style, extensible): • OWNER – full control, permissions, settings • MAINTAINER – merge, manage branches • DEVELOPER – push, create PRs • REVIEWER – review / approve PRs • REPORTER – issues only • GUEST – read-only
Roles are per-project, not global.
Enforcement Points
Authorization must be enforced at every boundary: • Git operations (clone, fetch, push) • PR creation / approval • Branch creation / deletion • REST API access (projects, issues, PRs) • Anonymous access gates
Acceptance Criteria • No Git or REST action succeeds without passing authorization checks • Anonymous access works only for public projects • Role changes take effect immediately • Authorization logic is testable and centrally enforced • Clear audit trail possible (future extension)