recurring appointments: exceptions not shown properly



  • If I have an exception in the Outlook calendar, Outlook shows the same summary, location, body text as in the original VEVENT. So I don’t have to copy it over to the exception.

    Could you maybe implement a workaround for this issue? I don’t think that I can convince Microsoft to change its implementation.


  • developer

    @meiser said in recurring appointments: exceptions not shown properly:

    Could you maybe implement a workaround for this issue? I don’t think that I can convince Microsoft to change its implementation.

    We can of course think about that. But before doing so, I would at least like to know whether this change would be standards-compliant behaviour (and thus improve compatibility) or a workaround (which may reduce compatibility).



  • At https://icalevents.com/support/documentation/ics-guides/ under “Development and Testing Resources”, I looked at the “Tests for Recurrence Updates and Exceptions” (http://www.calconnect.org/tests/recurr_ical_streams.doc).

    In that doc, there’s an example for an exception. The only difference to the Outlook VEVENT is (from what I can see), the the SUMMARY is put into the VEVENT with the RECURRENCE-ID instead of the VEVENT with the RRULE.

    Chair reschedules a single instance’s (Tuesday’s) time portion +1 hr, so from 1000-1100 on Tuesday April 26, 2005.    This should yield a recurring meeting with following date/times:
    
    
    04/25/05	0900-1000
    04/26/05	1000-1100
    04/27/05	0900-1000
    04/28/05	0900-1000
    04/29/05	0900-1000
    
    
    Stream sent to invitee:
    
    BEGIN:VCALENDAR
    X-LOTUS-CHARSET:UTF-8
    VERSION:2.0
    PRODID:-//Lotus Development Corporation//NONSGML Notes 6.0//EN
    METHOD:REQUEST
    BEGIN:VTIMEZONE
    TZID:Eastern
    BEGIN:STANDARD
    DTSTART:19501029T020000
    TZOFFSETFROM:-0400
    TZOFFSETTO:-0500
    RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=-1SU;BYMONTH=10
    END:STANDARD
    BEGIN:DAYLIGHT
    DTSTART:19500402T020000
    TZOFFSETFROM:-0500
    TZOFFSETTO:-0400
    RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=1SU;BYMONTH=4
    END:DAYLIGHT
    END:VTIMEZONE
    BEGIN:VEVENT
    DTSTART;TZID="Eastern":20050426T100000
    DTEND;TZID="Eastern":20050426T110000
    TRANSP:OPAQUE
    RDATE;TZID="Eastern";VALUE=PERIOD:20050426T100000/20050426T110000
    RECURRENCE-ID:20050426T130000Z
    DTSTAMP:20050406T205010Z
    COMMENT;ALTREP="CID:<FFFF__=0ABBE548DFE1E66E8f9e8a93d@coffeebean.com>":R
    eschedule of a single instance's time only (+ 1 hr)
    SEQUENCE:1
    ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN="iCal Chair/CoffeeBean"
    ;RSVP=FALSE:mailto:iCalChair@coffeebean.com
    ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION
    ;CN="iCal Participant/CoffeeBean";RSVP=TRUE
    :mailto:iCalParticipant@coffeebean.com
    CLASS:PUBLIC
    DESCRIPTION;ALTREP="CID:<FFFE__=0ABBE548DFE1E66E8f9e8a93d@coffeebean.com>":b
    ody
    SUMMARY:More complicated stream (5 day recurring)
    ORGANIZER;CN="iCal Chair/CoffeeBean":mailto:iCalChair@coffeebean.com
    UID:6BA1ECA4D58B306C85256FDB0071B664-Lotus_Notes_Generated
    END:VEVENT
    END:VCALENDAR
    

    So I think, it’s standards compliant to copy all properties like SUMMARY, LOCATION, etc. to the event exception.



  • @rfc2822 said in recurring appointments: exceptions not shown properly:

    … (for instance: how shall one know whether the SUMMARY has to be copied or whether it’s really empty?). …

    I’d recommend to copy the SUMMARY field if it’s not present in the exception. If it was empty, there would be a SUMMARY field with no text, I assume.

    If I fill-in a specific SUMMARY and LOCATION in the exception, the diff looks like this:

    --- test2.ics	2017-11-25 21:18:49.000000000 +0100
    +++ test2-exp-loc.ics	2017-11-26 10:18:52.000000000 +0100
    @@ -20,13 +20,13 @@
     END:VTIMEZONE
     BEGIN:VEVENT
     CLASS:PUBLIC
    -CREATED:20171125T191827Z
    +CREATED:20171126T091449Z
     DESCRIPTION:\n
     DTEND;TZID="W. Europe Standard Time":20171128T153000
    -DTSTAMP:20171125T191827Z
    +DTSTAMP:20171126T091449Z
     DTSTART;TZID="W. Europe Standard Time":20171128T143000
     EXDATE;TZID="W. Europe Standard Time":20171205T143000
    -LAST-MODIFIED:20171125T191827Z
    +LAST-MODIFIED:20171126T091449Z
     LOCATION:location2
     PRIORITY:5
     RRULE:FREQ=WEEKLY;BYDAY=TU
    @@ -49,18 +49,27 @@
     END:VEVENT
     BEGIN:VEVENT
     CLASS:PUBLIC
    -CREATED:20171125T191827Z
    +CREATED:20171126T091449Z
    +DESCRIPTION:\n
     DTEND:20171130T143000Z
    -DTSTAMP:20171125T191827Z
    +DTSTAMP:20171126T091449Z
     DTSTART:20171130T133000Z
    -LAST-MODIFIED:20171125T191827Z
    +LAST-MODIFIED:20171126T091449Z
    +LOCATION:location2-exp
     PRIORITY:5
     RECURRENCE-ID:20171128T133000Z
     SEQUENCE:0
    +SUMMARY:test2-exp
     TRANSP:OPAQUE
     UID:040000008200E00074C5B7101A82E00800000000A08FD262365DD301000000000000000
     	0100000002C09D751F5A73F44850FE0D9795AB603
    +X-ALT-DESC;FMTTYPE=text/html:<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//E
    +	N">\n<HTML>\n<HEAD>\n<META NAME="Generator" CONTENT="MS Exchange Server ve
    +	rsion rmj.rmm.rup.rpr">\n<TITLE></TITLE>\n</HEAD>\n<BODY>\n<!-- Converted 
    +	from text/rtf format -->\n\n<P DIR=LTR><SPAN LANG="de"></SPAN><SPAN LANG="
    +	de"></SPAN><SPAN LANG="de"></SPAN></P>\n\n</BODY>\n</HTML>
     X-MICROSOFT-CDO-BUSYSTATUS:BUSY
     X-MICROSOFT-CDO-IMPORTANCE:1
    +X-MS-OLK-AUTOFILLLOCATION:FALSE
     END:VEVENT
     END:VCALENDAR
    

  • developer

    @meiser said in recurring appointments: exceptions not shown properly:

    In that doc, there’s an example for an exception. The only difference to the Outlook VEVENT is (from what I can see), the the SUMMARY is put into the VEVENT with the RECURRENCE-ID instead of the VEVENT with the RRULE.

    That’s exactly what I’m talking about. This version (SUMMARY in the VEVENT with RECURRENCE-ID) will work as expected in the current version of ICSdroid. If you have a look at your example, you will see that the exception (the VEVENT with RECURRENCE-ID) does not only repeat SUMMARY, but also DESCRIPTION, CLASS and other properties.

    So, as far as I understand your example, it supports my current opinion that the exception must repeat the values. Otherwise, those values are empty for the exception.

    However, RFC 5545 also speaks about “rescheduling” in context of Recurrence-ID. This could indicate that values should be copied by the client, if not specified otherwise.

    I also wonder why Outlook repeats other values in your example:

    BEGIN:VEVENT
    RECURRENCE-ID:20171005T110000Z      # moved to top for readability
    CLASS:PUBLIC
    CREATED:20171005T062226Z
    DTEND:20171006T113000Z
    DTSTAMP:20171005T062500Z
    DTSTART:20171006T110000Z
    LAST-MODIFIED:20171005T062231Z
    PRIORITY:5
    SEQUENCE:0
    TRANSP:OPAQUE
    UID:040000008200E00074C5B7101A82E00800000000100784D2B13DD301000000000000000
            01000000089D712D5C9CC8F44850E47904055B8A1
    X-MICROSOFT-CDO-BUSYSTATUS:BUSY
    X-MICROSOFT-CDO-IMPORTANCE:1
    BEGIN:VALARM
    TRIGGER:-PT15M
    ACTION:DISPLAY
    DESCRIPTION:Reminder
    END:VALARM
    END:VEVENT
    

    Why are all the other values, including the alarm, priority etc. repeated, but not the SUMMARY?

    So I think, it’s standards compliant to copy all properties like SUMMARY, LOCATION, etc. to the event exception.

    This would be the next step. Which properties should be copied by ICSdroid? Really all properties, even RRULE (rhetorical question)? But a more pratical example: shall the alarms/reminder (VALARM sub-components) be copied? If yes, how would it be possible to remove the alarm for a certain instance (which I guess is a thing that could really be required)?

    Maybe it would be a temporary solution to just copy the SUMMARY, if it’s not present in the exception? So users could at least know which event they’re looking at in the calendar ("—" is not really useful).



  • From a practical point of view, it would be sufficient/helpful to copy SUMMARY, LOCATION and DESCRIPTION.

    BTW, your sent test app works fine!


  • developer

    @meiser Ok, so we will copy the SUMMARY for a better user experience, but not other fields.

    If you find out that other fields (and which ones) have to be copied, too, please let us know more details here.



  • No, sorry. As I wrote, I’d like to have SUMMARY, LOCATION and DESCRIPTION copied over to the exception.



  • Any news?



  • Hi! It doesn’t make much sense to also copy LOCATION and DESCRIPTION, I think. Copying the SUMMARY has a practical outcome for the user because of the display in the calendar not being “—” anymore. Isn’t it enough to solve the problem just by copying the SUMMARY field?