Regression: Re-adding Deleted Calendar Events Impossible (Caused by Calendar Trashbin) (with Proposed Solution Suggestion)

[gohrner]

Steps to reproduce

1. Delete a calendar entry using CalDAV.
2. Try to re-add the same calendar entry using CalDAV.

Expected behaviour

The event is added again.

Actual behaviour

The server returns an error:

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Sabre\\DAV\\Exception\\BadRequest</s:exception>
<s:message>Deleted calendar object with uid already exists in this calendar collection.</s:message>
</d:error>

This problem is caused by #1662.

The behaviour introduced with this "feature" also causes bugs in Nextcloud itself, e.g.:

• Moving events back and forth between calendars causes trash bin conflicts calendar#3325
• Moving task between lists back and forth causes error tasks#1685

Proposal:

If a client tries to re-add a calendar entry which is contained in the trashbin, restore the event from the trashbin first, and treat the request as an event update request.

(Alternatively: Discard the event from the trashbin automatically, and perform the add request as requested by the client.)

This should solve the issues described above, it will fix my own calendar sync tool, and it would be the behaviour I'd actually intuitively expect from a trashbin mechanism...

Server configuration

Server configuration detail

Operating system: Linux 4.19.0-18-amd64 #1 SMP Debian 4.19.208-1 (2021-09-29) x86_64

Webserver: Apache/2.4.38 (Debian) (fpm-fcgi)

Database: mysql 10.3.31

PHP version: 7.3.31-1~deb10u1

Modules loaded: Core, date, libxml, openssl, pcre, zlib, filter, hash, Reflection, SPL, sodium, session, standard, cgi-fcgi, mysqlnd, PDO, xml, apcu, bcmath, bz2, calendar, ctype, curl, dom, mbstring, fileinfo, ftp, gd, gettext, gmp, iconv, igbinary, imagick, imap, intl, json, ldap, exif, mysqli, pdo_mysql, apc, posix, readline, recode, redis, shmop, SimpleXML, sockets, sysvmsg, sysvsem, sysvshm, tokenizer, wddx, xmlreader, xmlwriter, xsl, zip, Phar, Zend OPcache

Nextcloud version: 22.2.3 - 22.2.3.0

Updated from an older Nextcloud/ownCloud or fresh install:

Where did you install Nextcloud from: unknown

Signing status

Array
(
)

List of activated apps

Enabled:
 - accessibility: 1.8.0
 - activity: 2.15.0
 - appointments: 1.11.4
 - apporder: 0.13.0
 - calendar: 3.0.1
 - cloud_federation_api: 1.5.0
 - comments: 1.12.0
 - contacts: 4.0.6
 - contactsinteraction: 1.3.0
 - dashboard: 7.2.0
 - dav: 1.19.0
 - deck: 1.5.5
 - external: 3.9.0
 - federatedfilesharing: 1.12.0
 - federation: 1.12.0
 - files: 1.17.0
 - files_external: 1.13.0
 - files_markdown: 2.3.5
 - files_pdfviewer: 2.3.1
 - files_rightclick: 1.1.0
 - files_sharing: 1.14.0
 - files_trashbin: 1.12.0
 - files_versions: 1.15.0
 - files_videoplayer: 1.11.0
 - firstrunwizard: 2.11.0
 - forms: 2.4.0
 - impersonate: 1.9.0
 - logreader: 2.7.0
 - lookup_server_connector: 1.10.0
 - mail: 1.11.0
 - nextcloud_announcements: 1.11.0
 - notes: 4.2.0
 - notifications: 2.10.1
 - oauth2: 1.10.0
 - password_policy: 1.12.0
 - photos: 1.4.0
 - polls: 3.3.0
 - privacy: 1.6.0
 - provisioning_api: 1.12.0
 - recommendations: 1.1.0
 - richdocuments: 4.2.3
 - serverinfo: 1.12.0
 - settings: 1.4.0
 - sharebymail: 1.12.0
 - socialsharing_email: 2.4.0
 - spreed: 12.1.2
 - support: 1.5.0
 - survey_client: 1.10.0
 - systemtags: 1.12.0
 - tasks: 0.14.2
 - text: 3.3.0
 - theming: 1.13.0
 - twofactor_backupcodes: 1.11.0
 - updatenotification: 1.12.0
 - user_ldap: 1.12.1
 - user_status: 1.2.0
 - viewer: 1.6.0
 - weather_status: 1.2.0
 - workflowengine: 2.4.0
Disabled:
 - admin_audit
 - circles
 - encryption

Configuration (config/config.php)

{
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": [
        "nextcloud.ohrner-it.com"
    ],
    "datadirectory": "***REMOVED SENSITIVE VALUE***",
    "overwrite.cli.url": "https:\/\/nextcloud.ohrner-it.com",
    "htaccess.RewriteBase": "\/",
    "dbtype": "mysql",
    "version": "22.2.3.0",
    "dbname": "***REMOVED SENSITIVE VALUE***",
    "dbhost": "***REMOVED SENSITIVE VALUE***",
    "dbport": "",
    "dbtableprefix": "oc_",
    "mysql.utf8mb4": true,
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "installed": true,
    "instanceid": "***REMOVED SENSITIVE VALUE***",
    "ldapIgnoreNamingRules": false,
    "ldapProviderFactory": "\\OCA\\User_LDAP\\LDAPProviderFactory",
    "mail_from_address": "***REMOVED SENSITIVE VALUE***",
    "mail_smtpmode": "sendmail",
    "mail_smtpauthtype": "LOGIN",
    "mail_domain": "***REMOVED SENSITIVE VALUE***",
    "maintenance": false,
    "theme": "",
    "loglevel": 0,
    "auth.bruteforce.protection.enabled": true,
    "memcache.local": "\\OC\\Memcache\\APCu",
    "memcache.locking": "\\OC\\Memcache\\Redis",
    "redis": {
        "host": "***REMOVED SENSITIVE VALUE***",
        "port": 6379
    },
    "updater.release.channel": "stable",
    "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
    "enable_previews": true,
    "encryption.legacy_format_support": false,
    "encryption.key_storage_migrated": false
}

External storages: yes

External storage configuration

No mounts configured

Encryption: no

User-backends:

• OC\User\Database
• OCA\User_LDAP\User_Proxy

Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0

[Joshndroid]

I have been seeing this error constantly with every old event.
Using davx5 to sync calendar with nextcloud.

[jroldroyd]

I have also run into this problem.

The "Deleted calendar object with uid already exists in this calendar collection" error (from ./apps-pkg/dav/lib/CalDAV/CalDavBackend.php) is a violation of CalDAV RFC4791. CalDAV has no provisions for performing a restore operation or forcing a permanent deletion. So a user who sends a CalDAV DELETE followed by a CalDAV PUT on the same UID (e.g., by an event move in a client that has event Cut/Paste support) is now completely stuck.

The proposed behavior, restore from the trashbin and treat as an update request, is the correct behavior from a CalDAV perspective.

[cpm1]

This is a serious issue, a clear violation of the RFC and I really wonder, why this didn't get fixed yet. We are facing this issue almost every day and it is a real PITA. So pretty please can you give it a higher prio and get it fixed soon? Thanks.