Первоначальный ситуация:

  • В одном из наших сервисов мы используем сервисный аккаунт для вызова Google Calendar API.
  • Пользователь может поделиться своими календарями с этой технической учетной записью через свой технический адрес электронной почты (@ .iam.gserviceaccount.com).
  • Поскольку календари используются совместно, мы можем запрашивать их через API (CalendarList / List: https: //developers.google.com/calendar/v3/reference/calendarList/list )
  • Все это работало нормально в течение нескольких лет без проблем.

Текущий номер:

  • Как мы недавно обнаружили, новые общие календари больше не возвращаются через вызов API. Календари, которыми делятся в прошлом, все еще возвращаются (!)
  • Мы знаем о PageTokens и обрабатываем их - это не может быть проблемой. В случае одной (тестовой) учетной записи в настоящее время используется только 8 календарей, и мы не можем получить больше.
  • Нет ошибки / предупреждения во время вызова на бэкэнд-стороне
  • В консоли разработчика Google нет ошибок, предупреждений и квот

Мы не получили никаких предупреждений или предупреждений от Google об изменениях API Календаря или ограничениях наших аккаунтов. Также я не нашел ни одной общеизвестной проблемы / сбоя в работе Календаря Google.

В чем может быть проблема?

Должен ли я сообщить об этом в Google? Если да, то как именно? Все, что я мог найти, это «Устранение неполадок пробной версии Google Cloud Platform», где (кроме предложения использовать stackoverflow;]) все, что я могу сделать с «конкретным вопросом и технической поддержкой», это «запустить чат», что приводит на внутренний сайт Google (moma). Могу ли я попробовать что-нибудь еще?

Любая помощь приветствуется!

< Сильный > UPDATE : В качестве косвенного следа / намека в официальных документах, что Google изменил это поведение (автоматически) принятия общих календарей - сравните текущую и августовскую версии раздела «Поделиться существующим календарем» 2019 года:

ОБНОВЛЕНИЕ 2 Мне удалось сообщить об этой проблеме в Google благодаря @DaImTo (требуется аккаунт Google): https://issuetracker.google.com/issues/148804709

Дело в следующем:

  • «Из-за недавнего изменения поведения любая учетная запись должна явно« принять »Календарь, который был им предоставлен».
  • Статус: не исправить (предполагаемое поведение)
2
gabowsky 3 Фев 2020 в 12:25

3 ответа

Лучший ответ

Там было недавнее изменение

После того, как вы поделились календарем с учетной записью пользователя / службы, эта учетная запись пользователя / службы должна «принять» общий доступ, добавив общий календарь в свой список календарей.

Это можно сделать (в случае пользователя) из пользовательского интерфейса, нажав «Добавить этот календарь», или программно (работает как для пользователей, так и для учетных записей служб) методом CalendarList: insert.

4
ziganotschka 3 Фев 2020 в 12:50

CalendarList.List Возвращает календари в списке календарей пользователя.

Это не обязательно все календари, к которым у пользователя есть доступ. Список пользователей календаря отображается в левой нижней части веб-приложения Google Calendar

enter image description here

Когда пользователю предоставляется доступ к новому календарю, он принимает доступ по электронной почте. Когда они это делают, календарь обычно добавляется в их calendarlist.list. Этого не происходит со служебной учетной записью, поскольку у нее нет возможности проверить электронную почту и принять приглашение, к которому у него есть доступ.

Если вы хотите, чтобы календари были добавлены в список календарей служебных учетных записей, вам нужно будет вставить их через служебную учетную запись. используя calendarlist.insert

Я не уверен, почему вы думаете, что это работало в том прошлом, я использовал этот API в течение многих лет и никогда не беспокоился об использовании calenadarlist с учетными записями служб по этой самой причине.

  1. Пользователь делится своим календарем с адресом электронной почты учетной записи службы 2. При выполнении CalendarList / List мы ожидаем вернуть все календари, включая тот, который использовался на шаге 1. Ситуация такова, что вызов API возвращает только «ранее опубликованный» календари, но не тот, которым мы делимся сейчас. Я надеюсь, что разъяснил немного - если нет, пожалуйста, задавайте конкретные вопросы, спасибо!

Нет способа вернуть все календари, к которым у пользователя есть доступ. TBH ответ будет огромным, учитывая все открытые календари в дикой природе, они также будут возвращены.

Совет по использованию сервисных аккаунтов.

Служебные учетные записи не предназначены для того, чтобы вы раздавали пользователям доступ к своим календарям. Сервисные учетные записи предназначены для вас, чтобы разработчик имел статический календарь, который вы можете использовать в своем приложении, и сохранять в нем данные.

Если вы обращаетесь к календарю пользователей, вам следует использовать Oauth2 и сохранять токен обновления, если вам нужен доступ к их данным, когда они не в сети.

Сообщить о проблеме

В последнее время было много изменений в учетных записях служб и календаре Google. Я сам сообщал о проблемах с серверами за последние несколько месяцев форум по вопросам Я предлагаю вам представить это как проблему. Ссылка здесь, и я посмотрю, смогу ли я найти свой контакт в этой команде, чтобы пинг по этой проблеме.

1
DaImTo 4 Фев 2020 в 08:55

Еще одно решение этого

1) Добавить календарь в свой аккаунт Google

2) Поделиться календарем с идентификатором электронной почты учетной записи службы

3) Перейдите в Настройки и Общий доступ во вновь созданном календаре и найдите Идентификатор календаря .

4) Перейдите по этой ссылке - https://developers.google.com/calendar/ v3 / ссылка / calendarList / вставка

Это пример кода PHP для добавления существующего календаря в учетную запись службы

$calendarListEntry = new Google_Service_Calendar_CalendarListEntry();
$calendarListEntry->setId("calendarId");

$createdCalendarListEntry = $service->calendarList->insert($calendarListEntry);

echo $createdCalendarListEntry->getSummary();

5) Теперь вызовите API Списка Календаря, и вы найдете добавленный идентификатор календаря в Списке календаря служебной учетной записи.

0
Sahil Tanna 17 Мар 2020 в 05:43