Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has required the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
Coverage report for
|
St.❔ |
Category | Percentage | Covered / Total |
|---|---|---|---|
| 🔴 | Statements | 8.81% (+0.01% 🔼) |
1736/19695 |
| 🔴 | Branches | 7.99% | 1097/13729 |
| 🔴 | Functions | 5.31% (+0.02% 🔼) |
284/5351 |
| 🔴 | Lines | 8.51% (+0.01% 🔼) |
1628/19130 |
Test suite run success
847 tests passing in 38 suites.
Report generated by 🧪jest coverage report action from 2160733
There was a problem hiding this comment.
Pull request overview
This PR updates the Admin VFolder list page to scope visible vfolders by the user’s effective admin role (project-scoped for project admins, unscoped for superadmins), hides personal/user-owned folders from the admin view, and adds an admin-side folder creation entrypoint.
Changes:
- Add
scope_idsupport to the adminvfolder_nodesRelay query and compute scope based onuseEffectiveAdminRole()+ current project. - Pin the admin list to project-owned folders via
ownership_type == "group"and remove the ownership-type filter UI control. - Add a “Create Folder” button and wire
FolderCreateModalto create a project folder for the currently selected project.
| // Determine the `scope_id` to apply to the `vfolder_nodes` query based on the | ||
| // user's effective admin role: | ||
| // - superadmin: no scope (sees all projects/domains) | ||
| // - projectAdmin: scope to the currently selected project | ||
| // - domainAdmin: TODO(needs-backend) — requires a `domain:<name>` scope argument | ||
| // that the core does not yet accept. For now, fall back to no scope, which | ||
| // matches the pre-FR-2556 behavior for domain admins. | ||
| // Personal (user-type) folders are always filtered out via `ownership_type == "group"` | ||
| // so that admins never see other users' private folders. | ||
| const scopeId: string | undefined = | ||
| effectiveAdminRole === 'projectAdmin' && currentProject?.id | ||
| ? `project:${currentProject.id}` | ||
| : undefined; |
There was a problem hiding this comment.
For effectiveAdminRole === 'projectAdmin', scopeId falls back to undefined when currentProject.id is missing, which makes the vfolder_nodes query unscoped (potentially showing folders outside the intended project scope). Consider making currentProject.id mandatory in this role (e.g., block rendering/query until available or surface an error) and avoid issuing an unscoped admin query for project admins.
| @@ -75,6 +80,7 @@ const AdminVFolderNodeListPage: React.FC = (props) => { | |||
| Array<VFolderNodesType> | |||
| >([]); | |||
|
|
|||
| const [isOpenCreateModal, { toggle: toggleCreateModal }] = useToggle(false); | |||
| const [isOpenDeleteModal, { toggle: toggleDeleteModal }] = useToggle(false); | |||
| const [isOpenRestoreModal, { toggle: toggleRestoreModal }] = useToggle(false); | |||
There was a problem hiding this comment.
Now that the admin folder list can be scoped by currentProject (for project admins), selected rows can become stale when the user switches projects. Without clearing selectedFolderList on currentProject.id change, bulk actions (delete/restore) may target folders from a previous project. Add an effect similar to VFolderNodeListPage to reset selection (and optionally pagination) when currentProject.id changes.
| // Admin view creates folders for the currently-scoped project only: | ||
| // the type radio group ("User"/"Project") and the project selector | ||
| // are hidden so an admin cannot create a personal folder or target a | ||
| // different project. The `group` field defaults to | ||
| // `currentProject.id` inside `FolderCreateModal`, so simply hiding | ||
| // the fields locks the folder to the current project. | ||
| initialValues={{ | ||
| type: 'project', | ||
| group: currentProject?.id || undefined, | ||
| }} | ||
| hiddenFormItems={['type', 'group']} |
There was a problem hiding this comment.
initialValues always includes group, even when currentProject?.id is undefined. In FolderCreateModal, mergedInitialValues is {...INITIAL_FORM_VALUES, ...initialValuesFromProps}, so an explicit group: undefined from props overrides the modal's own default group value and can lead to submitting an invalid project folder (especially since the group field is hidden). Consider omitting the group key entirely when there is no currentProject.id, and/or disabling the Create button/modal until a project is selected.
…er creation in admin mode
86ff2d3 to
2160733
Compare
4181d2d to
28bb644
Compare

Resolves #NNN (FR-2209)
Summary
AdminVFolderNodeListPagequery by current project when the effective admin role iscurrentProjectAdmin; superadmins still see all folders.ownership_type == "group"so admins never see personal user folders.FolderCreateModal, locked to the current project (type/group fields hidden, defaulted toproject+currentProject.id).project-admin-vfolderspage that reusesAdminVFolderNodeListPageunder/project-admin-vfolders, registered inPROJECT_ADMIN_PAGE_KEYSso project admins see a dedicated Folders entry in the admin menu.admin-sessioninPROJECT_ADMIN_PAGE_KEYSso project admins can reach the admin Sessions view.effectiveAdminRole === 'projectAdmin'never matched the real enum value (currentProjectAdmin), so scoping was inactive for project admins.webui.menu.ProjectFoldersi18n key (en, ko).Test plan
/admin-datastill lists folders across all projects;/project-admin-vfoldersis not shown in the admin menu.Folders(project-admin-vfolders) andUsersentries;/project-admin-vfolderslists only folders under the current project; switching the project re-scopes the list./project-admin-vfolders: confirm the modal hides the type/group fields and the folder is created under the current project.en,ko).Checklist: (if applicable)