现象
平台版本 @objectstack/*@17.0.0-rc.6。
同一份对象级 userActions 声明中,两个动作用完全同形的谓词,收敛结果却不一致:delete.visibleWhen 生效,edit.visibleWhen 在记录详情页页头的内建【编辑】按钮上不生效。
逐字的对象声明:
userActions: {edit: {visibleWhen: P`os.user.id != record.executor`},delete: {visibleWhen: P`os.user.id != record.executor`},},复现与实测
以目标角色账号(即该记录 executor 本人)登录 Console,打开该记录的详情页:
| 入口 | 实测 | 是否符合谓词 |
|---|
| 列表行入口的【删除】 | 已按谓词隐藏 | ✅ |
| 页头「⋯」溢出菜单里的【删除】 | 已按谓词隐藏 | ✅ |
| 页头内建【编辑】 | 仍然显示 | ❌ |
点开页头【编辑】得到的是可编辑表单;提交时被服务端权限 / RLS 拒绝,数据未发生变更 —— 所以这不是数据完整性问题,是纯粹的 UI 入口收敛问题。
A/B 对照(用于排除项目侧写法问题):同一构建、同一账号、同一会话下,两个不同业务对象使用同一形态的 userActions 声明,表现完全一致 —— 均为「delete 生效、页头 edit 不生效」。因此不是单个对象的声明写错。
影响
业务上「某角色对该记录只读」这类需求,UI 入口收不干净:只能依赖服务端拦截,用户会先看到入口、点进去、填完再被拒。体验之外,合规审计也会把「能看到编辑入口」记为缺陷 —— 每轮 QA 都会重复报同一条。
期望
userActions.edit.visibleWhen 对详情页头的内建【编辑】按钮同样生效,与 delete(以及列表行入口)行为一致;- 若设计上「页头内建入口不受该谓词约束」是有意为之,请在文档中明示这条边界,并提供一个可用的收敛方式 —— 目前没有任何其他杠杆可以隐藏这颗按钮。
相邻单(非重复)
现象
平台版本
@objectstack/*@17.0.0-rc.6。同一份对象级
userActions声明中,两个动作用完全同形的谓词,收敛结果却不一致:delete.visibleWhen生效,edit.visibleWhen在记录详情页页头的内建【编辑】按钮上不生效。逐字的对象声明:
复现与实测
以目标角色账号(即该记录
executor本人)登录 Console,打开该记录的详情页:点开页头【编辑】得到的是可编辑表单;提交时被服务端权限 / RLS 拒绝,数据未发生变更 —— 所以这不是数据完整性问题,是纯粹的 UI 入口收敛问题。
A/B 对照(用于排除项目侧写法问题):同一构建、同一账号、同一会话下,两个不同业务对象使用同一形态的
userActions声明,表现完全一致 —— 均为「delete生效、页头edit不生效」。因此不是单个对象的声明写错。影响
业务上「某角色对该记录只读」这类需求,UI 入口收不干净:只能依赖服务端拦截,用户会先看到入口、点进去、填完再被拒。体验之外,合规审计也会把「能看到编辑入口」记为缺陷 —— 每轮 QA 都会重复报同一条。
期望
userActions.edit.visibleWhen对详情页头的内建【编辑】按钮同样生效,与delete(以及列表行入口)行为一致;相邻单(非重复)
edit/delete加了 per-record CEL 谓词 —— 本单是该能力在详情页头这一渲染面上的缺口;create根本不接受谓词),已由 feat(spec): userActions.create/import accept the edit/delete CEL predicate union #7758 合并解决,与本单不同面。