[Feature] Move access migrations into the access module migration registration #78

Closed
opened 2026-07-06 15:05:30 +02:00 by zemion · 2 comments
Owner

Imported from a backlog-like text file.

  • Source: /mnt/DATA/Nextcloud/ADD ideas UG/Products/govoplan/split-concept-action-plan.md
  • Line: 152
  • Source kind: product
  • Section: GovOPlaN Split Concept and Action Plan > Staged Refactor Plan > Phase 2: Extract Access

Imported item:

Move access migrations into the access module migration registration.
<!-- codex-generic-backlog-fingerprint:8833d36aa4e36a3467a68493 --> Imported from a backlog-like text file. - Source: `/mnt/DATA/Nextcloud/ADD ideas UG/Products/govoplan/split-concept-action-plan.md` - Line: `152` - Source kind: `product` - Section: `GovOPlaN Split Concept and Action Plan > Staged Refactor Plan > Phase 2: Extract Access` Imported item: ```text Move access migrations into the access module migration registration. ```
zemion added this to the Phase 2: Extract Access milestone 2026-07-06 15:05:30 +02:00
zemion added the
type
feature
priority
p2
source/backlog-import
codex/ready
labels 2026-07-07 23:26:03 +02:00
zemion added the
status
triage
label 2026-07-08 02:54:08 +02:00
Author
Owner

Review 2026-07-10: keeping this open. The current core Alembic stream still contains ownership-mixed historical migrations: alembic/versions/b57c5b216bce_initial_persistence_models.py creates tenancy_tenants, access_groups, access_roles, access_users, access_api_keys, and audit_log; later core migrations still alter/read access_* and tenancy_tenants tables, for example 2c3d4e5f6a7b_auth_sessions_and_rbac.py, 8c9d0e1f2a3b_accounts_tenant_admin_rbac.py, and a0b1c2d3e4f5_permission_catalogue_refinement.py. This should wait for a release migration baseline/squash instead of rewriting old production history in-place. Close condition: release baseline documents the ownership boundary and module-owned DDL is represented by module baselines going forward.

Review 2026-07-10: keeping this open. The current core Alembic stream still contains ownership-mixed historical migrations: `alembic/versions/b57c5b216bce_initial_persistence_models.py` creates `tenancy_tenants`, `access_groups`, `access_roles`, `access_users`, `access_api_keys`, and `audit_log`; later core migrations still alter/read `access_*` and `tenancy_tenants` tables, for example `2c3d4e5f6a7b_auth_sessions_and_rbac.py`, `8c9d0e1f2a3b_accounts_tenant_admin_rbac.py`, and `a0b1c2d3e4f5_permission_catalogue_refinement.py`. This should wait for a release migration baseline/squash instead of rewriting old production history in-place. Close condition: release baseline documents the ownership boundary and module-owned DDL is represented by module baselines going forward.
Author
Owner

Codex State: done

Summary

  • Access migrations are owned by the access module manifest.
  • The active access manifest registers MigrationSpec(module_id='access') with AccessBase.metadata and its own backend/migrations/versions script location.
  • Core still has historical compatibility reconciliation paths, but new access-owned migrations live under govoplan-access.

Verification

  • manual inspection of govoplan-access backend manifest and migration tree
## Codex State: done ### Summary - Access migrations are owned by the access module manifest. - The active access manifest registers MigrationSpec(module_id='access') with AccessBase.metadata and its own backend/migrations/versions script location. - Core still has historical compatibility reconciliation paths, but new access-owned migrations live under govoplan-access. ### Verification - `manual inspection of govoplan-access backend manifest and migration tree`
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: add-ideas/govoplan-core#78
No description provided.