[Task] Make Views the canonical user and group module-visibility layer #3

New Issue

2026-08-03T21:10:39+02:00

zemion commented

2026-08-03 21:10:39 +02:00

Goal

Use Views, rather than a duplicate personal module-selection store, for user/group module visibility.

Every WebUI module already contributes a root <module>.module surface. User and group Views can include or hide that root while View policy controls select/edit/derive/assignment rights.

Required work

Verify module root surfaces are present for every WebUI module.
Exclude tenant-unavailable module surfaces from the effective tenant catalogue and explain stale references.
Verify required View assignments can force visibility of selected module roots while preserving administration escape surfaces.
Add user/group tests showing that a View can hide a tenant-effective module but cannot expose a tenant-unavailable module or grant Access permission.
Document the boundary: tenant entitlement controls operational availability; Views control presentation; Access controls authorization.

## Goal Use Views, rather than a duplicate personal module-selection store, for user/group module visibility. Every WebUI module already contributes a root `<module>.module` surface. User and group Views can include or hide that root while View policy controls select/edit/derive/assignment rights. ## Required work - Verify module root surfaces are present for every WebUI module. - Exclude tenant-unavailable module surfaces from the effective tenant catalogue and explain stale references. - Verify required View assignments can force visibility of selected module roots while preserving administration escape surfaces. - Add user/group tests showing that a View can hide a tenant-effective module but cannot expose a tenant-unavailable module or grant Access permission. - Document the boundary: tenant entitlement controls operational availability; Views control presentation; Access controls authorization.

zemion added the

type

task

module/views area/module-system area/tenancy area/governance codex/ready

area/webui labels 2026-08-03 21:10:39 +02:00

zemion commented

2026-08-03 21:30:19 +02:00

Codex State: progress

Summary

Confirmed Views as the canonical user/group module-visibility layer through each WebUI module root surface.
Filtered the View surface catalogue and all definition, assignment, selection, and workflow resolution paths by the active tenant module entitlement.
Immutable revisions retain now-unavailable references and report them as stale rather than being rewritten.

Changed Files

src/govoplan_views/backend/router.py
tests/test_authorization.py

Verification

All 32 Views tests and Ruff passed; all-module smoke startup passed.

Next / Blocked

Push and exercise personal/group View selection after toggling a module at tenant scope.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Confirmed Views as the canonical user/group module-visibility layer through each WebUI module root surface. - Filtered the View surface catalogue and all definition, assignment, selection, and workflow resolution paths by the active tenant module entitlement. - Immutable revisions retain now-unavailable references and report them as stale rather than being rewritten. ### Changed Files - `src/govoplan_views/backend/router.py` - `tests/test_authorization.py` ### Verification - `All 32 Views tests and Ruff passed; all-module smoke startup passed.` ### Next / Blocked - Push and exercise personal/group View selection after toggling a module at tenant scope. Suggested status label: `status/in-progress`

zemion commented

2026-08-03 21:30:35 +02:00

Codex State: progress

Summary

Confirmed Views as the canonical user/group module-visibility layer through each WebUI module root surface.
Filtered the View surface catalogue and all definition, assignment, selection, and workflow resolution paths by the active tenant module entitlement.
Immutable revisions retain now-unavailable references and report them as stale rather than being rewritten.

Changed Files

src/govoplan_views/backend/router.py
tests/test_authorization.py

Verification

All 32 Views tests and Ruff passed; all-module smoke startup passed.

Next / Blocked

Push and exercise personal/group View selection after toggling a module at tenant scope.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Confirmed Views as the canonical user/group module-visibility layer through each WebUI module root surface. - Filtered the View surface catalogue and all definition, assignment, selection, and workflow resolution paths by the active tenant module entitlement. - Immutable revisions retain now-unavailable references and report them as stale rather than being rewritten. ### Changed Files - `src/govoplan_views/backend/router.py` - `tests/test_authorization.py` ### Verification - `All 32 Views tests and Ruff passed; all-module smoke startup passed.` ### Next / Blocked - Push and exercise personal/group View selection after toggling a module at tenant scope. Suggested status label: `status/in-progress`

zemion commented

2026-08-19 22:57:58 +02:00

Completed and verified. The behavior was implemented by the existing Views entitlement work (f271ca2) and Core surface normalization; the remaining acceptance-focused coverage is pushed in govoplan-core 8d9bcfd and govoplan-views e49129c.\n\nAcceptance evidence:\n- Core derives a stable <module>.module root from every frontend manifest; a workspace audit confirms 40/40 current WebUI modules have the root.\n- Views filters the effective surface catalogue through the active tenant module entitlement before definition, assignment, selection, or workflow resolution. Immutable stale references remain diagnostic evidence and fail back to the authorized full interface rather than restoring unavailable modules.\n- Required assignments retain the selector and appropriate administration escape surfaces, with validation and fallback tests already present.\n- New Views tests cover both personal and group defaults hiding another tenant-effective module root, and prove a group View cannot restore a tenant-unavailable module.\n- New Core WebUI coverage proves that selecting a surface does not add the Access permission required by that module.\n- README and manifest documentation already state the boundary: entitlement controls operational availability, Views controls presentation, and Access controls authorization.\n\nVerification passed: 36 Views tests plus Ruff; Core module-capability suite; Core View-surface suite; 40/40 root-surface audit; 68/68 manifest registry; protected pushes in both repositories.

Completed and verified. The behavior was implemented by the existing Views entitlement work (`f271ca2`) and Core surface normalization; the remaining acceptance-focused coverage is pushed in `govoplan-core` `8d9bcfd` and `govoplan-views` `e49129c`.\n\nAcceptance evidence:\n- Core derives a stable `<module>.module` root from every frontend manifest; a workspace audit confirms 40/40 current WebUI modules have the root.\n- Views filters the effective surface catalogue through the active tenant module entitlement before definition, assignment, selection, or workflow resolution. Immutable stale references remain diagnostic evidence and fail back to the authorized full interface rather than restoring unavailable modules.\n- Required assignments retain the selector and appropriate administration escape surfaces, with validation and fallback tests already present.\n- New Views tests cover both personal and group defaults hiding another tenant-effective module root, and prove a group View cannot restore a tenant-unavailable module.\n- New Core WebUI coverage proves that selecting a surface does not add the Access permission required by that module.\n- README and manifest documentation already state the boundary: entitlement controls operational availability, Views controls presentation, and Access controls authorization.\n\nVerification passed: 36 Views tests plus Ruff; Core module-capability suite; Core View-surface suite; 40/40 root-surface audit; 68/68 manifest registry; protected pushes in both repositories.

zemion closed this issue

2026-08-19 22:57:58 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-views#3