[Feature] Configuration package import/export and signed preconfiguration catalogs #208

New Issue

zemion · 2026-07-07T15:01:59+02:00

zemion commented

2026-07-07 15:01:59 +02:00

Problem

GovOPlaN modules can be installed, but a working public-sector process still
requires many coordinated module-owned configurations: workflows, forms, portal
entry points, tasks, mail templates, payment profiles, access roles,
permissions, and interface bindings. Operators need a way to import a trusted
preconfiguration, understand required modules and data, resolve problems before
applying changes, and export a working setup for reuse.

Durable concept: docs/CONFIGURATION_PACKAGES.md
Example catalog shape: docs/configuration-package-catalog.example.json

Proposed Capability

Add configuration packages: signed, versioned preconfigurations that sit above
modules and are imported/exported through typed module provider capabilities.

The system should:

recognize required modules, versions, capabilities, and optional integrations
preflight required configuration and interface bindings before applying
changes
report import/configuration problems with actionable resolutions
collect only the operator data needed for a fully working setup
import module-owned fragments idempotently through provider contracts
export existing configurations with secrets redacted into data requirements
support signed configuration catalogs analogous to module package catalogs
present this as a focused admin wizard and durable help/docs flow

Ownership

Owning repository: govoplan-core
Related module repositories: govoplan-access, govoplan-admin,
govoplan-portal, govoplan-forms, govoplan-cases, govoplan-workflow,
govoplan-tasks, govoplan-templates, govoplan-mail,
govoplan-payments, govoplan-audit
Extension point or integration boundary: configuration-package provider
capabilities, typed DTOs/schemas, module package catalog integration, admin
route/UI contributions, audit events

Core should own orchestration, package/catalog validation, dependency
resolution, generic APIs, and the generic wizard shell. Modules should own
their own fragment schemas, validation, apply/export logic, diagnostics,
redaction, and health checks. Access owns roles, groups, permissions, users,
API keys, and principal-mapping fragments only.

Acceptance Criteria

Define package manifest, catalog, diagnostic, required-data, and provider
DTO schemas.
Add a core configuration.provider capability contract for module-owned
preflight/apply/export/health operations.
Add signed configuration catalog validation using the same trust model as
module package catalogs.
Implement a dry-run import path that detects required modules, missing
capabilities, missing operator data, conflicts, and unsafe changes.
Implement an export path that redacts secrets and turns deployment-local
values into data requirements.
Add an admin import/export wizard that shows modules, configuration,
interfaces, and required data without exposing irrelevant internals.
Implement the first provider for access-owned roles/groups/permission
assignments.
Add follow-up module issues for
workflow/forms/portal/tasks/templates/mail/payments/cases/audit providers as
those modules mature.
Add round-trip tests for export from a configured tenant and import into a
clean tenant.

Verification Target

Validate a signed and unsigned example catalog.
Dry-run an application-handling package and verify required modules, required
data, and diagnostics are shown before apply.
Export a setup, verify secrets are redacted, then import into a clean tenant
and verify provider health checks pass.

## Problem GovOPlaN modules can be installed, but a working public-sector process still requires many coordinated module-owned configurations: workflows, forms, portal entry points, tasks, mail templates, payment profiles, access roles, permissions, and interface bindings. Operators need a way to import a trusted preconfiguration, understand required modules and data, resolve problems before applying changes, and export a working setup for reuse. Durable concept: `docs/CONFIGURATION_PACKAGES.md` Example catalog shape: `docs/configuration-package-catalog.example.json` ## Proposed Capability Add configuration packages: signed, versioned preconfigurations that sit above modules and are imported/exported through typed module provider capabilities. The system should: - recognize required modules, versions, capabilities, and optional integrations - preflight required configuration and interface bindings before applying changes - report import/configuration problems with actionable resolutions - collect only the operator data needed for a fully working setup - import module-owned fragments idempotently through provider contracts - export existing configurations with secrets redacted into data requirements - support signed configuration catalogs analogous to module package catalogs - present this as a focused admin wizard and durable help/docs flow ## Ownership - Owning repository: `govoplan-core` - Related module repositories: `govoplan-access`, `govoplan-admin`, `govoplan-portal`, `govoplan-forms`, `govoplan-cases`, `govoplan-workflow`, `govoplan-tasks`, `govoplan-templates`, `govoplan-mail`, `govoplan-payments`, `govoplan-audit` - Extension point or integration boundary: configuration-package provider capabilities, typed DTOs/schemas, module package catalog integration, admin route/UI contributions, audit events Core should own orchestration, package/catalog validation, dependency resolution, generic APIs, and the generic wizard shell. Modules should own their own fragment schemas, validation, apply/export logic, diagnostics, redaction, and health checks. Access owns roles, groups, permissions, users, API keys, and principal-mapping fragments only. ## Acceptance Criteria - [ ] Define package manifest, catalog, diagnostic, required-data, and provider DTO schemas. - [ ] Add a core `configuration.provider` capability contract for module-owned preflight/apply/export/health operations. - [ ] Add signed configuration catalog validation using the same trust model as module package catalogs. - [ ] Implement a dry-run import path that detects required modules, missing capabilities, missing operator data, conflicts, and unsafe changes. - [ ] Implement an export path that redacts secrets and turns deployment-local values into data requirements. - [ ] Add an admin import/export wizard that shows modules, configuration, interfaces, and required data without exposing irrelevant internals. - [ ] Implement the first provider for access-owned roles/groups/permission assignments. - [ ] Add follow-up module issues for workflow/forms/portal/tasks/templates/mail/payments/cases/audit providers as those modules mature. - [ ] Add round-trip tests for export from a configured tenant and import into a clean tenant. ## Verification Target - Validate a signed and unsigned example catalog. - Dry-run an application-handling package and verify required modules, required data, and diagnostics are shown before apply. - Export a setup, verify secrets are redacted, then import into a clean tenant and verify provider health checks pass.

zemion commented

2026-07-07 22:30:36 +02:00

First configuration-package foundation slice landed. Added govoplan_core.core.configuration_packages with DTOs for package manifests, module requirements, fragments, diagnostics, required data, dry-run plan items, apply/export results, plus the runtime-checkable ConfigurationProvider protocol behind the configuration.provider capability key. Added configuration package catalog load/validate/sign/acceptance helpers with configuration-specific env vars and Ed25519 signature/channel/freshness/replay handling analogous to module package catalogs. Updated docs/CONFIGURATION_PACKAGES.md with the concrete contract and env var surface. Verification: py_compile for configuration_packages.py and tests/test_module_system.py; unittest module catalog adjacency set including test_configuration_package_catalog_validates_signed_entries and test_configuration_provider_contract_is_runtime_checkable; git diff --check. Keeping #208 open for dry-run orchestration, apply/export APIs, the access provider, and the admin wizard.

zemion added the

labels 2026-07-07 23:08:13 +02:00

zemion added the

module/core

label 2026-07-07 23:42:24 +02:00

zemion commented

2026-07-07 23:53:08 +02:00

Implemented the first complete configuration package foundation. Core now has provider-neutral dry_run_configuration_package, apply_configuration_package, and export_configuration_package orchestration, signed catalog validation remains covered, and access registers an access.configuration provider for roles, groups, and group-role assignments. Admin wizard backend endpoints were added under /api/v1/admin/configuration-packages/{catalog,dry-run,apply,export}, with WebUI API helpers. Round-trip smoke coverage applies access fragments into a tenant and exports them again. Focused unit/API tests, py_compile, WebUI build, and diff checks passed.

zemion closed this issue

2026-07-07 23:53:15 +02:00

zemion added the

status

triage

label 2026-07-08 02:12:31 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: add-ideas/govoplan-core#208