Orgs App — Change Log¶
This log tracks software changes for this area.
Current status¶
| Item | Status | Notes |
|---|---|---|
| Active development | Open | Core structure stable, services + APIs implemented, policy layer introduced |
| Next release target | TBA | Policy adoption completion + audit visibility |
| Known risk | Medium | Central dependency for all apps (tenant isolation critical + policy consistency) |
Recent changes (newest first)¶
| Date | Type | Summary | Impact | Reference |
|---|---|---|---|---|
| 2026-04-14 | Refactor | Introduced policy-based authorization layer for org capabilities | High | core.policies.orgs |
| 2026-04-14 | Refactor | Migrated membership service permission checks to policy layer | High | orgs.services.membership |
| 2026-04-14 | Test | Added full policy test suite for org capabilities | High | tests/core/test_policies_orgs.py |
| 2026-04-14 | Feature | Added audit logging to org membership services (role change, activate/deactivate, create/update) | High | services/membership |
| 2026-04-14 | Feature | Added membership management APIs (role update, activate, deactivate) | High | views |
| 2026-04-14 | Test | Extended test suite with audit log validation and edge cases | Medium | tests/orgs |
| 2026-04-13 | Feature | Added service layer for organization & membership logic (listing, membership resolution, safety checks) | Medium | services/orgs.py |
| 2026-04-13 | Feature | Added member listing endpoint (/orgs/members/) |
Low | views |
| 2026-04-13 | Feature | Added serializer layer for orgs and memberships (list + role resolution) | Low | serializers |
| 2026-04-13 | Refactor | Standardized org access via HasCurrentOrg permission |
Medium | core.permissions |
| 2026-04-13 | Refactor | Improved query efficiency using select_related("user") in member endpoints |
Low | views |
| 2026-04-13 | Test | Added full pytest suite for org services, views, and permissions | Medium | tests/orgs |
| 2026-04-13 | Fix | Resolved duplicate membership constraint issue in tests | Low | tests |
Open items and status¶
| ID | Title | Status | Priority | Owner | Target | Reference |
|---|---|---|---|---|---|---|
| ORGS-001 | Add org detail/update endpoints (CRUD for org settings & branding) | Open | P2 | Unassigned | TBA | |
| ORGS-004 | Add audit log listing endpoints (history UI support) | Open | P2 | Unassigned | TBA | |
| ORGS-005 | Add customer link management endpoints | Open | P2 | Unassigned | TBA | |
| ORGS-007 | Add caching for effective_settings / effective_branding | Open | P2 | Unassigned | TBA | |
| ORGS-008 | Add pagination + filtering for members endpoint | Open | P2 | Unassigned | TBA | |
| ORGS-009 | Add invite-to-membership integration | Open | P1 | Unassigned | TBA | |
| ORGS-010 | Complete migration to policy-based authorization across all org flows | Open | P1 | Unassigned | TBA |
Completed items¶
| ID | Title | Date | Notes |
|---|---|---|---|
| ORGS-002 | Add membership management APIs | 2026-04-14 | Role update + activate/deactivate |
| ORGS-003 | Enforce "at least one owner" constraint in services | 2026-04-14 | Fully enforced in service layer |
| ORGS-006 | Introduce org-level permission abstraction | 2026-04-14 | Implemented via core.policies.orgs |
Known bugs¶
| ID | Symptom | Severity | Status | Workaround | Reference |
|---|---|---|---|---|---|
| BUG-ORGS-001 | Duplicate membership creation in tests triggers unique constraint | Low | Fixed | Use get_or_create | |
| BUG-ORGS-002 | Missing org header causes inconsistent 403/400 responses | Medium | Open | Ensure HasCurrentOrg is applied |
|
| BUG-ORGS-003 | Deep org trees may cause unexpected inherited settings overrides | Low | Open | Inspect parent chain manually |
Breaking changes and migrations¶
| Date | Change | Action required | Reference |
|---|---|---|---|
| 2026-04-14 | Membership updates must go through service layer (audit enforced) | Do not update OrgMembership directly | |
| 2026-04-14 | Introduced policy-based permission layer | Replace direct role checks with policy helpers | core.policies.* |
| 2026-04-13 | Introduction of service layer for org logic | Use services instead of direct ORM | |
| 2026-04-13 | Standardized org context via request.org | All endpoints must rely on org context |
Notes¶
1. Policy-based authorization is now introduced¶
The orgs app has moved from:
- direct role checks (
role == "admin")
to:
- capability-based authorization via policy layer
Examples:
- can_manage_org_members
- can_view_org_members
- can_manage_org_settings
Benefits: - centralized logic - easier evolution of roles - safer tenant isolation
2. Orgs app is the authorization backbone¶
This app is now responsible for:
- user ↔ organization relationships
- role assignment
- permission resolution (via policies)
- audit logging of membership changes
It acts as the root authority layer for all other apps.
3. Audit logging is enforced at service level¶
All membership mutations now produce audit logs:
- role changes
- activation / deactivation
- creation / updates
Important: - logs originate from services - views must never bypass services
4. Owner safety rules are enforced¶
Critical invariant: - organization must always have ≥1 active owner
Protected against: - role downgrade - deactivation
This is a P0 rule for tenant integrity.
5. Remaining risk: partial policy adoption¶
Although the policy layer exists:
- not all apps may fully use it yet
- some legacy role checks may remain
This creates risk of: - inconsistent authorization - hidden permission gaps
6. Next logical step¶
- Complete policy migration across all apps
- Add audit log query endpoints
- Add pagination/filtering
- Integrate invites into membership flow
7. Long-term direction¶
- Move toward capability-based system
- Introduce RBAC/ABAC hybrid
- Add org feature flags
- Expand CustomerLink into full tenant bridging system
This change log reflects the transition:
➡️ org modeling
➡️ service layer
➡️ API layer
➡️ audit + governance
➡️ policy-based authorization (current phase)
➡️ next: system-wide policy adoption + observability