[Bug]: Declined event shows as busy in free/busy availability

section1 commented 4 months ago

⚠️ This issue respects the following points: ⚠️

[X] This is a bug, not a question or a configuration/webserver/proxy issue.
[X] This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
[X] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
[X] I agree to follow Nextcloud's Code of Conduct.

Bug description

When you decline an even/meet the time slot still shows as busy in free/busy availability.

Steps to reproduce

userA sends a meet to userB
userB decline the meet
userX checks userB free/busy slot and show as busy at tthat time that have the declined meet.

Expected behavior

Userb shows as free.

Installation method

Community Manual installation with Archive

Nextcloud Server version

28

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

[X] Default user-backend (database)
[X] LDAP/ Active Directory
[ ] SSO - SAML
[ ] Other

Configuration report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "calendar.domain.tld"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "27.1.11.3",
        "overwrite.cli.url": "https:\/\/calendar.domain.tld",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "skeletondirectory": "",
        "defaultapp": "calendar",
        "session_lifetime": 14400,
        "remember_login_cookie_lifetime": 172800,
        "token_auth_enforced": true,
        "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "25",
        "maintenance": false,
        "theme": "",
        "loglevel": 2
    }
}

List of activated Apps

Enabled:
  - calendar: 4.7.12
  - circles: 27.0.1
  - cloud_federation_api: 1.10.0
  - contactsinteraction: 1.8.0
  - dav: 1.27.1
  - federatedfilesharing: 1.17.0
  - federation: 1.17.0
  - files: 1.22.0
  - files_reminders: 1.0.0
  - files_rightclick: 1.6.0
  - files_trashbin: 1.17.0
  - files_versions: 1.20.0
  - logreader: 2.12.0
  - lookup_server_connector: 1.15.0
  - nextcloud_announcements: 1.16.0
  - notifications: 2.15.0
  - oauth2: 1.15.2
  - password_policy: 1.17.0
  - privacy: 1.11.0
  - provisioning_api: 1.17.0
  - related_resources: 1.2.0
  - serverinfo: 1.17.0
  - settings: 1.9.0
  - systemtags: 1.17.0
  - theming: 2.2.0
  - twofactor_backupcodes: 1.16.0
  - updatenotification: 1.17.0
  - user_ldap: 1.17.0
  - user_status: 1.7.0
  - viewer: 2.1.0
  - workflowengine: 2.9.0
Disabled:
  - activity: 2.19.0 (installed 2.19.0)
  - admin_audit: 1.17.0
  - bruteforcesettings: 2.7.0
  - comments: 1.17.0 (installed 1.17.0)
  - dashboard: 7.7.0 (installed 7.7.0)
  - encryption: 2.15.0
  - files_external: 1.19.0
  - files_pdfviewer: 2.8.0 (installed 2.8.0)
  - files_sharing: 1.19.0 (installed 1.19.0)
  - firstrunwizard: 2.16.0 (installed 2.16.0)
  - photos: 2.3.0 (installed 2.3.0)
  - recommendations: 1.6.0 (installed 1.6.0)
  - sharebymail: 1.17.0 (installed 1.17.0)
  - support: 1.10.1 (installed 1.10.0)
  - survey_client: 1.15.0 (installed 1.15.0)
  - suspicious_login: 5.0.0
  - text: 3.8.1 (installed 3.8.0)
  - twofactor_totp: 9.0.0
  - weather_status: 1.7.0 (installed 1.7.0)

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

section1 commented 4 months ago

I do some test to see if it's easy to fix... i'm not a programmer but i found this:

--- 3rdparty/sabre/vobject/lib/FreeBusyGenerator.php-ori        2024-06-25 10:23:42.000000000 +0000
+++ 3rdparty/sabre/vobject/lib/FreeBusyGenerator.php    2024-08-02 16:20:03.981952480 +0000
@@ -376,6 +376,14 @@ class FreeBusyGenerator
                             }
                         }

+                        if (isset($component->ATTENDEE)) {
+                            foreach ($component->ATTENDEE as $attendee) {
+                                if (str_contains($attendee, 'user@domain.tld') && 'DECLINED' === $attendee['PARTSTAT']->getValue()) {
+                                    break 2;
+                                }
+                            }
+                        }
+
                         $times = [];

                         if ($component->RRULE) {

but i don't know how to solve this part: if (str_contains($attendee, 'user@domain.tld') && 'DECLINED' === $attendee['PARTSTAT']->getValue()) {

To automatically check the real current user availability...i hard-coded my user. Sure needs a lot of work and checks etc..is a dumb POC code.

section1 commented 2 months ago

i create this patch for version 28.0.9 ... I duplicate the EventIterator with one called FreeBusyEventIterator with some changes because not sure about others calls to this iterator are affected with this changes... i don't want to break more important parts than a freebusy status.

patch: https://github.com/section1/nextcloud-stuff/blob/main/nextcloud-28.0.9-fix-declined-freebusy.patch

kesselb commented 2 months ago

cc @ChristophWurst @miaulalala @SebastianKrupinski

SebastianKrupinski commented 2 months ago

If the declining user is using the NC UI, then I think the better solution to this would be to set the STATUS property to CANCELLED. The Sabre code already checks for a CANCELLED status. This way we don't need to create a Sabre patch and it would have the site benefit of showing up on the declining users Calendar differently.

section1 commented 2 months ago

Hi @SebastianKrupinski , thanks for the respond, In my case and what i see in issues/help forum most users use a caldav client like thunderbird or the mobile phone etc so that still will don't work as expected..

BUT taking that out i have a doubt about that approach. Example a recurrent event with 10 attendees, someone decline the next coming event the STATUS property change to CANCELLED.. the doubt i have is: the STATUS change only is reflected to that user that declined the event or all attendees ?

SebastianKrupinski commented 2 months ago

The STATUS should only be applied to the declining user (The user that declined).

And you are correct this approach, will not work for external clients. Problem is unless I missed something in the RFC(s), it does not specify how to handle the event on the decliners calendar, so every client handles it differently.

miaulalala commented 1 month ago

The STATUS should only be applied to the declining user (The user that declined).

And you are correct this approach, will not work for external clients. Problem is unless I missed something in the RFC(s), it does not specify how to handle the event on the decliners calendar, so every client handles it differently.

Be careful with how you talk about things please 🙏 there's two different properties at work here. One is the PARTSTAT on the ATTENDEE - which is what changes when a user declines an invitation and triggers an iTIP message REPLY and a SEQUENCE increase, and the other is the STATUS property CANCELLED on the VEVENT which is not a significant change property and will not trigger an iTIP message nor a SEQUENCE change.

So if you're talking about declining that is different than setting the status to cancelled

section1 commented 1 month ago

I can provide more info for the users that have the same problem: Im using this patch in a production environment and users are happy now that slots are free in declined events. Basically the patch looks for the PARTSTAT property using the email of the user when checking for the user free/busy status.. If an event or an instance of a recursive event has declined in PARTSTAT for that email that "slot" don't count as Busy.. (this has a problem for example if two users have the same email not my case..and not sure about users without email.)

The other way to free a slot of an event that you don't want to attend is asking the organizer to remove you from the event but you depend of that "manual" interaction that 80% of the time never happens. and you have users more frustrated :D

The other way is deleting the event in your calendar...but this has a problem because for recurrent events when someone makes an update(like an attendee accept/decline one of the serie) the whole event appears again in your calendar.

nextcloud / server