目前通过钉钉开放能力自动创建并提交日报时,提交接口要求必须指定个人接收人的 userId。
现有参数中:
to-user-ids:必填,只能填写个人用户 ID。to-chat:仅控制是否将日报发送到接收人的单聊。openConversationId 或群聊接收人的相关参数。实际结果:
期望官方支持:
openConversationId。to-chat 是个人单聊还是也支持群聊,以及当前接口的接收对象限制。使用场景:
公司希望每天由系统自动整理并创建部门日报,然后直接推送到固定的部门群,供群成员统一查看。目前必须逐个指定个人,人员变动时还需要同步维护接收人列表,不适合部门日报和项目日报的自动化场景。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
这接口设计确实反人类,把“日报”这种协作工具做成了单向汇报。
核心痛点是 API 把日报绑定在了“人”身上,没绑定在“事”或“群”上。to-user-ids 强制要求个人 ID,导致自动化部署时还得维护一份死板的人员名单,一旦有人离职或调岗,脚本就崩了。
现状没法直接改接口,只能绕道:
双轨制:API 提交时随便填个“系统管理员”ID 应付校验,开启 to-chat 推送给该管理员。
二次转发:拿到日报链接后,立刻调用钉钉群消息接口(发送 Markdown 卡片),把链接丢进部门群。虽然多了一步,但实现了“自动创建+群可见”。
替代方案:如果团队允许,考虑用钉钉文档的“智能日报”模板,通过 Webhook 更新文档内容,再 @全员,比硬推日报接口灵活得多。
建议去钉钉开放平台提 Feature Request,强调“自动化运维/项目同步”场景,这类需求其实很多团队都有。
官方详细解决方案:https://www.aliyun.com/product/qoder