findMeetingTimes未返回忙碌时段，minimumAttendeePercentage参数失效问题

针对你遇到的两个问题——已安排会议未被识别为忙碌时段，以及minimumAttendeePercentage参数未生效，我整理了几个关键排查方向，你可以逐一验证：

1. 先确认 minimumAttendeePercentage 参数的使用逻辑 #

你设置的0.0其实符合参数范围（该参数接受0到100的数值，代表参会者可用率百分比），但要注意两个细节：

• 确保请求里的0.0是数值类型而非字符串（比如不要写成"0.0"），否则接口可能无法正确解析参数
• 当设置为0时，接口理论上会忽略参会者的可用性，返回所有符合时间约束的时段。如果这时候仍未返回预期结果，大概率和参会者日历权限或会议可见性有关

2. 检查参会者日历的访问权限 #

findMeetingTimes需要读取参会者的忙闲信息，所以要确认：

• 调用接口的当前用户（即/me对应的账号）对somebody@omni.com的日历有读取忙闲的权限。组织内用户通常默认有这个权限，但跨租户或外部用户需要对方显式授权日历共享
• 如果是跨场景调用，还要检查租户间的日历共享策略是否允许读取忙闲数据

3. 验证已安排会议的状态与可见性 #

已安排的会议没被标记为忙碌，可能是以下原因：

• 会议隐私设置：如果会议被标记为私密，接口默认不会返回该时段的忙碌信息。你可以在请求中添加"includePrivate": true参数，尝试获取私密会议的忙闲数据
• 会议响应状态：如果参会者还未响应会议邀请（处于暂定状态），部分场景下接口可能不会将其标记为忙碌，但通常日历会自动标记为暂定忙碌，你可以直接查看参会者的日历确认这一点
• 时间匹配度：确认已安排的会议时间是否完全覆盖你请求的2018-03-30T15:00:00Z到2018-03-30T16:00:00Z时段，是否存在部分重叠但未被接口识别的情况

4. 检查其他请求参数的影响 #

你的请求中设置了"isOrganizerOptional": true，这个参数会忽略组织者（即当前调用用户）的可用性。如果已安排的会议是你作为组织者创建的，接口会跳过你的忙碌时段检查；如果目标是检查参会者abc的忙碌状态，这个参数不影响，但可以尝试暂时设为false来测试差异

5. 用简化请求定位问题 #

建议你先简化请求做测试，比如：

• 把minimumAttendeePercentage设为100.0（要求所有必填参会者都可用），看是否能正确返回参会者的忙碌时段
• 直接调用/v1.0/users/somebody@omni.com/calendarview接口，查询该用户在目标时间段内的日历事件，确认是否存在已安排的会议。如果这个接口能返回会议，说明问题出在findMeetingTimes的参数配置上；如果也返回空，那可能是日历数据本身的问题

测试用请求示例 #

{
  "attendees": [
    {
      "type": "Required",
      "emailAddress": {
        "name": "abc",
        "address": "somebody@omni.com"
      }
    }
  ],
  "minimumAttendeePercentage": 100.0,
  "timeConstraint": {
    "activityDomain": "unrestricted",
    "timeslots": [
      {
        "start": {
          "dateTime": "2018-03-30T15:00:00Z",
          "timeZone": "UTC"
        },
        "end": {
          "dateTime": "2018-03-30T16:00:00Z",
          "timeZone": "UTC"
        }
      }
    ]
  },
  "isOrganizerOptional": false,
  "includePrivate": true
}

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