Odoo 企业版 Microsoft Calendar 预约同步为什么不是“换个连接器就等同 Google”：connector 检测、日历筛选与 setup 提示讲透

很多项目在做预约集成时，会默认把 Microsoft Calendar 当成“Google 的平替接口”。但 enterprise/appointment_microsoft_calendar/models/appointment_type.py 体现的思路并不是简单复刻，而是把 Microsoft 当成另一条有自己配置门槛的连接器链路。

一、connector 是否可用，要看同步状态而不是按钮是否存在

_get_calendars_possible_to_setup() 会检查 self.env.user.check_synchronization_status()['microsoft_calendar'] 是否不是 missing_credentials，并确认 microsoft_calendar_sync_paused 没被暂停。只有这些条件同时满足，系统才把 microsoft 加入可配置日历列表。

这说明 Microsoft 集成的核心问题不是“界面上有没有 Microsoft 选项”，而是当前用户和当前系统是否真的具备同步前提。

二、已配置与可配置是两个不同概念

_get_calendars_already_setup() 只在当前用户已有 microsoft_calendar_token 时把 microsoft 标记成已配置；_compute_connector_microsoft() 则只判断它是否可以 setup。也就是说，官方明确区分：

• 系统现在能不能提供 Microsoft 接入能力；
• 当前这个用户到底有没有接好自己的账号。

企业上线时最容易忽略这层区别，结果管理员配置好了应用，业务用户却没完成授权，最终预约体验半通不通。

三、暂停开关是运营能力，不只是技术开关

源码里专门检查 microsoft_calendar_sync_paused。这说明官方默认同步服务可能被临时暂停，且预约类型需要感知这种状态。对企业来说，这很有价值：出现授权故障、API 配额问题或切换租户时，可以先暂停新接入，而不是继续让业务以为一切正常。

四、为什么它不该被当成 Google 的镜像实现

虽然 Google 和 Microsoft 模块都做了“already setup / possible to setup” 两层判断，但底层条件不同：Google 看 client id 与 paused；Microsoft 看同步状态与 paused。也就是说，两个连接器在接入前提、报错方式和用户准备动作上并不完全一样。

这正是实战里要尊重的地方：如果把 Microsoft 按 Google 项目模板机械搬过去，排查时会不停走错方向。

实战注意事项

1. 区分管理员配置与用户授权：系统可 setup，不代表用户已可用。
2. 把 paused 状态接入上线检查：暂停中的连接器不该被误判为正常。
3. 不要照抄 Google 排障手册：两个连接器的前置条件不同。
4. 把 token 状态纳入验收：已配置列表才代表业务用户真的接好了账号。

新手误区

• 误以为 Microsoft 连接器只是名字不同。
• 误以为管理员开通后，所有用户都自动完成同步。
• 误以为只要界面出现选项就代表可用。
• 误以为暂停开关只影响后台任务，不影响预约配置判断。

主要源码参考

• enterprise/appointment_microsoft_calendar/models/appointment_type.py