组织成员与访问权限

不同角色不要混为一谈

BYINUX 将访问控制和工作职责分开：

• User：登录身份。
• Membership：某个用户加入某个组织的关系。
• Access Role：组织级访问权限组合，例如 Owner、Admin、Member。
• Job Title：例如设计师、技师，是岗位称谓，不自动获得系统权限。
• Work Assignment：当前某张 Request、Proposal 或未来 Work Order 的工作责任，不等于全组织授权。

当前系统角色

角色	当前静态授权原则
Owner	包含目前定义的所有系统权限码
Admin	大部分管理权限，但不能通过系统角色自行分配角色，也不具有审计导出权限
Member	有限只读权限，允许 pricing.resolve，但不默认拥有 pricing.read/manage

能够在 Proposal 中使用解析价格不等于能够查看或修改整个 Pricing Strategy。

为什么有些菜单不显示？

当前 More 部分运营资源主要以 organization.facilities.read 作为可见性门槛，写操作还可能需要 organization.facilities.manage。菜单隐藏是前端体验，真正的安全判断仍由 API 检查组织成员、权限和数据归属。

管理员应如何使用

1. 核对用户属于哪个 Organization。
2. 确认其 Membership 状态及 Access Role。
3. 根据岗位与业务责任安排 Team / Workforce 工作分配；不要以修改 Job Title 替代权限授权。
4. 对不可见或返回 403 的页面先核对权限，再排查数据是否属于当前组织。

未来若开放自定义角色，应以最新实现补充权限矩阵。当前不能虚构独立的 cost.labor.* 或 workorder.assign 组织级权限码。