У меня есть система отслеживания повторяющихся сроков, основанная на API Календаря Google. События используются для моделирования задач с дополнительным состоянием, сохраненным в sharedExtendedProperties: например, номером учетной записи, назначенной задаче, категорией задачи, статусом домена и т. Д. Это состояние может и меняется от экземпляра к экземпляру.
Когда пользователи устанавливают задачи, они не знают, сколько месяцев они будут повторяться. Поэтому изначально в правиле повторения не задана дата UNTIL. В конце концов, они хотят установить дату до тех пор, пока не узнают последнее задание в серии. Они также могут изменить промежуточное правило правила повторения: например, изменить сроки исполнения в определенный момент со 2-го вторника каждого месяца до 11-го числа каждого месяца.
В любом случае механизм, используемый для этого, заключается в изменении существующей серии повторений для установки даты UNTIL (и во втором случае также для создания новой серии, начиная с этой даты вперед).
Это прекрасно работает, только если нет исключений из правила повторения среди экземпляров существующего ряда повторений . Если существует единственное исключение originalStartTime, скажем, один экземпляр был перемещен обратно со 2-го вторника на следующий день, то создается впечатление, что при изменении правила повторения все экземпляры стираются и восстанавливаются из начальное состояние «мастер» recurringEventId запись . Это означает, что они теряют изменения состояния, которые они сделали во всех экземплярах, так как они первоначально создали серию событий.
Я могу сделать что-то вроде сохранения всего состояния до внесения изменений в повторение, затем после изменения вернуться назад и исправить каждый экземпляр по одному, сопоставляя их с originalStartTime (если и только если были какие-либо исключения ) - но это довольно грязно и отнимает много времени.
Есть ли лучший способ справиться с этим?