feat: add usePermissions hook for role-based access control

[surajmn1]

Summary

• Add reusable usePermissions and useResourcePermissions hooks for consistent RBAC
• Replace inline permission logic in dataset page with the new hooks
• Supports auth-disabled mode (defaults to admin) and creator-based ownership

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 9746f54f-7736-4915-b788-260b67c18b3a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/use-permissions-hook

📝 Coding Plan

• Generate coding plan for human review comments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Claude finished @surajmn1's task —— View job

---

Code Review: usePermissions Hook Implementation

Todo List:

• Read and analyze the new usePermissions hook file
• Review the dataset page changes
• Evaluate code quality and best practices
• Check for potential bugs and security issues
• Assess performance considerations
• Review test coverage
• Provide comprehensive feedback

Review Summary

This PR introduces well-structured RBAC hooks that effectively centralize permission logic. The implementation is clean and follows React best practices, though there are some areas for improvement.

✅ Strengths

Clean Architecture & TypeScript

• Well-defined interfaces with clear permission properties (web/src/hooks/use-permissions.ts:3-11)
• Proper TypeScript usage with good type safety
• Clear separation between role-based and resource-based permissions

Security Design

• Secure defaults: members get read-only access (web/src/hooks/use-permissions.ts:30-37)
• Auth-disabled mode defaults to admin privileges for development (web/src/hooks/use-permissions.ts:22-24)
• Creator ownership model allows resource creators to edit their own content (web/src/hooks/use-permissions.ts:57-58)

Code Organization

• Good documentation with clear access matrix comments (web/src/hooks/use-permissions.ts:13-19)
• Clean integration in the dataset page (web/src/app/projects/[projectId]/datasets/[datasetId]/page.tsx:31)
• Follows existing patterns in the codebase

🔄 Areas for Improvement

1. Environment Variable Handling

// Current: web/src/hooks/use-permissions.ts:22
const isAuthDisabled = String(process.env.NEXT_PUBLIC_ENABLE_AUTH).trim() !== "true";

Issue: This logic is somewhat fragile and could fail with undefined/null values.
Suggestion: Consider a more robust check:

const isAuthDisabled = process.env.NEXT_PUBLIC_ENABLE_AUTH?.toLowerCase() !== "true";

2. Role Fallback Logic

// Current: web/src/hooks/use-permissions.ts:27
const isMember = effectiveRole === "member" || !effectiveRole;

Issue: Users with undefined roles default to member permissions, which may not be intended.
Suggestion: Make role handling more explicit and consider what should happen with unknown roles.

3. Creator Check Logic

// Current: web/src/hooks/use-permissions.ts:53
const isCreator = !!createdBy && user?.id === createdBy;

Issue: This assumes string comparison is sufficient for user ID matching.
Suggestion: Consider type safety and potential ID format mismatches.

🚨 Potential Issues

Missing Edge Cases

• No handling for invalid/unknown roles beyond member/admin
• No validation of user ID format consistency
• Auth state changes during component lifecycle not considered

Error Handling

• No error boundaries for auth store failures
• Silent fallbacks might hide authentication issues

📊 Performance Considerations

Positive:

• Hooks follow React patterns with minimal re-renders
• No unnecessary dependencies or computations

Neutral:

• Auth store calls should be optimized at the store level
• Current usage pattern is appropriate for the scale

🧪 Test Coverage

Missing: No test files found in the codebase. Consider adding tests for:

• Permission matrix validation (admin/member/creator combinations)
• Auth-disabled mode behavior
• Edge cases with undefined users/roles
• Creator permission inheritance

Recommended Test Cases:

// Example test scenarios
describe('usePermissions', () => {
  it('should grant admin permissions when auth is disabled')
  it('should restrict member permissions correctly')
  it('should allow creators to edit their resources')
  it('should handle undefined user gracefully')
})

🔧 Recommendations

1. Add comprehensive tests for permission logic
2. Improve error handling for auth store failures
3. Consider role validation to prevent unknown role states
4. Document the auth flow for better maintainability
5. Add JSDoc examples showing typical usage patterns

✅ Approval Recommendation

This is a solid implementation that improves the codebase by centralizing permission logic. The concerns raised are minor and don't block approval, but addressing them would further improve robustness.

The code successfully replaces inline permission checks with a clean, reusable hook pattern that will make permission management more consistent across the application.