既然投诉了我，那我来解释一下吧。 这个是在填写节点中给了字段 A 的可编辑权限，但是字段 B 只给了查看权限，但是 B 引用了 A 作为默认值。这样在触发待办填写的时候，字段 A 设置了值之后，B 在界面上也被设为引用的值 A（是只读样式，因为 B 可以被查看）。在提交填写节点的时候，由于 B 并没有给编辑权限，因此并不会被实际写入。 所以用户由此判断为 Bug，要求我们修复。 我在第一次接到讨论里 @ 的时候，并不知晓此需求是从 Bug 转过来的，看到“控件事件”，和最后的描述“从控件事件都可以带出来值，但是填写节点不支持”，所以就草率的得出这是一个 “控件前端事件在表单中生效而在填写节点没有生效” 的 Bug，所以建议客服转到 Bug 处理。这是我本人的不专业和未与客户进一步沟通细节导致的，我郑重地向 @北冥 同学致歉，让您产生了互相踢皮球的感受，是我的问题，对不起。 今天早上在复盘会议上和顾问、研发一起探讨，顾问现场演示并解释了客户的操作和疑问，产品和研发一致得出结论，这里不是 Bug，因为在 填写节点没有给编辑权限的字段，如果可以成功写入数据，那就是明显的数据越权 。而用户置疑的在表单创建的时候为什么可以写入，是因为用户在创建表单记录时本身就有这个字段的编辑权限，这和填写节点中特意关闭了编辑权限并不一样（填写节点明确要求勾选后才有权限编辑）。并由研发给了顾问一个替代解决方案，就是 在填写节点中给编辑权限但是用业务规则设置为只读 来处理这种情况，可以解决用户的问题。 这也是后面顾问在 09:29 回复您「这个可以在填写节点开启编辑权限的情况下，用业务规则控制只读」的原因，因为这是产品和研发在会议上讨论后得出的结论，他只是转述给您最终的结论。 我对您在工单处理过程中被转来转去的情况再次表示歉意，我们也会优化完善工单中 Bug 和需求互转的提醒流程，不要让用户在反复等待中失去信任。
既然投诉了我，那我来解释一下吧。
这个是在填写节点中给了字段 A 的可编辑权限，但是字段 B 只给了查看权限，但是 B 引用了 A 作为默认值。这样在触发待办填写的时候，字段 A 设置了值之后，B 在界面上也被设为引用的值 A（是只读样式，因为 B 可以被查看）。在提交填写节点的时候，由于 B 并没有给编辑权限，因此并不会被实际写入。 所以用户由此判断为 Bug，要求我们修复。
这个是在填写节点中给了字段 A 的可编辑权限，但是字段 B 只给了查看权限，但是 B 引用了 A 作为默认值。这样在触发待办填写的时候，字段 A 设置了值之后，B 在界面上也被设为引用的值 A（是只读样式，因为 B 可以被查看）。在提交填写节点的时候，由于 B 并没有给编辑权限，因此并不会被实际写入。 所以用户由此判断为 Bug，要求我们修复。
因为审批、待办属于流程，本身就和应用、工作表不是一套数据权限体系。
财务要给全体员工发「薪资单」，完全没有必要把所有员都加到「财务应用」里，也不必为每个角色在薪资表上设置权限，只需要每个月给员工发一个待办填写让员工在「确认」这一个字段上修改并提交，其他的哪些字段需要哪些人看到，都在发通知的这个填写节点里设置就行了；不需要员工确认的，甚至发一个「抄送」给员工就行了。
This is an important feature, not bug.
这不是代码逻辑，这是业务逻辑
你说的好像也没错，但表单上规则事件，如果是卡在字段权限上，那么角色里面配置也应该是生效的，而且是最高的
这个事件甚至规则就失效了，那么有人测试过这种情况吗，照这么个理规则事件是可以从角色字段上焊死的
你们的只读描述都是人工不能修改。 我是默认值带出来，他是系统的自动化部分赋值，并不是人工赋值。 很费解
我只知道，创建时候没问题，视图按钮修改值也没问题，
变成待办就成了问题。
我是用户， 不是去理解你们代码逻辑的，用户只看界面使用逻辑。
现在使用上不同地方的只读在互相打架，可不就是 BUG 嘛。
看起来主要问题还是我们对不同事件，对于同一个字段给不同权限的时候的优先级解释还不足，这个需要优化。
4×4×3=48，刚才脑子短路了。
一个字段的值，在前端界面上（保存到服务器之前）会被以下方法完成更新：
1，人类手动修改；
2，根据默认值机制而修改；
3，触发事件后被修改；
4，他表、公式、统计字段的内置逻辑。
而“前端界面”有分为好几种：
1，直接在记录列表上修改；
2，在记录详情页上修改（包括在其子表、表格型关联记录上修改）；
3，在点击按钮后（触发工作流之前）的弹出层上修改；
4，在审批流的审批、填写界面上修改。
再考虑一个字段被设为只读的各种方式：
1，在权限上只读；
2，字段本身被设为只读；
3，被业务规则设为只读。
那么，以上的场景有 4×4×3=36 种。
若能对每种场景定义“正确的表现”，测出“目前的表现”，就清楚了。
我知道你们说的不同权限逻辑
但是不同权限落在我这边操作上应该是一致的，既然本身只读是可以写入数据，那么为什么推送个待办就不行。（要不然就全部都去掉只读不论哪里都不能赋值，都是一样的功能，为什么要互相打架）
至于你们说的不同的权限层级，那是你们底层设置问题。
既然投诉了我，那我来解释一下吧。
这个是在填写节点中给了字段 A 的可编辑权限，但是字段 B 只给了查看权限，但是 B 引用了 A 作为默认值。这样在触发待办填写的时候，字段 A 设置了值之后，B 在界面上也被设为引用的值 A（是只读样式，因为 B 可以被查看）。在提交填写节点的时候，由于 B 并没有给编辑权限，因此并不会被实际写入。 所以用户由此判断为 Bug，要求我们修复。
我在第一次接到讨论里 @ 的时候，并不知晓此需求是从 Bug 转过来的，看到“控件事件”，和最后的描述“从控件事件都可以带出来值，但是填写节点不支持”，所以就草率的得出这是一个 “控件前端事件在表单中生效而在填写节点没有生效” 的 Bug，所以建议客服转到 Bug 处理。这是我本人的不专业和未与客户进一步沟通细节导致的，我郑重地向 @北冥 同学致歉，让您产生了互相踢皮球的感受，是我的问题，对不起。
今天早上在复盘会议上和顾问、研发一起探讨，顾问现场演示并解释了客户的操作和疑问，产品和研发一致得出结论，这里不是 Bug，因为在填写节点没有给编辑权限的字段，如果可以成功写入数据，那就是明显的数据越权。而用户置疑的在表单创建的时候为什么可以写入，是因为用户在创建表单记录时本身就有这个字段的编辑权限，这和填写节点中特意关闭了编辑权限并不一样（填写节点明确要求勾选后才有权限编辑）。并由研发给了顾问一个替代解决方案，就是在填写节点中给编辑权限但是用业务规则设置为只读来处理这种情况，可以解决用户的问题。
这也是后面顾问在 09:29 回复您「这个可以在填写节点开启编辑权限的情况下，用业务规则控制只读」的原因，因为这是产品和研发在会议上讨论后得出的结论，他只是转述给您最终的结论。
我对您在工单处理过程中被转来转去的情况再次表示歉意，我们也会优化完善工单中 Bug 和需求互转的提醒流程，不要让用户在反复等待中失去信任。
👀️ 淡定淡定
不能让他们收 bug 只处理他们自己的问题，不解决用户的问题
非常理解您的心情。作为 AI 助手，我帮您梳理一下检索到的相关知识，希望能帮助您更好地定位问题。
相关知识梳理
1. 字段只读属性
标记为只读的字段，在新增或编辑记录时不能直接填写内容，但可以通过工作流修改，或通过业务规则更改为可编辑 。
2. 关联记录字段的行内编辑
关联记录字段可以勾选"允许行内编辑"，勾选后在关联表格的单元格中可以直接编辑字段；如果不勾选，则必须点击行记录打开记录详情才能编辑 。
3. 工作流填写节点/待办的特殊权限
填写节点有以下特殊规则：
4. 字段属性优先级
字段属性可能同时受以下因素影响：字段原始配置、业务规则、视图、角色权限、工作流/自定义按钮。系统按 "隐藏 > 显示 > 只读 > 必填 > 可编辑" 的优先级裁决 。
5. 业务规则在不同场景的生效范围
业务规则中的"只读所有字段"仅在对工作表操作时有效，工作流中的填写节点、审批节点打开记录，依然可以继续编辑 。
关于您描述的问题
根据知识库内容，待办（填写节点/审批节点）中编辑字段的逻辑确实与工作表直接编辑有所不同，这涉及到：
但知识库中没有关于"待办中修改关联字段"与"直接修改关联字段"差异的具体说明，也没有您描述的这种特定场景下问题的详细解释。
建议
由于您遇到的问题涉及到具体产品逻辑和可能的边界情况，建议您：
我理解这确实令人沮丧，但具体问题的定位和解决需要产品团队根据实际配置进行排查。希望您能尽快得到满意的解决方案！
未找到相关工单