Files
summercms/.planning/phases/12.1-user-plugin-admin-screens/deferred-items.md
Jakub Zych 93f0171e9c docs(12.1-05): security review and validation sign-off for Phase 12.1
- 12.1-SECURITY-REVIEW.md: every threat T-12.1-01 to T-12.1-40 and T-12.1-SC with its mitigation, test and observed result; T-12-18 revisited; the D-30 guard and its boundary; the eleven handed-over items; five findings that need a decision
- 12.1-VALIDATION.md: per-task map with real task ids and measured run times, signed off
- deferred-items.md: older framework files that name an application
2026-10-05 16:13:50 +02:00

5.4 KiB

Phase 12.1 deferred items

Deferred Items

  • Two inventory tests of the application's fonoteka plugin module fail against the framework at v0.1.3 status: resolved Resolved: plan 12.1-04, 2026-10-05, fonoteka.go commit ca746fc (phase09AdminRoutes names the bulk action and record action routes; phase10ListMessageKeys names the three row-state messages). The form half of TestPhase10ControllerCopy reads named keys only and needed no change. Found: plan 12.1-02 Task 6, 2026-10-05, by running go -C ../fonoteka.go/plugins/golem15/fonoteka test ./... -count=1 in addition to the plan's gate. What: TestPhase09SecurityRoutes (admin_phase09_security_test.go) reports the two plan 01 routes POST .../{controller}/bulk/{action} and POST .../{controller}/{id}/actions/{action} as unexpected, because the fixed list phase09AdminRoutes does not name them. TestPhase10ControllerCopy (admin_phase10_copy_test.go) compares the list messages with the fixed list phase10ListMessageKeys, which lacks rowStateDeleted, rowStateNegative and rowStateDisabled; its form half was not reached and may need preview and edit the same way. Why not fixed here: the fix is two fixed lists in the application repository (fonoteka.go); plan 12.1-02 writes to summercms.go only. No framework change is needed, so the tagged commit is not affected. The same catch-up was done once before (549840d test(13-06): list the Phase 12.2 cabana admin routes in the Phase 9 route inventory). Why the gate missed it: the plan's application gate go -C ../fonoteka.go test ./... -count=1 runs the root module only; the go.work plugin modules (plugins/golem15/{user,fonoteka,golem,feedback}) are separate modules and are not matched by ./.... Suggested owner: plan 12.1-04 (it already writes the application's parity allow-list entry and submodule pointer) or plan 12.1-05's gate script, which should run every workspace module.

  • Four more application tests fail once the user plugin registers its admin screen, its three migrations and the FrontendPermission model status: resolved Resolved: plan 12.1-04, 2026-10-05, fonoteka.go commit b35442a (developer navigation [fonoteka user], with the publisher still seeing neither; expectedUserModels = 7, because plan 04 also registers the UsersGroup pivot; the user plugin's history has ten migrations) and 35a727f (the golem15_user_frontend_permissions allow-list entry). Each failure was checked to be the fixed list and not a defect before the list changed. Found: plan 12.1-03 Tasks 1 and 3, 2026-10-05. The application's go.work uses the plugin's working tree, so these fail as soon as the plugin commits exist, before any submodule pointer bump. What: (1) TestAdminMetadataFiltering (plugins/golem15/fonoteka/admin_metadata_test.go) expects the developer role's navigation to be exactly [fonoteka]; it is now [fonoteka user], because the four Winter permission codes of the user plugin default to the developer role (D-02, D-04). (2) TestMigrateSeedsCanonicalGenres and TestRollbackLastIsolatesFonoteka (parity/migrate_test.go) compare the user plugin's migration history with a fixed id list, which lacks 202610040001_add_users_permissions, 202610040002_add_users_last_seen and 202610040003_create_frontend_permissions. In history order (by id) the first of them sorts before the shipped 202610040001_create_user_api_tokens. (3) TestHiddenNeverMarshals (plugins/golem15/fonoteka/classes/hidden_marshal_test.go) pins expectedUserModels = 5; the user plugin now registers six models (FrontendPermission is new). With the constant at 6 (checked through a go test -overlay copy, nothing written to the repository) the test passes, so the marshalling checks themselves hold for the new model and the new User fields. Already known, same run: TestSchemaMatchesPHPSnapshot reports the new table golem15_user_frontend_permissions until plan 04 adds its allow-list entry (stated in the 12.1-03 plan). Why not fixed here: all of them are fixed lists or counts in the application repository (fonoteka.go). Plan 12.1-03 commits only inside the plugin checkout. Effect on plan 12.1-03's own verify: the command go -C ../fonoteka.go test ./plugins/golem15/fonoteka -run '^(TestAdmin|TestPhase09|TestPhase10|TestPhase12Threats)' cannot be green before plan 04: it matches TestAdminMetadataFiltering and the two tests of the entry above. Every other test that pattern selects passes. Suggested owner: plan 12.1-04, together with the entry above.

  • Thirteen framework Go files outside Phase 12.1 name a consuming application status: open Found: plan 12.1-05 Task 3, 2026-10-05, when the hygiene stage of scripts/check-phase12.1.sh was first pointed at the whole modules tree. What: grep -rlniE for the two application names over modules --include=*.go lists 13 files, all tests or comments of older modules (for example modules/tide/capture_test.go and modules/wristband/authorize_test.go). None was added or changed by Phase 12.1. Why not fixed here: out of this phase's scope: the hygiene stage covers the files Phase 12.1 added or changed, the root README, every module README, docs, admin/src and admin/tests, and those are clean. Renaming fixtures in other modules' tests belongs to those modules. Suggested owner: a quick task, or the next phase that touches each module.