351850 - It's possible to mark all occurrences of recurring event as exception

Status: NEW

(Calendar :: Internal Components, defect)

Description

[Stefan Sitter [:ssitter]]

It's possible to mark all occurrences of recurring event as exception

Steps to Reproduce:
1. Start Sunbird with clean profile
2. Create recurring event (occurs daily, repeat for 2 occurrences)
3. Select first occurrence and delete it. Select 'This occurrence' in
   upcoming dialog. (Proceed if dialog is not shown -> Bug 332266)
4. Select second occurrence and delete it too. Select 'This occurrence' again.

Actual Results:
All occurrences of repeating event are marked as exception. No occurrences are shown in calendar view. Event still shows up in unifinder if 'All Events' filter is selected. The event exported to ics looks like:

    BEGIN:VEVENT
    [...]
    RRULE:FREQ=DAILY;COUNT=2;INTERVAL=1
    EXDATE;TZID=/mozilla.org/20050126_1/Africa/Ceuta:20060904T200000
    EXDATE;TZID=/mozilla.org/20050126_1/Africa/Ceuta:20060905T200000
    DTSTART;TZID=/mozilla.org/20050126_1/Africa/Ceuta:20060904T200000
    DTEND;TZID=/mozilla.org/20050126_1/Africa/Ceuta:20060904T210000
    END:VEVENT

To-do:
Check if this is valid iCalendar code or not. 
Decide how this use case should be handled and if it should be possible or not to create such an event. 

Discussion including suggestion for workaround fix:
<ssitter> What is the error in this case?
<ssitter> That i can mark all occurrences as exceptions?
<ssitter> Or that we fail when trying to show tooltip?
<dmose> both, i think]
<dmose> that is i suspect that may be "valid" ICS, though one would have to check for sure
<dmose> but we should not fail when we see such ICS
<dmose> but also, we shouldn't be generating that sort of ICS ourselves, since it doesn't really make sense
<lilmatt> If you delete the 2nd to last instance of a recurring event, we should convert it to a non-recurring event?
<lilmatt> it == the remaining event
<lilmatt> instance
<dmose> that's less clear, i suppose
<dmose> probably need to do some RFC reading here
<dmose> as well the bis inet drafts
<lilmatt> Well, by saying "we shouldn't generate that sort of ICS ourselves", you're saying we should clean it up when someone makes it using our app.
<dmose> yes
<dmose> but i was talking about what to do when someone deletes the very last occurrence
<dmose> i'm less sure about the right thing to do w.r.t. the second-to-last occurrence
<lilmatt> If they delete the last occurrence, the event is gone altogether.
<lilmatt> If they delete the 2nd to last, and save it, we'll generate this wonky ICS for now
<dmose> according to ssitter, that's not how it currently works
<lilmatt> Well, I guess I meant we _should_
<dmose> agreed
<lilmatt> for the last occurrence case.
<ssitter> yes, i think removing the last occ. should delete the whole event
<dmose> we should probably make it non-recurring for the case where we've removed the 2nd-to-last
<dmose> ah, good point
<dmose> there's some sort of use case question here
<dmose> about whether user wants to be able to look back at a set of meetings that were all cancelled in unifinder
<dmose> but i don't propose to sort that out now

Comment 1

[Stefan Sitter [:ssitter]]

*** Bug 355733 has been marked as a duplicate of this bug. ***

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

Ignoring the use-case dmose mentioned, I think a solution could be:
- Removing the first item from a set changes the startdate of the item (and possibly decreases the .count of the rule) such that what was previously the second item is now the first item.
- Removing the last item doesn't create an exdate, but changes the enddate or the count of the rule such that the last items is no longer part of the recurrence set.
- When there is only one item left, there is no recurrence anymore, so removing will remove the entire event.

the use-case of looking for history is a bigger item: it also influences the way normal deleting would work. If a user really cares about this, he should use the 'cancelled' state instead of deleting.