Every appointment is a group appointment



  • Hello,

    i have problems when i sync my appointments with my self-written caldav-server.
    I am using DavDroid 0.9 and Android 5.1.1.
    When i open the appointment on my device i get on the bottom of the app the selection, if i want to accept the appointment.

    BEGIN:VEVENT
    CREATED:20150818T094346
    DTEND;TZID=Europe/Berlin:20150827T120000
    DTSTAMP:20150818T094444
    DTSTART;TZID=Europe/Berlin:20150827T110000
    LAST-MODIFIED:20150818T114446
    ORGANIZER;CN= XXX:mailto:XXX
    PRIORITY:1
    SEQUENCE:0
    STATUS:Confirmed
    SUMMARY:Abc3
    UID:22381D93-7E1A-4746-A9EF-9C4D65E98D1E
    END:VEVENT
    

    What property of my VEVENT is wrong? What need's DavDroid to set the appointment to a normal event?

    Best regards,
    Marc


  • developer

    @Marc246 said:

    What property of my VEVENT is wrong? What need's DavDroid to set the appointment to a normal event?

    As far as I know, DAVdroid can't set "group events" or "normal events". All it can do is to set the ORGANIZER, add ATTENDEEs and set the HAS_ATTENDEE_DATA for the event.

    You can find the logic for setting HAS_ATTENDEE_DATA in AndroidEvent.java in buildEvent(). As you can see, HAS_ATTENDEE_DATA is only set to 1 when there are ATTENDEE properties (in your iCalendar, there are none).

    So I suggest to dig further into the sources of the AOSP Calendar app (as I have done before) to find out when the "attend? yes/no" block is displayed.



  • Ok i didn't know, that DavDroid can't set this property.
    But when i create a new appointment on my device i get following VEVENT:

    BEGIN:VEVENT
    DTEND;TZID=Europe/Berlin:20151020T150000
    DTSTAMP:20151019T120656Z
    DTSTART;TZID=Europe/Berlin:20151020T140000
    ORGANIZER:mailto:XXX
    SEQUENCE:1
    STATUS:Confirmed
    SUMMARY:Test Termin 12
    UID:16cffaff-bfa3-4e90-a313-0cdd3edc9ccc
    END:VEVENT
    

    This appointment has no selection, if i want to accept the appointment. But there is no difference to my VEVENT, which i sent from the server to the device.

    Best regards,
    Marc


  • developer

    This appointment has no selection, if i want to accept the appointment. But there is no difference to my VEVENT, which i sent from the server to the device.

    The difference is not visible in the VEVENT, but is in the locally stored Event entry. We'll have to find out what exactly causes the questionable UI block to be shown.



  • @rfc2822 Is there a solution to this problem? I tested it with our owncloud test server and there is the same "bug".

    i hope you can help to handle this problem.

    Best regards,
    Marc


  • developer

    @Marc246 This is not a server issue, but a misunderstanding between what DAVdroid writes into the Contacts storage and the Calendar app.

    Did you manage to have a look into the AOSP Calendar app yet, to find out when the "attend? yes/no" block is displayed? As far as I know, there's no documentation for it.

    Also, this seems quite a minor issue to me. Does this make any problems, despite from optical ones?



  • @rfc2822 We tested it with SPlaner and Google Calendar and in both calendar apps is the same problem. No, for this purpose, unfortunately I haven't had time in the last few days. No there are no problems but i wanted to know, if there is a possibility to remove the optical mistake.


  • developer

    I have found the root of the problem now. All information is related to AOSP Calendar (version 5.1.1_r29).

    • The "attend: yes/no/maybe" widget is named mResponseRadioGroup in the code (because it's radio group and it's the user's "response" for the event).
    • Whether mResponseRadioGroup is visible or not is determined by a variable named canRespond, whose value is calculated by EditEventHelper.canRespond.
    • EditEventHelper.canRespond's logic is like that:
      1. If the calendar can't be edited, return false.
      2. Otherwise: If the user is not the organizer, return true. I.e. the response radio group will always appear if the user is not the organizer (makes sense, because if the user is not the organizer, (s)he must be another participant and is thus eligible to respond).
      3. Otherwise, i.e. if the calendar can be edited by the user and (s)he's the organizer: return false if mOrganizerCanRespond is false.
      4. Otherwise, i.e. if the calendar can be edited by the user and (s)he's the organizer and mOrganizerCanRespond == true, the following two expressions remain:
    // This means we don't have the attendees data so we can't send
    // the list of attendees and the status back to the server
    if (model.mHasAttendeeData && model.mAttendeesList.size() == 0) {
        return false;
    }
    
    return true;
    

    DAVdroid doesn't set mHasAttendeeData to true when there are not attendees. So, EditEventHelper.canRespond returns true.

    I think there are two possibilities:

    1. EditEventHelper.canRespond should return false if mHasAttendeeData is false because when there's no information about attendes, there's no reason to let the user select his/her participation status.
    2. This could be worked around by always setting mHasAttendeeData to true (I have tested this, and it works).

    It depends on what HAS_ATTENDEE_DATA really means. According to the SDK docs:

    (HAS_ATTENDEE_DATA) Whether the event has attendee information. True if the event has full attendee data, false if the event has information about self only. Column name.

    So I guess, it should be set to true if all attendee data about this event is known ("full attendee data") and to false if only information about ourselves is known. I don't wheter it's possible with CalDAV Scheduling to get only information about ourselves, but in plain CalDAV, we get the whole event information, thus all attendee information, so we should set that field to true.

    Do you agree? What are your thoughts?



  • Thanks for this statement.
    I would agree. Sounds interesting what you have found. I think it should be set to true too. Your arguments are understandable and i would say we should test it with this solution. Is this workaround implemented in the DavDroid Version 0.9.1?

    Best regards,
    Marc


  • developer

    @Marc246 said:

    Is this workaround implemented in the DavDroid Version 0.9.1?

    If the second interpretation is true (and I believe so), it's not even a workaround. And it's implemented in DAVdroid 0.9.1, but it will of course only be applied to events received after updating to 0.9.1 (i.e. not for events that are already in the calendar provider).

    Can you please verify this?



  • @rfc2822
    Bad news.
    It doesn't work with DavDroid 0.9.1.

    This is the content of my .ics file

    BEGIN:VCALENDAR
    VERSION:2.0
    PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
    BEGIN:VTIMEZONE
    TZID:Europe/Berlin
    TZURL:http://tzurl.org/zoneinfo/Europe/Berlin
    END:VTIMEZONE
    BEGIN:VEVENT
    CLASS:PUBLIC
    CREATED:20151112T073836
    DESCRIPTION:
    DTEND;TZID="Europe/Berlin;":20151112T081500
    DTSTAMP:20151112T073836
    DTSTART;TZID="Europe/Berlin;":20151112T074500
    LAST-MODIFIED:20151112T073836
    LOCATION:
    ORGANIZER;CN=XXX:mailto:XXX
    PRIORITY:1
    SEQUENCE:1
    STATUS:Tentative
    SUMMARY:test123
    UID:770F1ED52A27483EB6E01F610CF9F1B8
    END:VEVENT
    END:VCALENDAR
    

    Is it possible that the problem is the organizer?
    This event is created in another client and the DavDroid account on our test client was recreated.

    Any other tips?

    Thank you in advance.

    Best regards,
    Marc


  • developer

    @Marc246 It works here (just tested again to be sure). Is the organizer email address your account name?

    Also, I have tested with Etar. Maybe other calendar apps (S Planner) don't behave like that.

    Is your device rooted? Then you could have a look whether HAS_ATTENDEE_DATA is set to 1 directly in the database.



  • @rfc2822 The organizer email address and my account name are different.

    My device is rooted. Can you send me via chat short instructions to look for the HAS_ATTENDEE_DATA ?


  • developer

    @Marc246 said:

    @rfc2822 The organizer email address and my account name are different.

    In this case, the response radio group is always shown, see case 2 in my list above: »I.e. the response radio group will always appear if the user is not the organizer (makes sense, because if the user is not the organizer, (s)he must be another participant and is thus eligible to respond).«

    My device is rooted. Can you send me via chat short instructions to look for the HAS_ATTENDEE_DATA ?

    I guess this is not required anymore, but it's always fun. Just use your file manager (with root) to copy /data/data/com.android.providers.calendar/databases/calendar.db to the external storage (or fetch it with root adb), then send it to your PC and open it with an SQLite GUI.



  • @rfc2822 said:

    @Marc246 said:

    @rfc2822 The organizer email address and my account name are different.

    In this case, the response radio group is always shown, see case 2 in my list above: »I.e. the response radio group will always appear if the user is not the organizer (makes sense, because if the user is not the organizer, (s)he must be another participant and is thus eligible to respond).«

    Now i tested it with the same value for the organizer and for the account - but i get still the display of accepting or declining the event.

    My device is rooted. Can you send me via chat short instructions to look for the HAS_ATTENDEE_DATA ?

    I guess this is not required anymore, but it's always fun. Just use your file manager (with root) to copy /data/data/com.android.providers.calendar/databases/calendar.db to the external storage (or fetch it with root adb), then send it to your PC and open it with an SQLite GUI.

    I think i have to test this proposal. Maybe i will test also that i remove the organizer for a normal event.


  • developer

    Now i tested it with the same value for the organizer and for the account - but i get still the display of accepting or declining the event.

    That's strange, because it works here as expected. What's your account name, and what's your organizer? Did you create a new event with ORGANIZER:mailto:accountname?



  • Ok sorry that was my fault.
    There was a trailing whitespace in the organizername.
    Now it works! Thank you @rfc2822

    Edit: I can't set the thread to solved.


  • admin

    Thanks for the update and telling us the cause of the problem :+1:


Log in to reply
 

Looks like your connection to Bitfire App Forums was lost, please wait while we try to reconnect.