Partecipant status is NEEDS-ACTION but partecipation was confirmed
-
Android device: Xiaomi Redmi Note 4 - Android 7.0
DAVx5: version 2.2.3.1-ose-267
Other CalDAV client: Thunderbird 60.5.0 on Win10 x64
CalDAV server: SOGO 4.0.4.20190212Bug description:
- received an invite to an event (not accepted yet)
- in Google calendar the event is drawn as an “unfilled” rectangle with calendar-color border
- accepted the event
- in Google calendar the event is now drawn as a rectangle filled with calendar-color
- after a resync the event rectangle got back to unfilled, like it was never accepted
- in Thunderbird/Lightning I was marked as accepted
- in SOGo Calendar web page I was also marked as accepted
- confirming again my partecipation in Google Calendar started the same loop again: rectangle filled, resync, rectangle unfilled
So it seems that the only client markink me as unconfirmed was Android/DAVx5.
After some investigation I noticed that event organizer added my email with “unusual case”, say
Myself@example.org
instead ofmyself@example.org(note the initial Uppercase).I manually changed that ics record in SOGo database, then forced a DAVx5 resync and… the bug disappeared and I was marked as
ACCEPTED!
As a counter-proof, I set the ics record content back to “uppercased” version, reforced sync and the event got back toNEEDS-ACTION.
In both cases Thunderbird/Lightning and SOGo web application correctly shown me as ACCEPTED.Below is the untouched ICS content that causes the bug (changed emails for privacy reasons, I’m the first attendee…):
BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:Europe/Rome BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT LAST-MODIFIED:20190213T175219Z DTSTAMP:20190213T175219Z UID:f6ce8b28-bd8d-4557-b8cb-a74a47bacc4a SUMMARY:Summary ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE=0;RECEIVE D-DTSTAMP=20190213T152257Z;CUTYPE=INDIVIDUAL:mailto:Myself@example.org ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE =0;RECEIVED-DTSTAMP=20190213T160158Z;CUTYPE=INDIVIDUAL:mailto:user1@exampl e.org ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE =0;RECEIVED-DTSTAMP=20190213T162824Z;CUTYPE=INDIVIDUAL:mailto:user2@exampl e.org ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE =0;RECEIVED-DTSTAMP=20190213T163556Z;CUTYPE=INDIVIDUAL:mailto:user3@exampl e.org DTSTART;TZID=Europe/Rome:20190218T140000 DTEND;TZID=Europe/Rome:20190218T173000 CLASS:PUBLIC X-MOZ-GENERATION:5 BEGIN:VALARM ACTION:DISPLAY TRIGGER;VALUE=DURATION:-PT240M DESCRIPTION:Description END:VALARM ORGANIZER;CN=Organizer User:mailto:organizer@example.org END:VEVENT END:VCALENDAR```
-
Hello,
Thanks for your report. DAVx⁵ just inserts the attendees into the Android calendar provider, which is responsible for determining the “self status” (= status of the account owner when the same email address is an attendee).
Seems like Android compares the email address with case sensitivity.
Do you know how the rules are for comparing attendee/organizer emails? Do mailto: URIs have to be normalized in some way? According to https://tools.ietf.org/html/rfc5321#section-2.4:
The local-part of a mailbox MUST BE treated as case sensitive. [… ] In particular, for some hosts, the user
“smith” is different from the user “Smith”.This would mean that
Myself@example.orgcan be another email address thanmyself@example.org, and then it would get complicated…Maybe it would be a solution that the server always rewrites attendees to a canonical version? So that if
Myself@example.orgis invited, but the server account ismyself@example.org, the server rewrites theATTENDEEtomyself@example.org?But this is only the local part. The domain part of the email address could always be normalized. Because Android doesn’t do that, DAVx⁵ could rewrite it to lower case, as a workaround. But it would probably cause bug reports too (“bug: domain part of attendee mailtos always rewritten to lowercase”)…
-
I don’t have any knowledge about .ics format (thanks for linking the RFC), but in the ICS I’ve posted I see that
Myself@example.orgline has thePARTSTAT=ACCEPTEDproperty like the others; isn’t it enough for the partecipant to be marked as ACCEPTED?Well, I wonder if this issue should be better resolved at server or client side.
Since Thunderbird and SOGo web page both don’t care about casing, I’ve supposed Android should behave the same… but it’s not.Maybe an advanced option like “normalize email addresses” could be added in account configuration?
Maybe together with a warning like “use only if you have issues with users adding mixed-case email addresses”
PS: will post an issue notice to SOGo bug tracker too, linking to this. If server side we could have a feature that will normalize all of the email addresses, we’re done.
-
@nicorac said in Partecipant status is NEEDS-ACTION but partecipation was confirmed:
I don’t have any knowledge about .ics format (thanks for linking the RFC), but in the ICS I’ve posted I see that Myself@example.org line has the PARTSTAT=ACCEPTEDproperty like the others; isn’t it enough for the partecipant to be marked as ACCEPTED?
As far as I see, the problem is that
Myself@example.orgis not identified with yourself, isn’t it? When you look in the event after accepting the invitation, isMyself@example.orgset to “confirmed”?
-
As far as I see, the problem is that Myself@example.org is not identified with yourself, isn’t it?
Yes it is, no doubts.
I was only justifying myself about how I’ve missed the casing issue at first sightMaybe an advanced option like “normalize email addresses” could be added in account configuration?
Maybe together with a warning like “use only if you have issues with users adding mixed-case email addresses”Is this acceptable or do you think it’s a “too geeky” workaround?
