单用户跨数据库创建文档时@MailSend不生效问题排查问询

• 文档未完成持久化：代码中创建文档时调用的是.save False,False，未开启强制保存，跨库打开时文档还未完全写入生产库的磁盘，@MailSend生成文档链接时读取不到完整的文档元数据触发静默失败，重新打开时文档已经完成持久化，可正常读取。
• 上下文数据库指向异常：通过ws.EditDocument从第一个mail-in库跨库打开第二个库的新文档时，客户端公式的运行上下文仍临时绑定在第一个mail-in库，@MailSend带[IncludeDoclink]参数需要生成目标文档所在库的链接时，上下文不匹配导致链接生成失败触发静默失败。测试环境的数据库可能未开启跨上下文安全校验，或两个库同属一个域/服务器，不存在上下文隔离问题。
• 生产库的邮件发送安全限制：生产第二个库的数据库属性中开启了仅允许来自受信任代理的邮件发送规则，刚通过跨库操作打开的文档，操作请求未被识别为受信任来源，直接拦截@MailSend请求但不返回报错；重新打开文档时操作请求直接来源当前库，符合规则限制可以正常发送。
• 字段值临时未加载：跨库打开新文档时，area、Type等@MailSend标题依赖的字段未完成前台初始化，导致邮件标题生成失败触发静默回滚，但activity_log的更新逻辑不依赖这两个字段，所以可以正常写入。
• 客户端邮件缓存异常：该用户客户端针对生产第二个库的邮件发送缓存存在损坏，首次调用时读取了异常缓存信息，重新打开文档后缓存刷新，调用恢复正常。

• 简化@MailSend逻辑测试：先去掉[IncludeDoclink]参数测试，如果此时首次操作可以正常发信，即可定位为文档链接生成失败导致的问题；再进一步去掉标题中的area和Type变量，用固定字符串测试，排查是否为字段加载问题。
• 增加调试日志：在表单操作逻辑开头新增字段赋值逻辑，把@MailSend的所有入参、上下文数据库路径@DbName、执行时间写入临时字段，对比首次操作和重新打开后操作的入参差异，确认是否存在上下文或字段值异常。
• 对比生产和测试库的配置差异：检查两个库的数据库属性-安全标签页配置，重点核对「禁止LotusScript/公式发送邮件」「受信任的代理签名者」配置是否一致；再核对两个库所在服务器的邮件路由规则、发件人校验规则是否存在差异。
• 客户端层面排查：让该用户换个干净的Notes客户端环境测试，排除本地缓存、场所配置异常的问题；同时用其他同权限的用户在同客户端操作，确认是用户权限配置问题还是客户端环境问题。
• 调整代码调用逻辑：将创建文档时的保存逻辑修改为.save True,False强制持久化后再打开文档，测试是否可以解决问题，反向验证上下文或持久化异常的猜想。

内容的提问来源于stack exchange，提问作者Duston