Apps Script потерял доступ после смены владельца таблицы: что проверить

Передача Google-таблицы другому владельцу не всегда переносит полномочия автоматизации. Скрипт, привязанный проект, устанавливаемые триггеры, OAuth-разрешения и развертывание web app могут принадлежать разным учетным записям.

Нужно составить карту владельцев: файл Sheets, проект Apps Script или Cloud Project, триггеры, подключенные ресурсы и развертывания. Затем восстановить разрешения и пересоздать только те объекты, которые действительно исполняются от прежнего владельца.

Что проверить в первую очередь

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

• Уточните, скрипт привязан к таблице или является отдельным проектом.
• Проверьте владельца файла, проекта, shared drive и связанного Google Cloud Project.
• Откройте раздел триггеров под старой и новой учетной записью.
• Определите, от чьего имени выполняется web app и какие OAuth scopes использует.

Почему возникает проблема

У подобных сбоев редко бывает одна универсальная причина. На итог одновременно влияют конфигурация приложения, окружение, данные, кеш, права и внешние сервисы. Проверка должна идти от внешнего симптома к конкретному уровню, на котором впервые появляется неверное состояние.

• Installable trigger создан прежним владельцем и выполняется с его разрешениями.
• Новый владелец файла не выдал OAuth-согласие скрипту на нужные scopes.
• Скрипт открывает другой файл по ID, к которому новая учетная запись не имеет доступа.
• Web app развернут старым аккаунтом и продолжает исполняться от его имени.
• Файл перенесен в shared drive, где правила владения и доступа отличаются.

Пошаговая диагностика

Диагностику проводите на копии или в контролируемое время. Перед изменениями сохраните конфигурацию, данные и журналы. Каждый шаг должен отвечать на один вопрос и оставлять измеримый результат: код ответа, запись в логе, состояние процесса, значение поля или воспроизводимый тест.

• Запустите проблемную функцию вручную под новой учетной записью и зафиксируйте точную ошибку.
• Проверьте Executions: функцию, инициатора, тип запуска и stack trace.
• Выведите IDs используемых файлов и проверьте доступ к каждому без публикации содержимого.
• Сравните список триггеров и развертываний у обеих учетных записей.
• Проверьте манифест appsscript.json, scopes и привязанный Cloud Project.

Что не переносится вместе с таблицей автоматически

Доступ редактора к таблице не равен праву выполнять все действия скрипта. Некоторые сущности персональны для создателя.

• Устанавливаемые триггеры принадлежат пользователю, который их создал, и обычно требуют пересоздания.
• OAuth grants выдаются каждой учетной записи отдельно и могут быть ограничены администратором Workspace.
• Развертывание web app имеет собственные параметры execute as и who has access.
• Связанный Cloud Project, секреты и API могут остаться под управлением старой организации.
• Доступ к внешним таблицам, папкам и почте нужно проверять отдельно.

Как исправить проблему

Исправление лучше разбить на небольшие обратимые изменения. После каждого шага повторяйте исходный сценарий и проверяйте соседние функции. Если правка касается данных, сначала выполните ее на ограниченной выборке и сохраните журнал затронутых записей.

• Авторизуйте проект под новой учетной записью с минимально нужными scopes.
• Удалите устаревшие триггеры после проверки и создайте новые от нужного технического владельца.
• Передайте или переопубликуйте web app с согласованным режимом исполнения.
• Выдайте доступ к зависимым файлам и папкам через группы или shared drive.
• Для критичной автоматизации используйте управляемую техническую учетную запись и документированную передачу.

Безопасный порядок внедрения

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

Как проверить результат

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

• Ручной запуск и каждый тип триггера завершаются успешно под ожидаемым исполнителем.
• Executions не показывают permission denied и обращения к недоступным файлам.
• Web app работает для разрешенных пользователей после нового развертывания.
• Отключение старой учетной записи не останавливает автоматизацию.

Типичные ошибки при исправлении

• Передавать пароль от личного Google-аккаунта вместо передачи ресурсов и ролей.
• Создавать дубли триггеров и получать двойные письма или записи.
• Запрашивать полный Drive scope, когда достаточно доступа к отдельным файлам.
• Удалять старое развертывание до проверки нового URL и клиентов.

Как предотвратить повторение

Профилактика строится вокруг наблюдаемости и воспроизводимости: понятных конфигураций, контролируемых релизов, журналов без секретов и тестов на реальные сценарии. Важно не просто убрать текущий симптом, а сделать следующий похожий сбой заметным раньше пользователя.

• Ведите реестр файлов, проектов, триггеров, владельцев и внешних зависимостей.
• Используйте группы и shared drive там, где это поддерживается политикой Workspace.
• Документируйте OAuth scopes и процедуру смены технического владельца.
• Добавьте уведомление о сбоях Executions и регулярную проверку триггеров.

Что подготовить для разбора

• Краткое описание ожидаемого и фактического поведения без паролей, токенов и персональных данных.
• Точное время и последовательность действий, после которых появляется проблема.
• Версии приложения, окружения и зависимостей, а также перечень последних изменений.
• Фрагменты журналов с контекстом до и после ошибки; секреты в них необходимо скрыть.
• Описание уже выполненных проверок и способ безопасно повторить проблему.

Частые вопросы

Почему простой onEdit работает, а триггер по времени нет?

Простой триггер запускается в другом контексте, а устанавливаемый принадлежит создателю и использует его разрешения. Их нужно проверять отдельно.

Можно ли просто скопировать таблицу?

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

Когда нужна помощь специалиста

Если Apps Script перестал работать после передачи таблицы или аккаунта, я могу составить карту зависимостей, восстановить триггеры и доступы без дублей и оформить автоматизацию так, чтобы следующая смена владельца прошла предсказуемо.