既然投诉了我，那我来解释一下吧。 这个是在填写节点中给了字段 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，要求我们修复。
有1人点赞
这种服务很魔幻，知道吗 😄
要实施，实施没有，服务费也收了
明明发个消息就能摇人，顾问就开始 唉~您给我转个工单呗
再充分沟通，邮件，短信就各种消息，就像楼主说的反反复复开始消耗了
再回来群里，技术进来了@XX 远程一下：
最终大概率是
😄 嗯，是这么个问题，搞不定了，等升个级吧，XX 版本已经解决了
👀️ 啊，我更新到期了呀，升不了
😕 哦，那我也没招了
就针对这个问题，只读字段赋值问题，
明道有很多客户，不同公司的业务逻辑是不同的，为每个客户定制是做不到的。
HAP 的做法是把功能拆散（所以才有权限、视图、业务规则等模块），让客户自己组装成适合自己的业务逻辑。
所以就会要求客户花点时间，去了解这些模块的特点和用法。
至于如何方便地学习，客服的回答是否有问题之类的，是沟通上的事。
总之我不觉得 HAP 平台本身有啥问题。
我是采购给公司用的，我的逻辑就一个，所有的规则这些都是限制人工的操作。
其他类似默认值、流程节点复制、或者规则赋值等等，都不应当考虑账号的权限问题。
因为本身不属于人员账号的操作，只是基于人工账号其他地方的操作从而触发的系统程序。
现在因为人工权限不够，所以系统程序就不能完成相应的动作。
从我的角度看，就是很费解，提出情况后，一会说 BUG，一会说是需求，一会说这个逻辑就是这样，不能改。搞得我这种付费用户完全感受不到服务体验 （不针对群内服务，只说你们的这种产品逻辑完全和用户反着来，也许也是我们花的钱不够多，你们不够重视）
我是用户，我只认眼前界面看到的，能设置的东西，至于背后代码逻辑，就不该我来去理解去适应。
赞同，
是自己公司采购自己搭建给公司用，还是中间商搭建卖给其他人用。
都是用户，那个用户会和你扯代码，市面上没看到过买软件的让用户去理解代码的
我都采购了还费心的理解代码逻辑，那采购的钱不是白花了嘛
他这个是流程权限与前端规则的问题，从程序逻辑讲就是有问题的，要么越权，要么规则失效
官方解释 归属于流程权限，规则失效这不是问题？
就用户逻辑，规则事件必须生效，而且前端可见的字段规则事件，流程节点也是生效的，不然设置也没意义了，跟编辑权半毛钱关系没有
我采购的，我肯定走业务逻辑
我觉得
当你只是用明道云搭建起来的系统，遇到一会可以编辑，一会不能编辑，你理所当然的判断这个系统有 bug，一点问题没有，完全可以去喷做这个这个系统人垃圾，系统垃圾。
当你是用明道云来做系统给别人用或者自己用，用间接实现的方法一点问题没有，只要用的时候没问题就可以。说白了要明白自己的角色定位，上面有个老哥说的很好，业务逻辑和代码逻辑要分清楚。
此外，也别觉得写代码没有中间过程，用明道云只是省略写代码， 不是连实现的逻辑都要省略的。
不要去纠结中间控件（中间件）的问题了。
真的了深入业务系统，你还会纠结为啥要有中间表呢。
真的想自己开发系统，到后面也会纠结为啥有了数据库（MySQL）还要 Redis 垫一层而不是应用系统直连数据库。
别纠结
因为审批、待办属于流程，本身就和应用、工作表不是一套数据权限体系。
财务要给全体员工发「薪资单」，完全没有必要把所有员都加到「财务应用」里，也不必为每个角色在薪资表上设置权限，只需要每个月给员工发一个待办填写让员工在「确认」这一个字段上修改并提交，其他的哪些字段需要哪些人看到，都在发通知的这个填写节点里设置就行了；不需要员工确认的，甚至发一个「抄送」给员工就行了。
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. 业务规则在不同场景的生效范围
业务规则中的"只读所有字段"仅在对工作表操作时有效，工作流中的填写节点、审批节点打开记录，依然可以继续编辑 。
关于您描述的问题
根据知识库内容，待办（填写节点/审批节点）中编辑字段的逻辑确实与工作表直接编辑有所不同，这涉及到：
但知识库中没有关于"待办中修改关联字段"与"直接修改关联字段"差异的具体说明，也没有您描述的这种特定场景下问题的详细解释。
建议
由于您遇到的问题涉及到具体产品逻辑和可能的边界情况，建议您：
我理解这确实令人沮丧，但具体问题的定位和解决需要产品团队根据实际配置进行排查。希望您能尽快得到满意的解决方案！
未找到相关工单