Есть ли проверенный способ обработки интервалов обновления с автоматической проверкой / установкой триггера и несколькими пользователями между несколькими электронными таблицами?

Question

Я работаю над надстройкой, которая должна обновлять электронные таблицы с заданными пользователем интервалами (от одного раза в час до одного раза в год) - есть ли умный, проверенный способ справиться с этим с помощью автоматической проверки / установки триггера и нескольких пользователей между несколькими электронными таблицами?

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

1. Проверка, установлены ли триггеры, не "видит", были ли они установлены другими пользователями, и не может им управлять (например, удалять чужой триггер, когда он больше не нужен). Есть идеи, как с этим справиться? Наличие 50 пользователей с установленными почасовыми триггерами - не лучший вариант.

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

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

Answer 1

будет ли триггер запускать вызываемую функцию во всех из них одновременно или для каждого листа требуются отдельные триггеры?

Устанавливаемые триггеры устанавливаются на [лист | документ | форма] на [пользователя] (ну, если быть точным, на проект скрипта). Учитывая тот факт, что они изолированы для каждого пользователя, они также запускаются для каждого пользователя (в отличие от простых триггеров).

Устанавливается на Open | onEdit | по изменению

Однако есть случай, когда это может быть не так просто - см. Устанавливаемый onOpen раздел триггеров в официальном руководстве. Хотя общий случай все еще сохраняется - даже если другая учетная запись вызовет его, триггер будет запущен для учетной записи создателя, которая включает квоты и все, что связано с пользователем, поэтому будьте с этим особенно осторожны.

Есть идеи, как с этим справиться?

Хотя [устанавливаемые] триггеры не являются общими для пользователей, некоторые ресурсы разделяются между ними, поэтому у вас есть по крайней мере два возможных способа борьбы с одновременным срабатыванием триггеров:

1. Предпочтительный способ: LockService. Он специально разработан, чтобы избежать состояний гонки, таких как ваш случай: просто подождите (или измените расписание, если действие может занять более 5 минут), пока блокировка не будет установлена ​​(обратите внимание, что вам нужно использовать скрипт или блокировку документа).
2. Резервный способ: если вы намерены разрешить пользователям одновременно взаимодействовать с пользовательским интерфейсом, блокировка не сработает (по дизайну). Вы правильно поняли, как использоватьPropertiesService(Я предполагаю, что это то, что вы имели в виду, говоря "добавление свойства"), но будьте осторожны, чтение / запись регулируются квотами.
   Я недавно ответил на аналогичный вопрос - у него есть рабочий и проверенный образец эмуляции LockService поведение с PropertiesService (но опять же будьте осторожны с квотами).

Заметки

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