If in multiple groups with different permissions (read, write) read has higher priority than write

[c-holtermann]

Steps to reproduce

1. Have a group A with read permission on a calendar
2. Have a group B with write permission on the same calendar

Expected behaviour

The users of the group should be allowed to write to the calendar as group B would

Actual behaviour

The user is only allowed to read the calendar as group A would. The calendar is shown as "Abonnement" (german) and not as own calendar.

Server configuration

Operating system: Debian jessie

Web server: Apache

Database: MySQL

PHP version: 5.6.30

Server version: (see your admin page) 9.1.5

Calendar version: (see the apps page) 1.4.1

Updated from an older installed version or fresh install: updated

Signing status (ownCloud/Nextcloud 9.0 and above): Sicherheits- & Einrichtungswarnungen Alle Überprüfungen bestanden.

List of activated apps: Enabled:

• activity: 2.3.2
• calendar: true
• comments: 0.3.0
• configreport: 0.1.1
• dav: 0.2.7
• federatedfilesharing: 0.3.0
• federation: 0.1.0
• files: 1.5.1
• files_pdfviewer: 0.8.1
• files_sharing: 0.10.0
• files_texteditor: 2.1
• files_trashbin: 0.9.0
• files_versions: 1.3.0
• files_videoplayer: 0.9.8
• firstrunwizard: 1.1
• gallery: 15.0.0
• notifications: 0.3.0
• provisioning_api: 0.5.0
• systemtags: 0.3.0
• templateeditor: 0.1
• updatenotification: 0.2.1 Disabled:
• encryption
• external
• files_antivirus
• files_external
• user_external
• user_ldap

The content of config/config.php:

{ "system": { "instanceid": "oc9975ab49a4", "passwordsalt": "REMOVED SENSITIVE VALUE", "secret": "REMOVED SENSITIVE VALUE", "trusteddomains": [ "REMOVED SENSITIVE VALUE" ], "datadirectory": "REMOVED SENSITIVE VALUE", "overwrite.cli.url": "REMOVED SENSITIVE VALUE", "dbtype": "mysql", "version": "9.1.5.2", "dbname": "REMOVED SENSITIVE VALUE", "dbhost": "REMOVED SENSITIVE VALUE", "dbtableprefix": "oc", "dbuser": "REMOVED SENSITIVE VALUE", "dbpassword": "REMOVED SENSITIVE VALUE", "installed": true, "defaultapp": "calendar", "loglevel": "2", "theme": "planungskalender", "maintenance": false, "memcache.local": "\OC\Memcache\APCu", "memcache.distributed": "\OC\Memcache\Memcached", "memcached_servers": [ [ "localhost", 11211 ] ], "mail_from_address": "REMOVED SENSITIVE VALUE", "mail_smtpmode": "php", "mail_domain": "REMOVED SENSITIVE VALUE", "trashbin_retention_obligation": "auto", "updater.secret": "REMOVED SENSITIVE VALUE" } }

Are you using external storage, if yes which one: no

Are you using encryption: no

Are you using an external user-backend, if yes which one: no

Client configuration

Browser: mostly firefox

Operating system: linux

CalDAV-clients: multiple

[jok2]

I've got the same issue with owncloud 10.1.1.1 (can't upgrade to 10.2 yet, PHP 5.6) and calendar 1.6.2.

[jok2]

It seems to be an issue with the core CalDAVBackend. In Nextcloud this error was fixed in https://github.com/nextcloud/server/pull/3678 , the corresponding issue was https://github.com/nextcloud/server/issues/3677

[jok2]

I created an issue in ownloud/core: https://github.com/owncloud/core/issues/36008