You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem:
Organisator can't access/change main appointment series entry after invited user declined first single entry.
In this case only the second and following recurrent entries may be updated by editing an untouched (not declined) entry. If for example the first 4 entries are declined by one or more users/participants, these entries have to be edited each one to be updated and not through changing the main series appointment entry.
Note: It is not relevant if an entry is confirmed/declined by web browser or CalDAV client!
Presumably it is a problem of the web frontend component as the CalDAV client of the inviter still shows the recurrent information!
Steps to reproduce
create a weekly recurring appointment within your personal calendar of User 1 (organisator/inviter). Starting at e.g. Friday 1st November 2024, no end date.
invite one or more other user/participant of your Nextcloud
let user 2 (participant) accept the appointment series first.
note: user 1 (organisator) is able to access/edit every single entry as a recurrent appointment starting from the time of the single appointment as it should be.
let user 2 (participant) decline the first single entry of Friday 1st November 2024
**Bug/Failure: ** from that moment user 1 sees the entry of Friday 1st November 2024 not any more as recurrent but as a single entry with no repetition.
If more single entries are declined from invited users, in the organisators/inviters calendar all those declined entries switch to single entries and it is not possible any more to change the content of the whole series any more. Only not declined entries may edited and changed any more.
This is a main function of calendaring and makes this not usable for bigger groups!
For better understanding there are a bunch of annotated screenshots (German version of Nextcloud) demonstrating the false behaviour.
Failure Screenshot look at last one with annotation "failure"!
Expected behavior
For user 1 (inviter) all entries must remain with the recurrence information, so that if you change one of the entries you are able to update all upcoming entries with that entered information.
Editing/responding of a participant to an invitation must therefore not result in the inviter's entries being changed, apart from the status information of the invited (acceptance, rejection, maybe).
Actual behaviour
If an invited participant declines a single entry of a series the corresponding entry of the organisator/inviter changes to a single entry without the recurrence information, what makes it not possible to update the whole series any more.
In the organisators/invitors calendar always display the series entry and not the individual one, or
add an option in the context menu of the entry to show the series, or
presumably the best and easiest to implement option, additionally always add the "Update this and all future" in the bottom area of the organisators calendar entry details area. Currently there's only the option "Update this occurrence".
Important:
The described buggy behaviour actually makes Nextcloud calendaring with appointments/invitations unusable!
Steps to reproduce
Organisator can't access/change main appointment series entry after invited user declined first single entry.
In this case only the second and following recurrent entries may be updated by editing an untouched (not declined) entry. If for example the first 4 entries are declined by one or more users/participants, these entries have to be edited each one to be updated and not through changing the main series appointment entry.
Note: It is not relevant if an entry is confirmed/declined by web browser or CalDAV client!
Presumably it is a problem of the web frontend component as the CalDAV client of the inviter still shows the recurrent information!
If more single entries are declined from invited users, in the organisators/inviters calendar all those declined entries switch to single entries and it is not possible any more to change the content of the whole series any more. Only not declined entries may edited and changed any more.
This is a main function of calendaring and makes this not usable for bigger groups!
For better understanding there are a bunch of annotated screenshots (German version of Nextcloud) demonstrating the false behaviour.
Failure Screenshot look at last one with annotation "failure"!
Expected behavior
For user 1 (inviter) all entries must remain with the recurrence information, so that if you change one of the entries you are able to update all upcoming entries with that entered information.
Editing/responding of a participant to an invitation must therefore not result in the inviter's entries being changed, apart from the status information of the invited (acceptance, rejection, maybe).
Actual behaviour
If an invited participant declines a single entry of a series the corresponding entry of the organisator/inviter changes to a single entry without the recurrence information, what makes it not possible to update the whole series any more.
Calendar app version
5.0.1
CalDAV-clients used
MacOS (15.1), iOS (18.1),
Browser
Safari 18.1, Chrome (Version 130.0.6723.92), Firefox (132.0.1)
Client operating system
MacOS 15.1
Server operating system
Managed Webhosting - Debian GNU/Linux 11 (bullseye)
Web server
None
Database engine version
MariaDB
PHP engine version
PHP 8.2
Nextcloud version
30.0.1
Updated from an older installed version or fresh install
Updated from an older version
List of activated apps
Enabled:
Nextcloud configuration
{
"system": {
"instanceid": "REMOVED SENSITIVE VALUE",
"passwordsalt": "REMOVED SENSITIVE VALUE",
"secret": "REMOVED SENSITIVE VALUE",
"trusted_domains": [
"REMOVED SENSITIVE VALUE",
"REMOVED SENSITIVE VALUE"
],
"datadirectory": "REMOVED SENSITIVE VALUE",
"tempdirectory": "REMOVED SENSITIVE VALUE/ncdata/tmp",
"skeletondirectory": "",
"overwrite.cli.url": "REMOVED SENSITIVE VALUE",
"dbtype": "mysql",
"version": "30.0.1.2",
"dbname": "REMOVED SENSITIVE VALUE",
"dbhost": "REMOVED SENSITIVE VALUE",
"dbport": "",
"dbtableprefix": "oc_",
"mysql.utf8mb4": true,
"dbuser": "REMOVED SENSITIVE VALUE",
"dbpassword": "REMOVED SENSITIVE VALUE",
"installed": true,
"maintenance": false,
"maintenance_window_start": "1",
"auth.bruteforce.protection.enabled": true,
"theme": "",
"loglevel": 2,
"mail_from_address": "REMOVED SENSITIVE VALUE",
"mail_smtpmode": "smtp",
"mail_domain": "REMOVED SENSITIVE VALUE",
"mail_smtphost": "REMOVED SENSITIVE VALUE",
"mail_smtpport": "465",
"mail_smtpauth": 1,
"mail_smtpauthtype": "LOGIN",
"mail_smtpname": "REMOVED SENSITIVE VALUE",
"mail_smtppassword": "REMOVED SENSITIVE VALUE",
"app_install_overwrite": [
"richdocuments",
"impersonate"
],
"data-fingerprint": "REMOVED SENSITIVE VALUE",
"default_phone_region": "DE",
"mail_sendmailmode": "smtp",
"defaultapp": "dashboard,files,calendar"
}
}
Web server error log
No response
Log file
No response
Browser log
No response
Additional info
No response
The text was updated successfully, but these errors were encountered: