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

[jancborchardt]

Regarding where to store it – definitely directly in the Calendar respectively the Contacts app. cc @Henni @irgendwie

[georgehrke]

Do you mean store or restore?

Please excuse my brevity and typos.
Sent from my mobile

On Oct 11, 2016, at 9:36 AM, Jan-Christoph Borchardt [email protected] wrote:

Regarding where to store it – definitely directly in the Calendar respectively the Contacts app. cc @Henni @irgendwie

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or mute the thread.

[ChristophWurst]

The caldav part is done. Starting with Nextcloud 22 deletions of events and whole calendars result in a move into a trash bin instead of an instant and irreversible data deletion. This works with any connected client. Nextcloud Calendar then comes with a UI to restore from this trash bin. Until there is a standard for trash bins on caldav this trash bin won't be usable for connected clients.

[cornzy]

Thank you for the trash bin :) Is there an option to change the default 30 days of keeping the trash?

[tcitworld]

Yes, php occ config:app:set dav calendarRetentionObligation --value=%value% where %value% must be replaced by a number of seconds. 0 equals to disabled.

Will add it to the docs nextcloud/documentation#7696

[cornzy]

I just tried this configuration and set the value to 365. Reply:

Config value calendarRetentionObligation for app dav set to 365

Ok. But now when I go to the trash bin in the web frontend, under all entries it says:

Elements in the trash bin are deleted after 1 day

Is this just a bug in the UI? I can wait until tomorrow to tell you if all entries are deleted or not :)

[raimund-schluessler]

I just tried this configuration and set the value to 365. Reply:

Config value calendarRetentionObligation for app dav set to 365

The value needs to be set in seconds. I assume you want to set it to 365 days, so you need to put 365*24*60*60 which equals 31536000 seconds.

[gohrner]

Is there any way to completely disable this feature? Unfortunately, it breaks things.

Besides even side-effects within Nextcloud itself (as reported in Tasks Issue 1685 or Calendar Issue 3325), it also breaks a custom calendar sync tool we use.

It generates events with computed UIDs to properly sync them to an external source, and might remove an event temporarily, but later has to re-add it.

(I strongly suggest that adding an event which is in the trash bin should not cause a conflict, but recover the event from the trash bin - but I'll add a separate request for that.)

I tried setting the calendarRetentionObligation to 1 second, but it doesn't seem to help, not even with running the background cron job manually before re-running our sync tool. Only manually expunging the calendar trash bin helps.

Any solutions? Do I really have to adjust my sync tool? But how to deal with other CalDAV clients which perform similar operations, like moving a calendar entry from one calendar to another and back using an CalDAV client - it will also try to recreate a "deleted" calendar entry with the same UID, I'd assume...

Sidenode: The calendar sync tool uses a role user account which has write access to calendars belonging to other users, where it syns the stuff to. The deleted calendars end up in the trash bin's of the users to whom the calendar belongs, not in the trash bin of the role account who actually deleted the event... Is this intended?

[gohrner]

(I strongly suggest that adding an event which is in the trash bin should not cause a conflict, but recover the event from the trash bin - but I'll add a separate request for that.)

=> #30096

[tcitworld]

Is there any way to completely disable this feature? Unfortunately, it breaks things.

I tried setting the calendarRetentionObligation to 1 second, but it doesn't seem to help, not even with running the background cron job manually before re-running our sync tool. Only manually expunging the calendar trash bin helps.

Set it to 0 instead.

[gohrner]

Set it to 0 instead.

Ahh - I understood your comment above incorrectly. I somehow read it as "0 disables trashbin expiration completely" while what you meant was "0 disables trashbin completely".

Ok, thanks, I'll try that!

[zeaglee]

Yes, php occ config:app:set dav calendarRetentionObligation --value=%value% where %value% must be replaced by a number of seconds. 0 equals to disabled.

Thank you for this. This update broke my synchronization with iCal Import/Export. I use it to copy an external calendar to a nextcloud calendar then sync the changes on a regular basis. Immediately after the update I started getting errors that an event's uuid existed in the trash.

[pgy866]

Great PR, is it being discarded now?

[PhilippSchlesinger]

Is the carddav trashbin feature tracked in a separate issue that is not yet linked here by accident?

[gbakeman]

I was just recently made another victim of an errant DAV client trying to helpfully "sync" old data which, between it and Nextcloud, seemed to mean deleting newer contact data. Unfortunately it looks like I'm going to be spending the afternoon learning how to recover from a mysql database. Would be very helpful if DAV changes are at least logged, and deletions are captured in this recycle bin feature we've been discussing here.