Writable calendar share permission is toggled off when opening the share dialog

[airflow2010]

Steps to reproduce

1. Log in to the Nextcloud web UI as User A.
2. Open the Calendar app.
3. Create or use an existing calendar owned by User A.
4. Share that calendar internally with User B.
5. Enable write permission for User B using the checkbox labeled can edit and see confidential events.
6. Close the calendar edit/share dialog.
7. Re-open the same calendar edit/share dialog.
8. Observe the permission state.
9. Repeat opening the dialog / toggling permissions a few times.

This was reproduced with two local users on the same Nextcloud instance. The share is an internal Nextcloud calendar share, not a public link, not an ICS/WebCal subscription, and not a federated share.

Expected behavior

Opening the calendar edit/share dialog should not change existing share permissions.

If a calendar is shared read/write with another local user, the write permission should remain enabled until the owner explicitly changes it.

The permission checkbox should reflect the current backend state without causing a write request or toggling the permission.

Actual behavior

Opening the calendar edit/share dialog can immediately change an existing read/write share back to read-only.

After several attempts, the UI starts showing:

An error occurred, unable to change the permission of the share.

The server log then shows DAV share rate limiting:

Too many addressbook or calendar share requests
Rate limit exceeded

The issue appears to be triggered by the web Calendar app itself. The backend database confirms that the permission is actually changed server-side, not only displayed incorrectly.

In oc_dav_shares, the affected share changes between:

access = 2  -- read/write
access = 3  -- read-only

Calendar app version

6.4.0

CalDAV-clients used

The issue was reproduced using only the Nextcloud web Calendar UI.

Browser

Chrome 148.0.7778.96

Client operating system

Ubuntu LTS

Server operating system

Nextcloud AIO Docker setup on Linux

Web server

Apache

Database engine version

PostgreSQL

PHP engine version

PHP 8.3

Nextcloud version

33.0.3.2

Updated from an older installed version or fresh install

Updated from an older version

List of activated apps

activity: 6.0.0
calendar: 6.4.0
dav: 1.36.0
mail: 5.7.15

Nextcloud configuration

Nextcloud AIO
Nextcloud 33.0.3
Calendar 6.4.0
DAV 1.36.0
PostgreSQL
Apache
PHP 8.3.31

Web server error log

No relevant Apache error log entry was found for the permission toggle itself.

Log file

Browser log

Additional info

I inspected the built Calendar app source map of the installed app and found a likely cause in:

src/components/AppNavigation/EditCalendarModal/ShareItem.vue

The permission checkbox uses both v-model and an explicit update handler:

<NcCheckboxRadioSwitch
    v-if="canBeSharedWritable"
    v-model="isWriteable"
    :disabled="updatingSharee"
    @update:checked="updatePermission">
    {{ $t('calendar', 'can edit and see confidential events') }}
</NcCheckboxRadioSwitch>

Additionally, there is a watcher:

watch: {
    isWriteable() {
        this.updatePermission()
    },
},

And on mount:

mounted() {
    this.isWriteable = this.initialIsWriteable
    this.updateShareeEmail()
}

Because isWriteable initially defaults to false, opening the dialog for an already writable share sets it to true in mounted(). That appears to trigger the watcher, which calls updatePermission() even though the user did not change anything.

The store method toggles the current value:

async toggleCalendarShareWritable({ calendar, uri }) {
    const sharee = calendar.shares.find((sharee) => sharee.uri === uri)
    await calendar.dav.share(uri, !sharee.writeable)
    sharee.writeable = !sharee.writeable
}

So if a share is initially writable, simply opening the dialog may trigger a toggle to read-only.

This matches the observed behavior exactly:

1. Share is read/write in the database.
2. Open the edit/share dialog.
3. Frontend initializes isWriteable.
4. Watcher calls updatePermission().
5. Backend receives a share update request.
6. Share becomes read-only.
7. Repeated attempts eventually hit the DAV share rate limit.

This appears to be a web Calendar UI bug rather than a CalDAV server bug, because the unwanted permission change is triggered by opening/interacting with the web Calendar share dialog.

[EmmyGraugans]

We were also just hit by this bug (same App- and Nextcloud-version as above).

In addition: it doesn't make a difference, if one closes the share-dialog with the "Save" button or by clicking the "X" in top-right, the damage already happened. Also, the display shows the checkmark, but it is actually read-only.

Also a note re: Rate-limiting: once the limit is hit, one can observe that for a calendar that is writable, the notice appears as soon as the share-dialog is opened, while for a different calendar that is not writable the notice appears only when setting the checkmark within the dialog.

P.S. It seems unexpected (to me) that when hitting the X-button, the state as shown in the dialog is still applied, usually only "Save"ing should change the setting, while simply closing the window should keep the originally saved values.

Edit: es gibt wohl schon einen Fix, der nur noch in ein neues Release wandern muss? 0b71fbf

[SebastianKrupinski]

Morning.

This has already been fixed, will be released this week.

#8329

[stefangweichinger]

Is there maybe a workaround or trick that I can tell my customer while we wait for the new release?
thanks for the quick fix ..

[SebastianKrupinski]

Fix released in v6.4.1

[stefangweichinger]

Fix released in v6.4.1

Thanks a lot