Group view: fetch group + permission flags from /api/v2/groups/{id} (Group 4.1) - #892
Group view: fetch group + permission flags from /api/v2/groups/{id} (Group 4.1)#892edwh wants to merge 1 commit into
Conversation
Completes Group 4.1 of the Blade-to-Vue plan. group/view.blade.php previously
computed per-user permission flags server-side and passed them to <GroupPage> as
props; now GroupPage fetches the group (and those flags) from the v2 API instead.
- getGroupv2 resolves the OPTIONAL user (session, then api-token guard) and adds a
`permissions` object to the response via a groupPermissionsFor() helper that
replicates the blade logic exactly:
can_edit = admin || coordinatorForGroup || hostOfGroup
can_demote = admin || coordinatorForGroup
can_see_delete = admin
can_perform_delete = can_see_delete && group->canDelete()
can_perform_archive= admin || coordinatorForGroup
With no resolved user, all flags are false. (Host = Fixometer::userHasEditGroupPermission,
coordinator = User::isCoordinatorForGroup — the same calls the controller used.)
- GroupPage.vue drops the hydrated group/permission props and fetches on mount,
deriving the button flags as computed properties from the response.
- group/view.blade.php stops computing/passing those props.
- Note: these flags are UI show/hide only — the edit/delete/archive endpoints
enforce their own authorization independently.
Tests: APIv2GroupPermissionsTest covers the full matrix (anonymous / non-member /
host / coordinator own-vs-other network / admin, and can_perform_delete following
canDelete). GroupViewTest + InviteGroupTest updated for the removed props.
|
|
Superseded by #898 (Nuxt 4 SPA migration), which already carries this work. The API side is there. All five permission flags this PR adds are on
The client side no longer applies. The two files this PR changes for the legacy stack are deleted by #898:
The Nuxt client consumes the same flags directly — Still |
1 participant
Summary
Completes Group 4.1 of
plans/active/blade-to-vue-migration.md.group/view.blade.phppreviously computed per-user permission flags server-side and passed them to<GroupPage>as props. NowGroupPage.vuefetches the group and those flags from the v2 API on mount.getGroupv2resolves the optional user (session, then api-token guard) and returns apermissionsobject computed by a newgroupPermissionsFor()helper that replicates the Blade logic exactly:can_edit = admin || coordinatorForGroup || hostOfGroupcan_demote = admin || coordinatorForGroupcan_see_delete = admincan_perform_delete = can_see_delete && group->canDelete()can_perform_archive = admin || coordinatorForGroupFixometer::userHasEditGroupPermission, coordinator =User::isCoordinatorForGroup— the exact calls the controller used.GroupPage.vuedrops the hydrated group/permission props, fetches on mount, and derives the button flags as computed properties.group/view.blade.phpstops computing/passing those props.Security note
These flags are UI show/hide only — the edit/delete/archive endpoints each enforce their own authorization independently (defense in depth). The flag logic is nonetheless replicated faithfully and covered by a full test matrix.
Test plan
APIv2GroupPermissionsTest— full matrix (anonymous / non-member / host / coordinator own-vs-other-network / admin;can_perform_deletefollowscanDelete()): 8 tests, 112 assertionsGroupViewTest(8/171),InviteGroupTest,APIv2GroupTest,Groups\BasicTest— updated for removed props, all green (43 total)vite buildexit 0;translations:checkexit 0🤖 Generated with Claude Code