Add a trashbin for calendars and calendar objects

[ChristophWurst]

This adds the calendar part of #1662.

Todo

• Db structure to mark calendar as deleted
• Db structure to mark calendar object as deleted
• URI conflict handling
• Exclude deleted calendars from allprop requests list them, but give them a distinct resourcetype
• Exclude deleted calendar objects from requests
• Soft delete calendars only, keep their objects and shares
• Soft delete objects only, keep their properties
• Add a dedicated calendars_trashbin root to list deleted trashbins
• Expose deleted-at as DAV property
• Add a retention background job
• Handle calendar restore, possibly like https://github.com/nextcloud/server/blob/master/apps/files_trashbin/lib/Sabre/RestoreFolder.php
• Handle object restore
• Etag propagation on delete/restore
• Handling of shared claendars

---

API

List deleted objects and their contents

REPORT /remote.php/dav/calendars/admin/trashbin/objects/

<x1:calendar-query xmlns:x1="urn:ietf:params:xml:ns:caldav">
  <x0:prop xmlns:x0="DAV:">
    <x0:getcontenttype/>
    <x0:getetag/>
    <x0:resourcetype/>
    <x0:displayname/>
    <x0:owner/>
    <x0:resourcetype/>
    <x0:sync-token/>
    <x0:current-user-privilege-set/>
    <x0:getcontenttype/>
    <x0:getetag/>
    <x0:resourcetype/>
    <x1:calendar-data/>
  </x0:prop>
  <x1:filter>
    <x1:comp-filter name="VCALENDAR">
      <x1:comp-filter name="VEVENT">
      </x1:comp-filter>
    </x1:comp-filter>
  </x1:filter>
</x1:calendar-query>

note: filter is mandatory as per caldav specs (sabre enforces) but they are ignored. you can send anything as filter criteria …

Restore a calendar

MOVE /remote.php/dav/calendars/admin/my-deleted-cal

Destination: /remote.php/dav/calendars/admin/trashbin/restore/my-deleted-cal

Restore a calendar object (event)

MOVE /remote.php/dav/calendars/admin/trashbin/objects/73.ics

Destination: /remote.php/dav/calendars/admin/trashbin/restore/73.ics

---

What I tested

Nextcloud calendar

• Deleted calendar is hidden from list
• Deleted calendar object is not rendered
• Restored calendar object is rendered again

Thunderbird

• Deleted calendar is hidden from list
• Deleted calendar object is not rendered
• Restored calendar object is rendered again

Evolution

• Deleted calendar is hidden from list
• Deleted calendar object is not rendered
• Restored calendar object is rendered again

DAVx5

• Delete calendar collection (tick delete date from server)
• Deleted calendar is hidden from list
• Restore calendar is shown again after calendars refresh
• Deleted calendar object is not rendered
• Restored calendar object is rendered again

[tcitworld]

No index for calendarobjects?

[tcitworld]

Do we even need to use RestoreFolder at all? Can't you just move the object to it's original collection directly?

/me knows nothing about why it's used in files_trashbin or files_versions.

[ChristophWurst]

Do we even need to use RestoreFolder at all? Can't you just move the object to it's original collection directly?

I tried that first but then we run into the issue that the URI is identical. Which brings us back to the question whether URIs should be changed when a calendar object is deleted …

[tcitworld]

• Check if calendar subscriptions are handled correctly

[ChristophWurst]

@tcitworld now that the trashbin was moved into the user's calendar home, couldn't that mean that there is a potential conflict between the new trashbin collection and a user's calendar with the same URI?

[tcitworld]

Indeed, we need to reserve that URI just like the birthday calendar.

[ChristophWurst]

Check if calendar subscriptions are handled correctly

I have to check the details but right now I think subscriptions are just not going into the trashbin. They are deleted like before.

[ChristophWurst]

If I'm not mistaken then my todo list is done, yet I'm not fully convinced of the design.

The solution with the changed resource type for deleted calendars and that clients still see but ignore the node is solid. But hiding the objects from listing but giving them away when you directly access them (with the -deleted suffix) is strange. I'll dive deeper to find out whether it's not somehow possible to have objects in the calendar that will be ignored by clients like the deleted calendars.

[ChristophWurst]

I'll dive deeper to find out whether it's not somehow possible to have objects in the calendar that will be ignored by clients like the deleted calendars.

The RFC says a calendar can only contain calendar object resources. In that sense it's hard to have anything in there that isn't an event. I'll therefore keep the logic where we move the object to a suffix'ed URI and add a flag so the object is excluded from ordinary calendar queries/listings.

[tcitworld]

• Test what happens for invites on deleted calendar objects
• Test what happens for reminders on deleted calendar objects

[ChristophWurst]

Test what happens for invites on deleted calendar objects

Haven't done that yet but I assume anything that we do immediately now could be done either still immediately or eventually when the object is dropped. So the question is more what is the expected behavior. As this is a feature that isn't specified by an official *dav RFC, I supposed we could only look into other non-dav solutions to compare how they handle it.

[ChristophWurst]

Test what happens for invites on deleted calendar objects

I tested this.

I meant what happens when invites are sent, then the event is deleted, and an invite is answered after that. Since we change the calendar object uid we should be fine, but we should check it anyway.

Well depends on what we define as fine 😉. The recipient can still confirm their attendance. But that attendance is on an event that doesn't exist anymore for the organizer.

I don't know what is the right thing to do here to be honest. Keeping it like it is seems a bit meh, but also not allowing the recipient to confirm when the organizer later restores is meh as the confirmation is lost :/

[ChristophWurst]

I don't know what is the right thing to do here to be honest. Keeping it like it is seems a bit meh, but also not allowing the recipient to confirm when the organizer later restores is meh as the confirmation is lost :/

So what if we do this: the links works, the event is updated, but the recipient also gets a little warning that the event they just confirmed/rejected is actually deleted.

This is also a bit strange but at least we do keep their attendance information and the recipient is aware that the event won't take place.

On a related note I think this topic isn't quite solved in general. I noticed that we send out cancellation emails when an event is deleted, but not when a whole calendar is deleted. This feels a bit inconsistent.

[tcitworld]

So what if we do this: the links works, the event is updated, but the recipient also gets a little warning that the event they just confirmed/rejected is actually deleted.

Yup. Check with ITip if there's a special status for this as well.

I noticed that we send out cancellation emails when an event is deleted, but not when a whole calendar is deleted. This feels a bit inconsistent.

That could trigger a lot of emails being sent if there's many future events with attendees in the calendar. Would be great if specs or CalConnect gave advice on this.

[tcitworld]

Is it worth it to have a repair step to rename existing calendars which URI is exactly trashbin?

[tcitworld]

It would be nice to be able to filter on the deleted-calendar property (or at least deleted-at) so that the trashbin UI can get only the deleted calendars instead of getting all of the user's calendars and do the filtering afterwards.

[ChristophWurst]

It would be nice to be able to filter on the deleted-calendar property (or at least deleted-at) so that the trashbin UI can get only the deleted calendars instead of getting all of the user's calendars and do the filtering afterwards.

Possibly. But we can also possibly do the filtering and splitting from the current listing.

[ChristophWurst]

Failing CI seems unrelated. Three of three failed due to a timeout.

[ChristophWurst]

This works well with nextcloud/calendar#3118. I'll merge this PR here when CI happy. Let's rebase just to be sure.