Implement a solution for cancelled events

[fyliu]

Overview

We need a solution to implement cancelled events, which needs to be displayed so that users can still see them as cancelled rather than having them disappear from the calendar.

Action Items

• [ ] [team discussion] Decide on an implementation strategy
• [ ] Implement it
• [ ] take #57 out of the ice box

Requirements

• We are using django-recurrence, which gives us recurring events. We need a custom behavior which is to show events as cancelled rather than have them simply disappear.

Discussion

From #88 comments

• does DR (Django-recurrence) replace this issue Create Table: cancelled_event #57
• In a word, NO. But we can make it work. See the next point.
• Functionally, we don't need a list of cancelled events that #57 would provide. We really need a list of "all" events, including cancelled ones. DR doesn't come with a way to return all events including cancelled ones. It only does the "smart" thing and return all included events minus all excluded ones. Given it provides so much out of the box (models, managers, wrapper code around dateutil.rrule.rrule and rruleset, etc.), I think we still want to keep it rather than implement our own. The way I see it is we have options to give us the cancelled events we need, with tradeoffs.
  1. add the functionality in DR to return all events with cancellation status. There are sub-options in this and we have flexibility to choose one that best fits our needs. This is the place to modify.
  2. we can make the default behavior do what we want, which is to return the unfiltered events list with an added field for whether or not each one is cancelled. This is okay since we're the only one using this modified code. It'll break the existing tests because we're modifying the underlying assumptions about the behaviors of that code. On the up side, it's cleaner when we use it. We just call the same interface and it does exactly what we want. We can fix the broken tests too.
  3. we can leave the default behavior that gives us all the non-cancelled events, and add a separate function to give us only the cancelled events. Code-wise, this is cleaner. It leaves the existing code and tests that go along with them. Interface-wise, This is messier, since it adds a little extra work when we use it, since we would need to combine the lists. Ultimately, it's up to how VRMS wants the data. It could be that they also need just the cancelled events for one of their displays.
  4. add an exdate array (list of excluded dates, meaning cancelled events) outside of DR RecurrenceField and don't set the exdate field inside RecurrenceField. This will make DR give us all the event dates and we manually apply the cancelled dates. This is less good since it means having an extra field, but it means we can use the RecurrenceField without modification. It's also less good if we consider the case where we want to use the exrule (recurrence rule that is an exclude, like NOT on the first Wednesdays of the month)
• We should discuss these options as a team to see what we think of each one. We should also talk to VRMS about what they need from this.

[fyliu]

Just wanted to say that I'm pretty sure one of the methods I listed above will work and we won't need the cancelled_events table.

[janebirman]

Can we create a boolean field for cancelled_events, such as the approved answer in this post? Would using a Django flag be necessary?

[fyliu]

This should depend on the main event issue from #88 being finished so we have a better idea what we have to work with. Once #88 is fully described, then we can put the issue number in the depedency and can put this in the ice box.