There's two things I feel are missing with recurring events:
1. Most of the time, I'd rather avoid setting an end date because there actually is no end date ("repeat until"). Currently, what I do is set an end date a few years in the future but this is almost bound to give us trouble at some point in time when those events *should* still be available but suddenly are not. It would be nice to be able to simply not set this. If it's not set, the event simply will keep on recurring until the end of time ;-)
2. A little more complex: Most calendars (including Google Calendars) support overriding specific instances of a recurring event. Like, for instance if you have a weekly meeting, every Friday, but Friday 13th you decide you want to cancel the meeting (for obscure reasons ;-) ). As far as I can tell, currently you'd need to create two recurring events: One before Friday 13th, and another one after Friday 13th. In the long run, that means that you'll end up with a lot of events even though it's actually always the same one. So, a better solution would be having two ways of "overriding" individual instances of a recurring event: a) give a specific date where the event is "cancelled" (that would solve the use case of the example given above); and b) overwrite the event with different data. The use case for b) is when you want to make a special note for that instance, e.g. if someone stands in for the usual trainer; or when there's something "special" - it would still be the same event but you'd be able to make changes to all the fields. Another use case would be featuring one specific instance of a recurring event.
I can see that this is not trivial to implement - but I think there's a rather straightforward solution: In EventsCalendar, you could add a foreign key linking to "ItemID" (RecurringOverrideEventID). Furthermore, you'd need an int field "OverrideInstanceType", which is "null" for any "normal event". Now, when an instance is overriden, a new entry is added to EventsCalender with RecurringOverrideEventID = ItemID of the original recurring event. This new entry has "OverrideInstanceType" not null. If it "cancels" the original event, this could be "-1", if it overrides the original event, it could be "1" (whatever works for you). When building the calendar lists for the different views, you'd need a second query that checks if there's "override events" for any of the recurring events in the current dataset. And if so, do the relevant "overwriting" (remove from dataset, or replace the entry with the data from the replacement event). Obviously, that will generate a little performance hit, but I doubt that should be too severe, and the functionality should be extremely useful in many cases.
From the user-interface perspective, one way of handling this would be appending a list of "override events" at the end of recurring events. To create a new event, you'd have a link similar to "Copy As New". However, instead of creating a new "separate" event, it would create a "linked event" that either removes a specific date or overrides a specific date. For user-convenience, you could change the Start Date/Time and End Date/Time fields to allow the user to select from a list (if 1. is implemented and there is no real end date, you could go "1 year into the future" to avoid running into an infinite loop ;-) ). Furthermore, you'd have a checkbox "delete specific date" - if that checkbox is checked, the only ui-element that would remain is the date (since there's no data to be added or overridden in that case).
In the list of "override events" which is accessible through the main event, you can go into "edit mode" for any specific event; or delete an "override event" (which would either make the instance that was "deleted" re-appear or restore the original data for a specific instance). |