Sync Repo-docs-ACCESS-EXTRACTION-PLAN from project files

2026-07-06 21:51:58 +02:00
parent 52d59eaf76
commit aaaa7f0904

@@ -1,4 +1,4 @@
<!-- codex-wiki-sync:270c19e5c534a991015f13f1 --> <!-- codex-wiki-sync:9fa19a3f5487e093da0a378d -->
> Mirrored from `/mnt/DATA/git/govoplan-core/docs/ACCESS_EXTRACTION_PLAN.md`. > Mirrored from `/mnt/DATA/git/govoplan-core/docs/ACCESS_EXTRACTION_PLAN.md`.
> Origin: `repository`. > Origin: `repository`.
@@ -75,9 +75,11 @@ The active implementation still uses core-owned models and services:
- `src/govoplan_core/api/v1/audit.py` - `src/govoplan_core/api/v1/audit.py`
- `src/govoplan_core/db/bootstrap.py` - `src/govoplan_core/db/bootstrap.py`
Core also still hosts WebUI access/admin/auth surfaces. Those should become Core still hosts the generic login/settings shell and shared WebUI primitives.
access/admin module route contributions once the backend ownership split is The legacy administration page has moved to the `govoplan-access` WebUI package
stable. and is contributed as the `/admin` route by the access module. Individual admin
panels can now be split further into access, admin, tenancy, policy, and audit
WebUI contributions without changing the core shell route wiring again.
### Current Module Consumers ### Current Module Consumers
@@ -243,19 +245,33 @@ Acceptance criteria:
Move active identity/access models out of `govoplan_core.db.models`. Move active identity/access models out of `govoplan_core.db.models`.
Current state: the stable table naming strategy is to keep legacy table names
and move SQLAlchemy class definitions under their platform owners. Core keeps
`govoplan_core.db.models` as a compatibility re-export. The earlier
`access_*` candidate tables are not active metadata.
Current table ownership:
- `govoplan-tenancy`: `tenants`
- `govoplan-access`: `accounts`, tenant memberships in `users`, `groups`,
`roles`, role/group assignment tables, `api_keys`, and `auth_sessions`
- `govoplan-admin`: governance templates and assignments
- `govoplan-audit`: audit log
- `govoplan-core`: system settings
Tasks: Tasks:
- Decide the stable table naming strategy. - [x] Decide the stable table naming strategy.
- Map legacy model names to access-owned model classes. - [x] Map legacy model names to access-owned model classes.
- Keep database table names where possible to avoid data migration churn. - [x] Keep database table names where possible to avoid data migration churn.
- Add Alembic migration metadata owned by access. - [x] Add Alembic migration metadata owned by the platform module owners.
- Keep compatibility aliases in core while modules migrate. - [x] Keep compatibility aliases in core while modules migrate.
- Update bootstrap/create-all compatibility paths. - [x] Update bootstrap/create-all compatibility paths.
Acceptance criteria: Acceptance criteria:
- Existing development databases migrate without data loss. - Existing development databases migrate without data loss.
- New databases initialize with access-owned metadata. - New databases initialize with module-owned metadata.
- Core no longer owns live account/user/group/role/session/API-key model - Core no longer owns live account/user/group/role/session/API-key model
definitions except compatibility aliases. definitions except compatibility aliases.
@@ -391,9 +407,12 @@ Acceptance criteria:
- [x] Replace core `create_all` feature-model imports with module registry - [x] Replace core `create_all` feature-model imports with module registry
metadata discovery. metadata discovery.
- [x] Remove transitional boundary checker allowlist entries. - [x] Remove transitional boundary checker allowlist entries.
- [ ] Move legacy admin service and model ownership out of the access - [x] Move live legacy model definitions out of core and into
compatibility implementation into access, tenancy, policy, audit, and core `govoplan-access` while preserving existing table names.
settings modules. - [x] Split the transitional access-owned legacy model graph further into
tenancy, audit, admin, access, and core settings ownership.
- [x] Reverse the tenancy/access dependency direction so `govoplan-access`
depends on `govoplan-tenancy`, and the registry inserts tenancy before access.
- [x] Replace tenancy-to-access default role seeding with an access - [x] Replace tenancy-to-access default role seeding with an access
tenant-provisioner capability. tenant-provisioner capability.
- [x] Replace feature-module direct user/group/tenant model imports. - [x] Replace feature-module direct user/group/tenant model imports.
@@ -402,7 +421,7 @@ Acceptance criteria:
- [x] `govoplan-campaign` - [x] `govoplan-campaign`
- [x] Replace files/mail/campaign direct cross-module SQL lookups with - [x] Replace files/mail/campaign direct cross-module SQL lookups with
provider/capability contracts. provider/capability contracts.
- [ ] Move access admin WebUI pages to module route contributions. - [x] Move access admin WebUI pages to module route contributions.
- [x] Remove transitional boundary checker allowlist entries as each contract - [x] Remove transitional boundary checker allowlist entries as each contract
lands. lands.
- [ ] Move campaign-scoped mail policy ownership fully behind an API/event - [ ] Move campaign-scoped mail policy ownership fully behind an API/event
@@ -413,12 +432,13 @@ Acceptance criteria:
- Is `govoplan-access` required for any authenticated deployment, while - Is `govoplan-access` required for any authenticated deployment, while
core-only remains a diagnostics/settings shell? core-only remains a diagnostics/settings shell?
- Should tenant models move with access first, or should `govoplan-tenancy` be - Tenant models live in `govoplan-tenancy`; `govoplan-access` depends on
created before moving live models? tenancy for authenticated platform composition.
- Which table names must remain stable for painless migrations? - Historical table names remain stable for painless migrations.
- Should secret encryption remain a kernel primitive or become an access-owned - Should secret encryption remain a kernel primitive or become an access-owned
capability? capability?
- Should audit move before policy provenance, or after access/tenancy are split? - Audit log storage lives in `govoplan-audit`; policy provenance can build on
that module boundary.
- How long should core keep compatibility route paths for existing clients? - How long should core keep compatibility route paths for existing clients?
## Verification ## Verification