Calendar and Contacts Trashbin

[georgehrke]

We already provide a trash bin for files, that allows users to restore deleted files.
I'd like to see something similar for calendars and contacts.

This also helps users who accidentally deleted events/contacts or an entire calendar/addressbook in their client.

Todo

• Calendar and event trash bin
• Calendar subscription trash bin
• Address book and contact card trash bin

cc @jancborchardt @tcitworld @schiessle

[georgehrke]

There are a few questions that need a prior discussion:

• Which app shall implement the features logic?
  • dav
  • a new dav_trashbin
  • calendar respectively contacts

I'd not like to see it in the latter, because you can use CalDAV and CardDAV without the Calendar and Contacts app. Therefore the trash bin should always work, no matter whether the web gui is enabled.

• Which app shall implement the GUI?
  • dav respectively dav_trashbin in the personal settings area
  • calendar respectively contacts

I'd actually go with calendar and contacts here. We can't do this with plain CalDAV/CardDAV. Therefore it's acceptable to having enable calendar respectively contacts before restoring imo.

I'd suggest to provide the trash bin via remote.php/dav/calendars_trashbin/ respectively remote.php/dav/addressbooks_trashbin/.

@schiessle I wasn't able to find the trash bin via remote.php/dav/. Does files_trashbin already use WebDAV for talking to the server?

[georgehrke]

However it would be of no use if the calendar/contacts app aren't here since you wouldn't be able to restore deleted calendars/contacts.

Yes, but there are the following scenarios:

Dav app takes care:
You delete a calendar by accident -> the calendar is moved to a trash bin by the dav app -> you enable the calendar app -> you restore the calendar

Calendar app takes care:
You delete a calendar by accident -> ¯_(ツ)_/¯

[tcitworld]

Totally agree with all of these. If I understand correctly, putting an item in the bin would mean moving the data from the oc_calendars table to oc_calendar_bin, while not touching oc_calendar_objects. Do the data from oc_dav_shares must remain too ?

[nickvergessen]

Couldn't we just create a flag, and some sort of hidden calendars/events which are not exposed, unless you propfind with a the special property? I think that would be very few lines to implement.

When you delete a calendar/event and it does not have the flag yet, we set the flag. If the flag already exists it's deleted from the system.

[georgehrke]

That would indeed be a good solution.
Instead of the flag I'd probably go for a timestamp, which is null by default.
This allows us to easily delete deleted calendars/events older than n days.

[georgehrke]

But there is actually one issues I'd like to discuss before implementing this:

When a calendar/addressbook (but also event/contact) is deleted, the uid should be available again.
What to do about this? Replace the uid (or uri for event/contact) with a random string?

Keep this random string when replacing or tell the client to send a new uid along the request?

The dav_shares table uses the calendar id and not the calendar uri, we don't need to change anything there.
The behavior should be the same as in the files app. Restoring a calendar/addressbook also restores all the shares.

[georgehrke]

Reminder for myself:
Do not return deleted calendars on allprop request

[nickvergessen]

When a calendar/addressbook (but also event/contact) is deleted, the uid should be available again.
What to do about this? Replace the uid (or uri for event/contact) with a random string?

As long as there are no duplicates on restoring, fine by me.

[georgehrke]

Yes, the db won't allow duplicate URIs.
https://github.com/nextcloud/server/blob/master/apps/dav/appinfo/database.xml#L375