feat(groups): application groups (data, admin, user grouping) [BUNYIP-100 1/2] #145
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/bunyip-100-application-groups"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
BUNYIP-100, PR 1 of 2. User-facing application groups so apps that are really one product (e.g. Mokosh = mokosh-server + mokosh-apps + ...) render together. PR 2 will add the unified per-card download affordance and retire the public Downloads page.
Layers
Data - new
application_groupstable + nullableapplications.group_idFK (ON DELETE SET NULL, so deleting a group ungroups its members).ApplicationGroupmodel + repository;group_idthreaded ontoApplicationandApplicationResponse.Assignment - a dedicated
ApplicationRepository::set_group, deliberately separate from the sharedupdate. That method COALESCEs every column and is called with partial bodies (e.g. anis_activetoggle), so it can neither cleargroup_idto NULL nor be trusted to leave it untouched. A directSET group_id = $1both sets and clears.API - admin CRUD under
/v1/admin/application-groups, app assignment viaPUT /v1/admin/applications/{id}/group, and a publicGET /v1/application-groups(display metadata only) the web layer uses to group apps.Web admin - a Groups management page (list / create / edit / delete) and a Group selector on the application edit form, posting to the dedicated set-group endpoint.
Web user - the Applications page renders apps under their group heading (groups in
sort_order), with an "Other" section for ungrouped apps. With no groups defined it falls back to the previous flat grid. The card markup is extracted into anapp_cardhelper shared by both paths.Verification
just check-containergreen: fmt, clippy-D warnings, and 224 workspace lib tests (api 19, domain 186, oci 9, oidc 9). Not exercised here: the live request flow and the migration apply, which need the running stack.Heads-up
This and the BUNYIP-99 surface-tags PR (#142) both touch
application_formand the admin applications list inbunyip-web/src/handlers/admin.rs; expect a small merge conflict to resolve when the second of the two merges.#BUNYIP-100
BUNYIP-100 PR 1 of 2. Adds user-facing application groups so apps that are really one product (e.g. Mokosh = several apps) render together. Data: new `application_groups` table and a nullable `applications.group_id` FK (ON DELETE SET NULL, so removing a group ungroups its members). `ApplicationGroup` model + repository, and `group_id` threaded onto `Application` and `ApplicationResponse`. Assignment uses a dedicated `ApplicationRepository::set_group` rather than the shared `update`: that method COALESCEs every column and is called with partial bodies (e.g. an is_active toggle), so it can neither clear group_id nor be trusted to leave it untouched. API: admin CRUD under `/v1/admin/application-groups`, app assignment via `PUT /v1/admin/applications/{id}/group`, and a public `GET /v1/application-groups` (display metadata only) the web layer uses to group apps. Web admin: a Groups management page (list / create / edit / delete) and a Group selector on the application edit form, posting to the dedicated set-group endpoint. Web user: the Applications page renders apps under their group heading (groups in sort order), with an "Other" section for ungrouped apps. With no groups defined it falls back to the previous flat grid. The card markup is extracted into an `app_card` helper shared by the grouped and ungrouped sections. Verified: `just check-container` green (fmt, clippy -D warnings, 224 lib tests across the workspace). Not exercised here: live request flow and migration apply, which need the running stack. Note: this and the BUNYIP-99 surface-tags PR both touch `application_form` and the admin applications list; expect a small merge conflict in admin.rs to resolve when the second of the two merges. #BUNYIP-100 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>