http://tools.ietf.org/html/rfc5545#page-23 Simple fix in ical.js this is a cross tracking bug.
We need to add support for the RANGE=THISANDFUTURE "exceptions" in the recurring event expansion layer. If we don't fix this we will incorrectly display events which have this exception. From various calendar interfaces its easy to change all future instances of an event so I expect this is a fairly common use case.
Severity: normal → major
blocking-basecamp: --- → ?
Priority: -- → P2
QA Contact: jlal
Summary: ICAL - handle "THISANDFUTURE" → Handle recurring event exceptions for "THISANDFUTURE"
I think you meant to set assignee.
Assignee: nobody → jlal
QA Contact: jlal → nobody
Unlikely anyone will take this bug if you're already assigned. What's the fix here? Les, do you have cycles to fix this?
Driver retriage: Uncommon user scenario. Would take a patch on approval once all P1s are fixed. Adding qawanted for better understanding of user impact. If there's a serious user impact, please re-nominate for blocking.
blocking-basecamp: + → -
tracking-b2g18: --- → +
(In reply to Dietrich Ayala (:dietrich) from comment #4) > Driver retriage: Uncommon user scenario. Would take a patch on approval once > all P1s are fixed. > > Adding qawanted for better understanding of user impact. If there's a > serious user impact, please re-nominate for blocking. Guarantee James will be a better person to ask to get more info on this rather than me. James - Can you elaborate on actual scenarios that could cause someone to hit this? Specifically looking for say, a test case that could be run end to end to reproduce this.
This is a similar issue to the recurring event bug where we only display 500 messages. If we don't do this we will display the users events incorrectly. It depends on how they modify it.. Maybe we show extra events maybe we show them at the wrong time... Either way we should handle this and (IMO should also be P1 so we can deal with it sooner rather then later). This is not totally uncommon. This can easily be done in Google Calendar's UI and in Zimbra's. I believe its harder to find (if at all) in Yahoo's UI. This is another spec completion issue. We have a few blind spots and this is the most important of those (IMO). Its true it is used much less but it should still be a priority.
Back into triage it goes then! If more information is needed, then feel free to inquiry.
blocking-basecamp: - → ?
tracking-b2g18: + → ---
based on comment 6, bb+
We need to land the incremental logic first then update the ical layer before we can persist the state of the iterator (probably needed otherwise this will be too slow).
Depends on: 796743
Does not actually depend on 796743 looking into it further... What I thought was google/yahoo/zimbra using "THISANDFUTURE" is actually them splitting the event up into multiple events (which we handle now). We _should_ support this but let me see if I can actually find a server that uses "THISANDFUTURE" to test against.
No longer depends on: 796743
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [email@example.com][LOE:S] → [firstname.lastname@example.org][LOE:S][qa-]
Whiteboard: [email@example.com][LOE:S][qa-] → [firstname.lastname@example.org][LOE:S][qa-], QARegressExclude
You need to log in before you can comment on or make changes to this bug.