Skip to content

Instantly share code, notes, and snippets.

@vanstee
Created September 12, 2013 05:04
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save vanstee/6533226 to your computer and use it in GitHub Desktop.
Save vanstee/6533226 to your computer and use it in GitHub Desktop.

How do you see detaching bookings from the recurrence working?

This isn't implemented yet, but I was planning on letting you do a normal reschedule, except if the booking belonged to a recurrence the original booking would be set to hidden while a separate booking would be created with the updated attributes. Altering the recurrence would no longer change the newly created booking. Implementing booking deletion would work the same way just without creating a new booking in it's place.

Example:

# Create a recurrence and generate bookings

POST /events/1/recurrences

{
  "start": "2013-07-26T19:00:00.000Z"
  "end": null,
  "booking-length-seconds": 1800,
  "frequency": "weekly",
  "room-id": "1"
}

# Decide to move a booking (found with a booking search)

POST /bookings/1/reschedule

{
  "to": {
    "start": "2013-07-26T19:05:00.000Z", # moved 5 minutes into the future
    "end": "2013-07-26T110:05:00.000Z"
  },
  "seq": 0
}

Now the previous booking with id 1 would be hidden and no longer accessible by the api. We would basically only keep it around in case we need to regenerate bookings for some reason.

There would also be a new booking the a 5 minute offset compared to the other generated bookings. However, this one would no longer be considered a part of the recurrence and the recurrence_id would be blank, but it would still belong to the same event.

And also listing recurrences

I hadn't thought too hard about this yet. I figured the booking and event searches would be enough. Let's talk about what exactly you need here.

Do bookings generated as part of a recurrence have a recurrence-id now?

Yes. I haven't yet added this to the serializer so you wont see it in the JSON response. Thanks for reminding me.

@jeremy-w
Copy link

There would also be a new booking the a 5 minute offset compared to the other generated bookings. However, this one would no longer be considered a part of the recurrence and the recurrence_id would be blank, but it would still belong to the same event.

For compatibility with iCal, we should probably leave the recurrence-id on there. iCal has a thing where the ID remains the originally scheduled date-time but the date and time value are set to the new values.

Later, you should probably be bumping the seq number whenever the date/time gets changed. The sequence number is how iCal clients know they're not up to date.

I hadn't thought too hard about this yet. I figured the booking and event searches would be enough. Let's talk about what exactly you need here.

I think I might have meant just GET /event/:event-id/recurrences/:id, rather than GET /event/:event-id/recurrences/. I can probably get the ID whenever I care about it from the booking or event search, so you're right: we don't need to worry about that now.

@randomstep
Copy link

iCal calls them 'detached' instead of 'hidden'. Forgot the term used for deletion - maybe 'deleted'. :)

@vanstee
Copy link
Author

vanstee commented Sep 13, 2013

Cool. Let's try to copy iCal on that then. I'll add detached and deleted attributes to bookings.

Oh yeah I almost forgot about the seq number. Thanks @jeremy-w.

@jeremy-w
Copy link

OK, been looking at this API some more. It looks pretty good. Users don't edit recurrences. They edit bookings, and so indirectly edit recurrences. It's easy to understand.

Rescheduling a booking works well. It'd be nice to have a "also-future: true" option we could use with recurring bookings. We need something similar for DELETE to truncate a recurrence, but putting a body in a DELETE seems funky, but it might still be the best way to do it.

Translating this into EKEvent-speak seems tricky; we might need to do it as a step after, where we fetch the details of the recurrence (including detached and canceled meetings) and update the calendar store to match.

@jeremy-w
Copy link

@vanstee What do we need detached and deleted attrs for? We don't really care about that except when we need the full recurrence info. Our main gateway into bookings is search, and we just won't find the deleted one any more.

@vanstee
Copy link
Author

vanstee commented Sep 18, 2013

@jeremy-w After detaching a booking from a recurrence, wont you need to know that it's detached so you don't show the normal recurrence options like "frequency" and "Update all future bookings" as well?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment