[Bug]: Some events don't shows in Free/busy Availability

[section1]

⚠️ This issue respects the following points: ⚠️

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

Bug description

Some user have an event in their calendar but in free/busy availability the slot show as "Free".
I parse the ICS with different validators and passed successfully. But not sure if it's valid and how to reproduce it.
It something related to RDATE.

Steps to reproduce

1. Not sure how the user created this meet(thunderbird)...but i append the ICS.

Expected behavior

The expected behavior is that in freebusy availability the slot is taken and don't show the user 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

Additional info

i can Fix this if in file ./3rdparty/sabre/vobject/lib/FreeBusyGenerator.php line 389 change this:

                         $times = [];
 
-                        if ($component->RRULE) {
+                        if ($component->RRULE || $component->RDATE) {
                             try {
                                 $iterator = new EventIterator($object, (string) $component->UID, $this->timeZone);

but not sure if is the ideal solution.

ICS:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
BEGIN:VTIMEZONE
TZID:America/Argentina/Buenos_Aires
BEGIN:STANDARD
TZOFFSETFROM:-0300
TZOFFSETTO:-0300
TZNAME:-03
DTSTART:19700101T000000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20240826T155456Z
LAST-MODIFIED:20240826T160113Z
DTSTAMP:20240826T160113Z
UID:e1309d6f-544a-477d-b4ce-9e8631f2cc8d
RDATE;TZID=America/Argentina/Buenos_Aires:20240828T173000
DTSTART;TZID=America/Argentina/Buenos_Aires:20240828T173000
X-MOZ-FAKED-MASTER:1
X-MOZ-GENERATION:1
END:VEVENT
BEGIN:VEVENT
CREATED:20240826T152656Z
LAST-MODIFIED:20240826T160113Z
DTSTAMP:20240826T160113Z
UID:e1309d6f-544a-477d-b4ce-9e8631f2cc8d
SUMMARY:1 on 1
RECURRENCE-ID;TZID=America/Argentina/Buenos_Aires:20240828T173000
ORGANIZER;PARTSTAT=NEEDS-ACTION;CUTYPE=INDIVIDUAL:mailto:xx@xx.xx
ATTENDEE;CN=xxxxx xxxxxxxxxx;PARTSTAT=NEEDS-ACTION;CUTYPE=INDIVIDUAL;ROLE=R
 EQ-PARTICIPANT;SCHEDULE-STATUS=1.2:mailto:xxxxxx@xxxx.xxx
ATTENDEE;PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT:mailto:xx
 xxx@xxxxxx.xx
ATTENDEE;CN=xxxxxxxx xxxxxxxx;PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL;ROLE=REQ-
 PARTICIPANT:mailto:xxxxxxxxxxxxxxxxxx@xxxx.xxx
DTSTART;TZID=America/Argentina/Buenos_Aires:20240829T150000
DTEND;TZID=America/Argentina/Buenos_Aires:20240829T160000
TRANSP:OPAQUE
X-MOZ-GENERATION:7
LOCATION:House
SEQUENCE:3
END:VEVENT
END:VCALENDAR

[kesselb]

cc @ChristophWurst @miaulalala @SebastianKrupinski

[SebastianKrupinski]

Yes this would fix the RDATE issue but we would still have a secondary issue. Yes the iterator should be called if there is a RDATE, the problem is that the default iterator only handles one property, so if there is a RRULE and RDATE only the RRULE will be processed due to a oversight in the Sabre DAV library.

That said, I'll do a Sabre PR for this fix.

[section1]

thanks @SebastianKrupinski

[SebastianKrupinski]

Upstream fix: sabre-io/vobject#691