mirror of
https://github.com/bulwarkmail/native.git
synced 2026-11-01 00:07:01 +00:00
Linus Rath
e6baa751a9
More edits of a recurring meeting went wrong at the edges of a series (0.16 and 1.0 alike, attendees included): - A series the app shows as itself - opened from a reminder or an event link, or one an edit just made recurring (0.16 before 0.16.20 showed it until the next reload) - took "This event only" as a change of the whole series: `CalendarEvent/set` on the series' id with the editor's title, start and rule. "Delete this event only" deleted the series. The series now stands for its first occurrence: a change becomes an override of it, in two writes when the user organizes the meeting, sends invitations and an attendee has answered (Stalwart sends a new override only to attendees who have not), and a delete excludes it. "This and following" from the first occurrence changes, or deletes, the whole series instead of ending it before its first occurrence. A series opened from a reminder on a calendar shared with the user is now known to the store, so the change goes to the owner's account under the series' own id. - An edit that makes an event recurring, or single again, now loads the range again, so the grid shows the occurrences instead of the series itself. - 0.16 (0.16.23 checked) reads a rule's UNTIL as the series' wall clock taken for UTC, so in a zone behind UTC a split or "delete this and following" kept the occurrence it was to end before. The UNTIL is now earlier by the zone's offset (the larger of the split's day and the day before), which ends the series there on 0.16 and 1.0 alike. - 0.16.6 to 0.16.23 send a change of one occurrence with its SEQUENCE raised but do not keep the raise, so a later change of every occurrence - a new title - went out with a lower number for that occurrence and the attendee's server refused it. A change of every occurrence that the user as organizer sends, of something the attendees see, on a series with changed occurrences, now raises the SEQUENCE of the series and of each changed occurrence by one. 1.0 raises and keeps the number itself; the result there is the same. The app's update sends `sequence` as it is, so nothing has to keep it. - An existing override written on the base event (0.16 before 0.16.20, and ranges the device expands) gets the series' organizer again when it has none: 0.16.19 refuses an answer to such an occurrence. 1.0 refuses the key inside an override once, and the store writes the override again without it.