Add Recurring Office Hours Events

[ajaygandecha]

Synopsis

The new office hours feature enables instructors and TAs to create office hours events for their classes! The problem, is, you cannot make recurring events. Dealing with recurring events correctly is a large challenge, since events are linked to each other.

Your mission, should you choose to accept it, is to implement the ability to add recurring office hours events for the XL site.

Acceptance Criteria

• [ ] Creating a recurring event should give a start and end date, as well as options to select days of the week.

• [ ] Deleting a recurring event should give a dialog asking whether or not to delete all future recurring events. Pressing "yes" should delete the selected event and all future ones. Pressing "no" should delete only one event. Note that the events following the selected event should still be linked such that deleting another event should give the same options and still work.

• [ ] Editing a recurring event should give a dialog asking whether or not to update all future recurring events. Pressing "yes" should update the selected event and all future ones. Pressing "no" should update only the selected event. Then, the selected event should no longer be considered a recurring event. Consider this chain of recurring events:

  [ 1 ] --> [ 2 ] --> [ 3 ] --> [ 4 ] --> [ 5 ]

  Updating [ 2 ] should ensure that event is no longer part of the chain, but that [ 3 ] is considered a recurring event of [ 1 ]. Therefore, choosing to delete [ 1 ] should give the option to delete [ 3 ]- [ 5 ] as well.

• [ ] When updating the days of the week of a recurring event and selecting "yes" to update future recurrences, these changes should be propagated, creating and deleting future events as necessary. For example, if OH are scheduled MWF and a Monday event is updated to TTh, the W and F events should be deleted, and T Th added.

First Steps

If your team chooses to accept this, please list yourself as "assignees" to this ticket! Then, begin to work on a backend entity diagram design and a frontend design on Figma. Then, comment them here on this ticket for approval! From there, you can begin creating a branch for this feature.

Work on a branch called reccuring-oh-events.

For approvals, we will work in this order:

1. Backend Review: Tests to ensure your backend is working properly.
2. Frontend Review: Ensures your frontend looks good!

For tips on what we will look for, check out the Contributing Guidelines.

[jadekeegan]

Backend Entity Diagram:

Changes to Backend:

• Created OfficeHourRecurrenceEntity to represent an recurrence pattern.
• Added "recurrence_id" foreign key to OfficeHourEntity to associate events with a specific recurrence pattern.

[jadekeegan]

Frontend Office Hours Event Creator:

Frontend Office Hours Event Editor

Notes:

• For OH purposes, the only options for the Recurrence Pattern field is "Does not repeat" or "Weekly". Backend is set up to allow for other recurrence patterns, but for OH weekly is probably sufficient.
• The end time of the recurrence is automatically set to the end of the term.
• Changing to "Weekly" makes the days of the week selection appear.
• If the event has a recurrence pattern and the time is changed, the "Recurrence Update Options" appear.
• If the event has a recurrence pattern and the days are changed, the update options do not appear, as all future events should automatically be updated.

[jadekeegan]

@ajaygandecha @KrisJordan Backend entity diagram and frontend editor form Figma commented above! Let me know if there are any changes I should make. I'll get started on code on Tuesday during my OH.

[ajaygandecha]

@jadekeegan wow LGTM, great work!! 🚀

[KrisJordan]

This is looking really great; loving the UX

My initial thinking is to go in one of two ways with the recurrence entity.

1. Fold it directly into office hours entity (it's already 1-to-1 as designed, correct?). Perhaps make the fields like: recurs (bool), recur_start_date, recur_monday prefixed. I'm not sure I grok the need for the frequency field?
2. (More complex) Make the relationship 1-many where 1 "office hours" can have many recurrence patterns. Move the start_time and end_time to the recurrence pattern. Default is no recurrence at a specific time. However, this would allow for one event in the same room to have gaps in time rather than creating two separate events.

My inclination is to keep it simple and go with #1. In the context of managing recurring office hours, I think #2 is overkill.

[jadekeegan]

This is looking really great; loving the UX

My initial thinking is to go in one of two ways with the recurrence entity.

1. Fold it directly into office hours entity (it's already 1-to-1 as designed, correct?). Perhaps make the fields like: recurs (bool), recur_start_date, recur_monday prefixed. I'm not sure I grok the need for the frequency field?
2. (More complex) Make the relationship 1-many where 1 "office hours" can have many recurrence patterns. Move the start_time and end_time to the recurrence pattern. Default is no recurrence at a specific time. However, this would allow for one event in the same room to have gaps in time rather than creating two separate events.

My inclination is to keep it simple and go with #1. In the context of managing recurring office hours, I think #2 is overkill.

I think it's a events-recurrence is actually a many-to-one, and we might need it separate in order to have every associated recurring event change if you change the pattern. The frequency field doesn't have any utility for us right now if we assume that all recurrences should just be weekly as opposed to daily/monthly/etc.