Permissions Demo#17
Conversation
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| --velt-font-size-md: 0.972rem; /* 15.556px - icon size */ | ||
| --velt-font-size-lg: 1.167rem; /* 18.667px - icon container */ | ||
| --velt-font-size-xl: 1.75rem; /* 28px - component height */ | ||
| --velt-font-size-2xl: 2rem; /* 32px */ |
There was a problem hiding this comment.
Bug: CSS custom properties declared without selector block
All CSS custom properties in this file (like --velt-default-font-family, --velt-border-radius-*, theme colors, spacing, and font sizes) are declared at the file's top level without being wrapped in a selector such as :root. CSS custom properties must be declared inside a selector block to be valid. The browser will ignore these declarations entirely, causing the Velt UI theme customization to have no effect.
|
|
||
| setUser(selectedUser); | ||
| setIsUserLoggedIn(true); | ||
| } catch {} |
There was a problem hiding this comment.
Empty catch block silently fails user initialization
The useEffect in AppUserProvider wraps initialization logic in a try-catch with an empty catch block (catch {}). If JSON.parse(stored) fails on corrupted localStorage data, or if storage access throws (e.g., storage is disabled), the error is silently swallowed. The user state remains undefined and isUserLoggedIn remains undefined, leaving the demo in a broken state with no indication of what went wrong. The same pattern appears in the login callback.
Additional Locations (1)
| selectedUser = userHeader as UserRole; | ||
| } else { | ||
| selectedUser = loadSelectedUser(); | ||
| } |
There was a problem hiding this comment.
Permission API ignores client-side settings changes
The permission API route calls loadPermissionSettings() and loadSelectedUser() as fallbacks, but these functions require localStorage which doesn't exist on the server. They will always return default values. The API expects settings via custom headers (x-demo-permission-settings, x-demo-selected-user), but no code in the codebase sends these headers. This means permission changes made in the UI are never reflected in actual permission checks - the demo UI appears to work but the underlying permission system always uses defaults.
| strokeOpacity={accessMap['doc-c'].hasAccess ? 1 : 0.32} | ||
| strokeWidth="2" | ||
| strokeDasharray={accessMap['doc-c'].hasAccess ? 'none' : '12 12'} | ||
| /> |
There was a problem hiding this comment.
Hierarchy diagram shows wrong parent for Document C
The visual hierarchy diagram draws a connecting line "From Folder B to Document C", implying Document C is a child of Folder B. However, the data hierarchy in permissions-data.ts defines doc-c with parentId: 'org-a', making it a direct child of Organization A. This mismatch will confuse users about permission inheritance - if they set Document C to Inherit, it will inherit from Organization A's permissions, not Folder B's as the visual suggests.
Additional Locations (1)
yoen-velt
force-pushed
the
permissions-demo
branch
from
0fa8a82 to
81dd931
Compare
Regenerate lockfile to resolve missing entries for @veltdev/react@4.6.5 and other packages that were causing build failures on Vercel. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
| { id: 'folder-b', name: 'Folder B', type: 'folder', parentId: 'org-a' }, | ||
| { id: 'doc-a', name: 'Document A', type: 'document', parentId: 'folder-b' }, | ||
| { id: 'doc-b', name: 'Document B', type: 'document', parentId: 'folder-a' }, | ||
| { id: 'doc-c', name: 'Document C', type: 'document', parentId: 'org-a' }, |
There was a problem hiding this comment.
Visual hierarchy mismatches permission inheritance data model
The HIERARCHY_NODES data defines doc-c with parentId: 'org-a', but the visual diagram in document-canvas.tsx draws a connection line from Folder B to Document C (labeled "From Folder B to Document C"). When doc-c is set to 'Inherit', the resolveEffectivePermission function traces doc-c → org-a, completely bypassing folder-b. Users will see folder-b as the visual parent but get inheritance behavior from org-a, causing confusing and incorrect permission calculations.
Additional Locations (1)
| case 'OrganizationPrivate': | ||
| // Only org members have access | ||
| hasAccess = userConfig.orgMember; | ||
| accessRole = userConfig.isOwner ? 'editor' : 'editor'; // Org members get editor |
There was a problem hiding this comment.
Redundant ternary always returns same value
The ternary expression userConfig.isOwner ? 'editor' : 'editor' always returns 'editor' regardless of the condition, making it pointless dead code. Comparing to the 'Public' case on line 144 which uses isOwner ? 'editor' : 'viewer', this appears to be a copy-paste error where the second 'editor' was likely intended to be 'viewer' to differentiate access roles between owners and regular organization members.
1 participant
Pull Request
Description
Type of Change
Monorepo Structure Checklist
If adding a new demo, ensure you've followed the 5-level structure:
apps/<framework>/<document>/<type>/<implementation>/<library-or-solution>/<demo>/package.jsonwith scoped name:@apps/<framework>-<document>-<library-or-solution>-<demo>pnpm --filter <package-name> buildpnpm --filter <package-name> devDeployment Checklist
If this demo should be deployed:
Testing
pnpm -w install && pnpm -w buildDocumentation
master-sample-app(if applicable)Related Issues
Screenshots/Videos
Additional Context
For Reviewers
Demo Location
Path:
apps/<framework>/<document>/<type>/<implementation>/<library-or-solution>/<demo>/Package name:
@apps/<...>How to Test
Structure Verification
The demo follows the 5-level hierarchy:
Documentation: See README_MONOREPO.md and docs/structure.md for more details on the monorepo structure.
Note
Adds a new Next.js demo app showcasing on-demand permissions with a custom permissions API, Velt auth token endpoint, and integrated Velt collaboration UI.
apps/react/permissions/on-demand/custom/permissions-demo(@apps/react-permissions-on-demand-custom-permissions-demo).app/,styles/,tailwind.config.js,postcss.config.js,tsconfig.json,next.config.js).README.md,.gitignore,components.json,package.json.app/api/check-permissions/route.ts: Processes batched permission requests, maps resource IDs, computes access vialib/permissions-data, returns Velt-formatted results; CORSOPTIONShandler.app/api/velt/token/route.ts: Proxies to Velt to generate JWT tokens using API/auth keys.lib/permissions-data.ts: Defines hierarchy (organization,folder,document), permission states, role configs, inheritance resolution, effective access computation, and localStorage helpers.components/document/document-canvas.tsx+icons/: Interactive hierarchy visualization with per-node permission dropdowns and access role toggles.app/document/DocumentContext.tsxanduseCurrentDocument.ts(URL/localStorage ID handling).app/userAuth/*(random user generation, login/logout context).app/providers.tsxintegratingVeltProviderwith permission provider config.components/velt/*(initialize document, comments, sidebar, presence, notifications) with custom wireframes and theming (ui-customization/styles.css).Written by Cursor Bugbot for commit 2179bbb. This will update automatically on new commits. Configure here.