Correct reports and operator queue breadcrumbs and flush attachment/report cards #102

Open
opened 2026-09-08 17:34:51 +02:00 by zemion · 1 comment
Owner

Campaign-global Reports and Operator queue currently receive singular campaign-detail breadcrumbs. The Global attachments and Campaign reports available to you tables do not occupy their complete cards.

Acceptance: global routes show Campaigns > Reports / Operator queue, campaign-specific reports retain their editor trail, deep links and guarded back navigation remain correct; both table surfaces declare the shared table card layout, including loading; EN/DE user/admin docs and regressions. Shared formatter and geometry remain in Core; no mail delivery or live campaign mutation.

Coordinated with GovOPlaN/govoplan-core#300.

Campaign-global Reports and Operator queue currently receive singular campaign-detail breadcrumbs. The Global attachments and Campaign reports available to you tables do not occupy their complete cards. Acceptance: global routes show Campaigns > Reports / Operator queue, campaign-specific reports retain their editor trail, deep links and guarded back navigation remain correct; both table surfaces declare the shared table card layout, including loading; EN/DE user/admin docs and regressions. Shared formatter and geometry remain in Core; no mail delivery or live campaign mutation. Coordinated with https://git.add-ideas.de/GovOPlaN/govoplan-core/issues/300. <!-- govoplan-navigation-layout-20260908-govoplan-campaign -->
zemion added the
type
bug
priority
p1
status
in-progress
labels 2026-09-08 17:34:51 +02:00
Author
Owner

Implemented global Reports/Operator queue breadcrumb corrections and explicit table-card bodies for Global attachments and aggregate reports. Follow-up at the user's exact 3085px viewport showed that removing Recipient(s)/Delivery caps alone allowed oversized initial columns, while the remaining custom-field maxWidth=360 blocked both their growth and neighbouring-column shrink compensation. Added Core preferredMaxWidth for automatic fitting only, mapped Recipient(s)=640, Delivery=480 and custom fields=360; manual resize and compensation can exceed these preferences, while true hard maxWidth contracts remain intact. Actual selected campaign/version verified: Recipients640→1040→890, Delivery480→880→730, all three custom fields293.84→693.84→543.84px, and every width survives reload. Delivery is present in the DOM and visible in a fresh authenticated session with Templates/Postbox loaded; the user's pre-existing session disappearance remains unreproduced. No module condition was removed or configuration overwritten. Also defer initial recipient/global-attachment grids until the real version/draft exists: loading-only column signatures were overwriting browser-stored widths on reload. EN/DE documentation updated. No campaign content, mail operations, or DB changes.

Verification after the ultrawide follow-up: 33 focused real-browser cases passed, including 3085px three-field recipient grids, two-way pointer/keyboard resizing, right-scroll-boundary shrink with stable handle/scroll position, width persistence, Delivery visibility, table-card desktop/mobile/loading geometry, navigation and EN/DE dashboard cancellation/save-and-leave. Actual authenticated 5173 campaign/version at 3085px also passed all five columns' grow/shrink/reload checks with zero campaign writes or JavaScript errors. Sizing unit regressions, strict conformance TypeScript, 27 Campaign documentation/navigation tests, final 72/72 manifest/architecture checks, and the final full-product production build with bundle-budget checks passed. The earlier full 243-case browser suite passed before this follow-up. The broad workspace gate completed its backend and focused frontend unit stages, but was deliberately interrupted during the optional-module build matrix after the user reported the ultrawide problem; do not treat that full gate as completed. Local implementation only: no commit, tag, push, release, or issue closure in this slice.

Implemented global Reports/Operator queue breadcrumb corrections and explicit table-card bodies for Global attachments and aggregate reports. Follow-up at the user's exact 3085px viewport showed that removing Recipient(s)/Delivery caps alone allowed oversized initial columns, while the remaining custom-field maxWidth=360 blocked both their growth and neighbouring-column shrink compensation. Added Core preferredMaxWidth for automatic fitting only, mapped Recipient(s)=640, Delivery=480 and custom fields=360; manual resize and compensation can exceed these preferences, while true hard maxWidth contracts remain intact. Actual selected campaign/version verified: Recipients640→1040→890, Delivery480→880→730, all three custom fields293.84→693.84→543.84px, and every width survives reload. Delivery is present in the DOM and visible in a fresh authenticated session with Templates/Postbox loaded; the user's pre-existing session disappearance remains unreproduced. No module condition was removed or configuration overwritten. Also defer initial recipient/global-attachment grids until the real version/draft exists: loading-only column signatures were overwriting browser-stored widths on reload. EN/DE documentation updated. No campaign content, mail operations, or DB changes. Verification after the ultrawide follow-up: 33 focused real-browser cases passed, including 3085px three-field recipient grids, two-way pointer/keyboard resizing, right-scroll-boundary shrink with stable handle/scroll position, width persistence, Delivery visibility, table-card desktop/mobile/loading geometry, navigation and EN/DE dashboard cancellation/save-and-leave. Actual authenticated 5173 campaign/version at 3085px also passed all five columns' grow/shrink/reload checks with zero campaign writes or JavaScript errors. Sizing unit regressions, strict conformance TypeScript, 27 Campaign documentation/navigation tests, final 72/72 manifest/architecture checks, and the final full-product production build with bundle-budget checks passed. The earlier full 243-case browser suite passed before this follow-up. The broad workspace gate completed its backend and focused frontend unit stages, but was deliberately interrupted during the optional-module build matrix after the user reported the ultrawide problem; do not treat that full gate as completed. Local implementation only: no commit, tag, push, release, or issue closure in this slice. <!-- govoplan-navigation-layout-20260908-implementation-evidence -->
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-campaign#102