Link copied to clipboard
By Gregory Yakushev, Software Engineer
Today we are introducing new behavior for “all-following” changes to recurring events. Previously, we cut a recurring event at the point an “all-following” change was made and created a new recurring event starting at that point. Now, in most cases we keep the recurring event intact, while still applying the relevant changes to all following instances.
This means that users can now perform operations on the entire recurring series even after an “all-following” change has been made. They can modify, reply to, delete, or apply additional “all-following” changes. Also, in many cases, changes to specific instances of a recurring event will still be preserved after an “all-following” change.
To preserve backward compatibility, API clients will still see a separate recurring event after each “all-following” change. A separate post will announce API support for making these “all-following” changes and accessing whole recurring events with multiple “all-following” changes in them.
For example: suppose I have a recurring event “Daily Meeting” for my team. Paul knows that he will be on vacation, so he declined a few instances next month. I know that we will get new intern in a month, so I invite him starting next month to “all following” instances. Also I want to move it to a different room starting next week, so I change location and apply to “all following” instances.
After all these operations Paul's responses are still preserved: I see that he will not attend a few meetings next month. I also see that on instances two months ahead both of my “all-following” changes are reflected correctly: the room is changed and intern is invited. And all attendees still see all “Daily Meeting” instances as one recurrence: they can accept, decline or remove all of them with one click.
Grisha Yakushev ensures Calendar servers keep your data consistent and safe. He enjoys travelling the world, preferably by hitchhiking.
Posted by Scott Knaster, Editor
