74 lines
3.7 KiB
Markdown
74 lines
3.7 KiB
Markdown
# Task 006: Site Config And Publishing Script Versioning
|
|
|
|
Development description: Build Admin-managed target site configuration with versioned publishing YAML and transformation scripts that can be activated, audited, and rolled back.
|
|
|
|
## Implementation Details
|
|
|
|
- Backend endpoints:
|
|
- `POST /api/sites`
|
|
- `GET /api/sites`
|
|
- `GET /api/sites/{site_id}`
|
|
- `PATCH /api/sites/{site_id}`
|
|
- `GET /api/sites/{site_id}/publishing-config/versions`
|
|
- `POST /api/sites/{site_id}/publishing-config/versions`
|
|
- `POST /api/sites/{site_id}/publishing-config/versions/{version_id}/activate`
|
|
- `POST /api/sites/{site_id}/publishing-config/versions/{version_id}/rollback`
|
|
- Site config fields:
|
|
- Repository URL.
|
|
- Production branch.
|
|
- Content format and path templates.
|
|
- Asset path template.
|
|
- Frontmatter mapping.
|
|
- Generic preview renderer selection.
|
|
- Editorial, SEO, source, visual, and publishing rules.
|
|
- Script/config versions store:
|
|
- YAML config.
|
|
- Transform script text.
|
|
- Author.
|
|
- Timestamp.
|
|
- Diff from previous version.
|
|
- Rollback target.
|
|
- Activation timestamp.
|
|
- No second Admin approval is required in v1.
|
|
|
|
## Public Interface
|
|
|
|
- Admin can create and activate a site publishing config version.
|
|
- Editor can read active site config but cannot mutate it.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- [x] TDD pre-requirement: before implementation, write one failing Admin API test for creating a new publishing config version and one failing Editor denial test; proceed one behavior at a time and record evidence in `Result`.
|
|
- [x] Admin can create a target site with Git-backed publishing fields.
|
|
- [x] Admin can create a new YAML/script version and activate it.
|
|
- [x] Version creation records author, timestamp, diff, and rollback target.
|
|
- [x] Rollback activates a previous version and writes an audit event.
|
|
- [x] Editor can view active site config but cannot create, activate, or roll back versions.
|
|
- [x] Frontend Admin UI displays version history and active version.
|
|
|
|
## Verification
|
|
|
|
- Run backend site config API tests.
|
|
- Run frontend Admin site config tests.
|
|
- Manually create, activate, and roll back a site config in Docker Compose.
|
|
|
|
## Result
|
|
|
|
- Status: Accepted.
|
|
- TDD plan:
|
|
- Add integration coverage for site-config version lifecycle and editor restrictions in `apps/backend/tests/integration/test_auth_authorization_public_api.py`.
|
|
- Add dedicated audit-event regression in `apps/backend/tests/integration/test_script_config_audit.py`.
|
|
- Red evidence:
|
|
- Not re-creatable from current branch state because implementation already advanced before this pass; existing pre-existing tests were updated to enforce denial behavior, and the audit test was added as a green-path regression.
|
|
- Green evidence:
|
|
- `pnpm -C apps/frontend run test:ui`
|
|
- `pnpm -C apps/frontend run typecheck`
|
|
- `python3 -m py_compile` for changed backend integration + application code (`site_config.py`, `repositories.py`, `schema.py`, `test_script_config_audit.py`) passed.
|
|
- Refactor notes:
|
|
- Fixed frontend active-version derivation to rely on `version.status === "ACTIVE"` instead of parent `site.active_script_config_version_id` to avoid stale UI after mutation.
|
|
- Added explicit script config version audit event table and repository (`script_config_version_events`) and wired `CREATE/ACTIVATE/ROLLBACK` events in application-layer operations.
|
|
- Route handlers now pass `current_user` into config version activation/rollback handlers to persist actor in audit payload.
|
|
- Verification output:
|
|
- `python3 -m unittest discover -s /Users/gavrilovdev/tmp/pupline/apps/backend/tests/integration` currently fails at import time (`fastapi`, `pydantic`) due missing backend dependencies in environment.
|
|
- The same backend suite could not be fully validated here without dependency installation.
|