fix(settings-page, team-page): refactor permission checks to use project-specific hooks - #481
Merged
Merged
Conversation
…ect-specific hooks
Contributor
|
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Summary
Fixes #468 — drag-and-drop reordering of task statuses could silently appear disabled (no grab cursor, no handle) for users who actually had
tasks.write, and only a hard page reload fixed it.Root cause: the Settings and Team pages each hand-rolled their own permission check by fetching the entire project members list and entire roles list, then manually cross-referencing them client-side to find "my role" and read its permission map. That derived state had no reliable invalidation path, so it could go stale in an open tab until a full reload forced everything to refetch.
Fix: both pages now use
useProjectPermissions(projectId)— the dedicated hook (backed byGET /projects/:id/members/me/permissions) already used consistently across ~20 other pages (backlog, sprints, docs, task detail, etc.) — instead of reimplementing permission derivation from bulk members/roles data.Changes
settings/index.tsx:canDelete,canEditProject,canManageRoles, andcanManageTasks(which gates the task-status drag handle) now read fromhasProjectPermission(...)instead of manually resolvingmembers→myMembership→myRole→permissions. Removed the now-unusedcurrentUserQueryOptions/members/roles derivation.team/index.tsx:canManageMembersfollows the same pattern; removed the now-unusedcurrentUserQueryOptionsfetch.Both pages still fetch
members/roleswhere that data is actually rendered (member list, role dropdowns) — only the permission-derivation logic changed.Testing
tsc -bpassesbiome checkpassesNote: this fixes the architectural inconsistency and removes staleness on normal remount/refocus/navigation, but doesn't add a live push — if a role's permissions change while an affected user's tab stays open and focused with no navigation, they'd still need some trigger (refocus/nav/reload) to see it, since the backend doesn't yet publish a change event for role/member updates.
🤖 Generated with Claude Code