-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hold invites #768
Hold invites #768
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MelissaAutumn This is still wip, but feel free to already take a look at it. Except for the remote event deletion, everythings already working fine on Google and CalDAV on my end.
30f0160
to
d8a8365
Compare
…s we create, and use that for deletions. Also fix issue existing requests could reference the wrong calendar.
Fixed the issue. It turns out Google needs their internal id field to delete events, and not the one we create via their import method. So once we save an event it returns the event object back to us, so I just store it on appointment.external_id (new field!). CalDAV doesn't need to use this field, so it falls back to uuid. Also discovered that it may fail if the user deletes their event before they reject the request. I'm not sure if we want to handle that any differently thank a "link is invalid" error. Additionally I discovered if you switch the schedule's calendar, delete and update requests were being attempted on the schedule's calendar and not the appointment's calendar (the one it's actually on.) so I patched that up. Feel free to give it a try again to see if it all works on your end now! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent work @MelissaAutumn 👏🏻 Google event deletion on denial works flawlessly now on my end too!
Also discovered that it may fail if the user deletes their event before they reject the request. I'm not sure if we want to handle that any differently thank a "link is invalid" error.
I think it's fine to keep that error for now and see, if we want to maybe make that more specific in the future if we need it.
Additionally I discovered if you switch the schedule's calendar, delete and update requests were being attempted on the schedule's calendar and not the appointment's calendar (the one it's actually on.) so I patched that up.
Oh, thank you! Didn't think of that particular case. Maybe we should also inform the user about open bookings when switching calendars on the schedule page or disabling them in the settings? Just as idea to improve the UX at that point, but out of scope here.
Imo we can merge this now.
Description of the Change
This change implements the previously discussed hold event flow.
This still needs heavy testing for both: Google and CalDAV.
Applicable Issues
Fixes #459