server
server copied to clipboard
nextcloud
Regression: Re-adding Deleted Calendar Events Impossible (Caused by Calendar Trashbin) (with Proposed Solution Suggestion)
Steps to reproduce
- Delete a calendar entry using CalDAV.
- 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 https://github.com/nextcloud/server/issues/1662.
The behaviour introduced with this "feature" also causes bugs in Nextcloud itself, e.g.:
- https://github.com/nextcloud/calendar/issues/3325
- https://github.com/nextcloud/tasks/issues/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
I have been seeing this error constantly with every old event. Using davx5 to sync calendar with nextcloud.
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.
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.
Why is this issue closed? I just had this exact same issue in the latest nextcloud version.
@hannob closed because https://github.com/nextcloud/server/pull/34375 addressed the bug by discarding previous deleted events on re-import. Do you still see Deleted calendar object with uid already exists in this calendar collection with 26.0.0?
I'm running version 25.0.5, the administration page tells me this is up to date.
Backport to 25 was missing: https://github.com/nextcloud/server/pull/34375#issuecomment-1495505206
Maybe there's a bug with the merged fix...
Now I get A calendar object with URI <uri>.ics already exists in calendar <n>, therefore this object can't be moved into the trashbin error messages when trying to delete tasks that have been moved across multiple task lists.
Deleting these tasks seems impossible through the webUI / caldav due to the error above.
Technical information:
- Nextcloud version: 26.0.0 (stable)
- PHP version: 8.2.4
- Host: Debian 11
Update: Created issue https://github.com/nextcloud/server/issues/37577
@tamas646 that sounds similar but isn't the problem this ticket described. Could you please file a new ticket for that bug? It eases tracking if we have two distinct tickets. Thanks for the quick feedback!
@ChristophWurst done (https://github.com/nextcloud/server/issues/37577) Thanks for the suggestion.
@r2evans: As this issue is closed, you're comment will probably not get much attention. If you can still reproduce this in 28, it would be better to open a new bugreport (with additional information about what exactly you were doing and what happened) and reference this one in the new one.
Yes, I'm planning on doing that once I have more information. I am surprised I got this much attention :-)
I added here as a place-holder, sorry if it's a problem.
... but the symptoms are identical: delete an event, reimport it, 400/failure. I'll work on a new issue.
@r2evans: No problem - I just feared your report might get lost this way. I only noticed by chance as I'm the original reporter of this issue and a such was in the watcher list.
Turns out not only has it been around in github.com/nextcloud/calendar for years, I have commented on one of them in the past.
https://github.com/nextcloud/calendar/issues/4412
https://github.com/nextcloud/calendar/issues/2065
https://github.com/nextcloud/calendar/issues/1508