update: The interface for ordinary users to view resources has been r…#2018
update: The interface for ordinary users to view resources has been r…#2018benjamin-747 merged 1 commit intoweb3infra-foundation:mainfrom
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f9add84d96
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // key by note.id in order to reset tiptap editor state | ||
| key={note.id} | ||
| note={note} | ||
| note={{ ...note, viewer_can_edit: hasWritePermission }} |
There was a problem hiding this comment.
This only patches viewer_can_edit for NoteEditor, while InnerNoteView still passes the original note into NoteBreadcrumbs and NoteTrailingAccessory, both of which gate share/move/delete affordances off note.viewer_can_edit via downstream components. In the exact mismatch case you now surface (!hasWritePermission && note.viewer_can_edit), users are told the doc is read-only but can still open edit-capable menus and trigger mutations that should be blocked, creating inconsistent and error-prone behavior; the effective permission should be applied consistently across the whole note view.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Pull request overview
Updates the notes UX to better reflect effective permissions for non-admin users by using the /permissions/me/... endpoint and visually indicating locked/read-only states in note lists and the editor view.
Changes:
- Use the
/api/v1/permissions/me/{resource_type}/{resource_id}endpoint for ordinary users when fetching note permissions. - Improve locked/disabled note row UI (lock icon styling + tooltip positioning).
- In NoteView, derive editability from effective permissions and show a read-only banner when applicable.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| moon/apps/web/hooks/admin/useGetNotesPermissions.ts | Switches regular-user permission fetches to the /me permissions endpoint. |
| moon/apps/web/components/NotesIndex/NoteRow.tsx | Updates disabled-note visuals (lock icon, opacity) and tooltip placement. |
| moon/apps/web/components/NoteView/index.tsx | Adds permission lookup to determine write access; shows read-only banner and forces editor read-only. |
| moon/apps/web/components/NoteEditor/NoteContent.tsx | Adjusts editor cursor/caret styling when not fully editable. |
| const permission = notesPermissions?.[note.id] | ||
| const hasWritePermission = permission?.hasWrite ?? note.viewer_can_edit | ||
|
|
| let response | ||
|
|
||
| if (isSystemAdmin) { | ||
| // Admin users: use admin endpoint | ||
| response = await legacyApiClient.v1 | ||
| .getApiAdminUsersPermissionsByResourceId() | ||
| .request(currentUser?.username || '', 'note', note.id) | ||
| } else { | ||
| // Regular users: use /me endpoint | ||
| response = await legacyApiClient.v1.getApiPermissionsMeByResourceId().request('note', note.id) | ||
| } | ||
|
|
| // Get permissions for this note | ||
| const { data: notesPermissions } = useGetNotesPermissions({ | ||
| notes: [note], | ||
| enabled: true |
f48ecd0
No description provided.