Calendar invitations end up in the trash bin, if the personal calendar had been deleted
Steps to reproduce
- Create a calendar personal if you don't have one already (the URI might actually have to be
personal) - Delete the calendar again, but leave it in the trash bin (no permanent delete)
- Create a new personal calendar (the URI will be
personal-1) - Invite yourself to an event from another user's calendar
Expected behavior
The event I'm invited to shows up in my new personal calendar.
Actual behaviour
The event doesn't show up, because the backend picks personal despite the deletion. Once I restore the first personal calendar, I'll see the event.
Calendar app version
3.2
CalDAV-clients used
No response
Browser
No response
Client operating system
No response
Server operating system
No response
Web server
No response
Database engine version
No response
PHP engine version
No response
Nextcloud version
No response
Updated from an older installed version or fresh install
No response
List of activated apps
No response
Nextcloud configuration
No response
Web server error log
No response
Log file
No response
Browser log
No response
Additional info
The bug happens in \OCA\DAV\CalDAV\Schedule\Plugin::propFindDefaultCalendarUrl.
https://github.com/nextcloud/calendar/issues/1835 could help with this.
I think we've got the same here. On our NC 24 instance, we have migrated some calendars from another CalDAV system. Doing this was not 100% ok at first attemps, so we have to delete / re-create some calendars. While re-creating the new calendars, we did not name them "personal".
Now, we see the following :
- A invites B
- B receives an invite email and confirms it
- a popup appears saying that B's participation has been taken in account
- the event only appears within A's calendar
- B is one of these users we had to delete / re-create the default calendar
- the opposite (B invites A) works fine
Reading this, lead us to check the content of oc_calendars and oc_calendarobjects tables, searching for this event's data, and we've found :
- 3 rows in the
oc_calendarobjects, with 3 differentcalendarid(there is obviously one that should not be there !) - 2 of these calendarids belong to user B
- 1 of these 2 calendars is actually deleted (
deleted_atis not null) and its uri ispersonal) - the other calendar uri is the name we've given at creation time (but not
personal)
So the "lost" event is actually in B's deleted calendar, which is still the default calendar.
https://github.com/nextcloud/server/pull/32361 in NC25 should avoid this.
Great ! Thanks.
In the meanwhile is it safe to fix the broken situation by doing this ? :
- change the
uricolumn of the deleted calendars frompersonaltodeleted-personal - change the
uricolumn of the what-should-be-the-default-calendar, from (whatever) topersonal
So that the accepted invites go to a non-deleted calendar !
The setting to define the default calendar already exists (for a while) even through there's no user interface for it. For future invitations to go into the right calendar, you can just just set:
php occ user:setting <uid> dav defaultCalendar <new_calendar_uri>
Setting a default calendar to some users, using this setting have improved the situation, but unfortunately we still have some issues with the invitations. The scenario is now different :
- A invites B
- B receives an email and accept the invitation
- a popup appears saying that B's participation has been taken in account
- but the event only appears within A's calendar
- when B invites A, all works fine
Both A and B now have a default calendar, verified using :
docker exec --user www-data our_nextcloud_1 php occ user:setting usera dav defaultCalendar
Browsing the oc_calendars and oc_calendarobjects tables, the situation is :
- only one row exists for this test event, belonging to user A
Here are two ics version of the event :
First exported from user A calendar (exported after B has received and accepted the invite)
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//IDN nextcloud.com//Calendar app 3.5.0//EN
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Europe/Zurich
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
CREATED:20220907T151153Z
DTSTAMP:20220907T151213Z
LAST-MODIFIED:20220907T151213Z
SEQUENCE:2
UID:3ae845da-6817-4765-800b-40be1a06335c
DTSTART;TZID=Europe/Zurich:20220910T113000
DTEND;TZID=Europe/Zurich:20220910T120000
STATUS:CONFIRMED
SUMMARY:PC GG F2
ATTENDEE;CN=User B;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=REQ-PART
ICIPANT;LANGUAGE=fr;SCHEDULE-STATUS=2.0:mailto:[email protected]
ORGANIZER;CN=User A:mailto:[email protected]
END:VEVENT
END:VCALENDAR
Then the one received by user B, attached to the invite email.
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sabre//Sabre VObject 4.4.3//EN
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Europe/Zurich
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
CREATED:20220907T151153Z
LAST-MODIFIED:20220907T151213Z
SEQUENCE:2
UID:3ae845da-6817-4765-800b-40be1a06335c
DTSTART;TZID=Europe/Zurich:20220910T113000
DTEND;TZID=Europe/Zurich:20220910T120000
STATUS:CONFIRMED
SUMMARY:PC GG F2
ATTENDEE;CN=User B;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-
PARTICIPANT;RSVP=TRUE;LANGUAGE=fr:mailto:[email protected]
ORGANIZER;CN=User A:mailto:[email protected]
DTSTAMP:20220907T151213Z
END:VEVENT
END:VCALENDAR
The first ics shows that user B has accepted, but despite of that the event doesn't now appear in his agenda.
Maybe one noticeable thing is that if A chooses to create a Talk room in the event, B is not present in the Talk room, A has to invite B to have him in the talk.
I have made sure that neither A or B have fixed Timezone defined in their calendars, since I've read #3882
I am not sure where to dig more in order to provide more details ! This Nextcloud install is "old", now in 24.0.4, but has been upgraded multiple time since around V18. The calendars are only used since a few weeks, users were using only file storage before.
Does NC 24.0.5 addresses these issues ?
No. As long as the ticket is open you can assume that it hasn't been addressed yet :)
Thanks ! Any direction you could point me, so I could try to provide more information on this issue ?
Hello ! After upgrading our instance to 25.0.3, I can see that this issue is still present.
My mistake, I just noticed https://github.com/nextcloud/server/pull/32361 didn't take into account this case properly. The personal calendar will indeed still be used if it exists even if deleted.
Now what should be the behavior:
- always remove completely the current (default to
personal, but could be otherwise) calendar where the invitations should go and recreate it to put the invitations in it - or try to put in the first other available calendar, defaulting to the first proposition if there's no other calendar available
I also vote for 2
Don't you think that option 2 may lead to confusion for the user ?