Directory tree (sidebar/Move-Copy picker) only works for built-in admin — unusable for any custom role even with identical (0xFFFF) permission bits

Please make sure of the following things

• I have read the documentation. 我已经阅读了文档。

• I'm sure there are no duplicate issues or discussions. 我确定没有重复的issue或讨论。

• I'm sure it's due to AList and not something else(such as Network ,Dependencies or Operational). 我确定是AList的问题，而不是其他原因（例如网络，依赖或操作）。

• I'm sure this issue is not fixed in the latest version. 我确定这个问题在最新版本中没有被修复。

AList Version / AList 版本

v3.64.0

Driver used / 使用的存储驱动

N/A (this is a role/permission issue, reproducible regardless of storage driver)

Describe the bug / 问题描述

For a non-admin custom role, the directory tree (sidebar tree and the folder picker used in Move/Copy dialogs) never shows any subfolders — only the root node, with no expand arrow — even after granting the role every available permission and confirming its permission bits are byte-identical to the built-in admin role.

Steps that ruled out a permission-bit issue:

1. Created a custom role "super" with all permissions checked in the role-edit UI. Resulting permission_scopes value capped at 16383 (0x3FFF) — the UI provides no checkboxes for bits 14–15, which admin has (65535 / 0xFFFF).
2. Manually PATCHed the role via /api/admin/role/update to permission_scopes: [{"path":"/","permission":65535}]. Confirmed via /api/me that the role's merged permissions array updated correctly to 65535 — tree still broken.
3. Noticed the user object itself carries a separate, legacy top-level permission field (independent from the role's permission_scopes), which for a user under a custom role stayed 0 even after step 2. Manually PATCHed the user via /api/admin/user/update to set permission: 65535 as well.
4. After step 3, the user's /api/me response is now fully identical in every permission field to the built-in admin account (permission: 65535, permissions: [{"path":"/","permission":65535}]). The directory tree / folder picker is still broken for this user.

Since permission bits are now byte-for-byte identical to admin and the bug persists, this strongly suggests the directory-tree feature (/api/fs/dirs consumer, or its permission gate) checks role identity (e.g. role_names containing the literal string "admin", or a role-ID comparison via IsAdmin()) rather than the actual permission bits — meaning no custom role, regardless of granted permissions, can ever use this feature. Note /api/fs/dirs itself returns correct data (verified via Network tab) for both accounts — the break appears to be in how that permission/identity is gated, not in the data returned.

Separately noting as a related but distinct gap: the role-edit UI does not expose checkboxes for permission bits 14–15 that exist on admin (16383 vs 65535), so no custom role built through the UI alone can ever reach parity with admin without direct API edits.

Reproduction / 复现链接

1. Create a custom role with all permissions checked; note the resulting permission_scopes value from /api/admin/role/list or /api/me (capped below 65535).
2. Create/assign a user this role, with base_path: "/".
3. Log in as this user, open the sidebar directory tree or the Move/Copy dialog's folder picker — only the root node shows, no expand arrow.
4. Manually set the role's permission_scopes permission to 65535 via /api/admin/role/update.
5. Manually set the user's own permission field to 65535 via /api/admin/user/update.
6. Confirm via /api/me that the user's permissions are now identical to admin's.
7. Directory tree / folder picker is still broken — only admin works.

Config / 配置

default version.

Logs / 日志

No response