Skip to content

Commit 15bd06f

Browse files
committed
feat(FR-2893): disable upload button when host lacks upload-file permission
Derive `hasWriteContentPermission` from the existing `unitedAllowedPermissionByVolume` host permission set instead of hard-coding it to `true`. The host permission set already carries `upload-file` alongside `download-file`, so the same pattern used for download gating now also gates upload/edit. Delete capability remains hard-coded behind the FR-2619 follow-up note, since `delete-vfolder` is folder-level rather than file-level.
1 parent f4e2e10 commit 15bd06f

1 file changed

Lines changed: 12 additions & 9 deletions

File tree

react/src/components/FolderExplorerModalV2.tsx

Lines changed: 12 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -159,17 +159,20 @@ const FolderExplorerModalV2: React.FC<FolderExplorerProps> = ({
159159
unitedAllowedPermissionByVolume[vfolderNode?.host ?? ''],
160160
'download-file',
161161
);
162-
// TODO(needs-backend): write/delete capability should be derived from the
162+
const hasWriteContentPermission = _.includes(
163+
unitedAllowedPermissionByVolume[vfolderNode?.host ?? ''],
164+
'upload-file',
165+
);
166+
// TODO(needs-backend): delete capability should be derived from the
163167
// caller's *effective* permission set on this entity (e.g.,
164-
// `delete_content`, `write_content`), not from the folder's mount
165-
// permission. The V2 schema currently exposes only the mount permission via
166-
// `accessControl.permission` (`READ_ONLY` / `READ_WRITE` / `RW_DELETE`),
167-
// which is what the folder is mounted *as* into a session — not what the
168-
// caller is allowed to do on the folder itself. Until the backend exposes a
169-
// proper effective permission set, allow all callers and let the server
170-
// enforce authorization. See FR-2619 follow-up.
168+
// `delete_content`), not from the folder's mount permission. The V2 schema
169+
// currently exposes only the mount permission via `accessControl.permission`
170+
// (`READ_ONLY` / `READ_WRITE` / `RW_DELETE`), which is what the folder is
171+
// mounted *as* into a session — not what the caller is allowed to do on the
172+
// folder itself. Until the backend exposes a proper effective permission
173+
// set, allow all callers and let the server enforce authorization.
174+
// See FR-2619 follow-up.
171175
const hasDeleteContentPermission = true;
172-
const hasWriteContentPermission = true;
173176
// TODO: Skip permission check due to inaccurate API response. Update when API is fixed.
174177
const hasNoPermissions = false;
175178

0 commit comments

Comments
 (0)