nextcloud / nextcloud/calendar

Include subscribed (external ICS) calendars in appointment conflict detection

Open
#8,446 0 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement feature: caldav
Dominant language
JavaScript
Stars
1.2k
Forks
332
Avg merge
16h 13m
Merged PRs (30d)
137

Description

[!TIP]

Help move this idea forward
  • Use the 👍 reaction to show support for this feature.
  • Avoid commenting unless you have relevant information to add; unnecessary comments create noise for subscribers.
  • Subscribe to receive notifications about status changes and new comments.

Is your feature request related to a problem? Please describe.
When configuring an appointment schedule, subscribed calendars (external ICS feeds such as public holiday calendars) can be selected under "Additional calendars to check for conflicts". However, they are silently ignored by the conflict detection engine — slots remain available on days that should be blocked.
This was tested on Nextcloud 32.0.8 with a French public holiday calendar subscribed from data.gouv.fr. Despite the subscription being explicitly selected in the appointment configuration, slots on public holidays were freely bookable.

Describe the solution you'd like
Events cached from external ICS feeds are treated as blocking when they are selected in "Additional calendars to check for conflicts" in appointment schedules.

Describe alternatives you've considered
Import locally and Pre-process the ICS if necessayr before importing it as native events into nextcloud calendar.
See additional context for Pre-processing reasons.

Additional context
Nextcloud version: 32.0.8
Calendar app version: 6.2.2
The conflict detection engine is implemented in CalendarProvider.php. This class only calls CalDavBackend::getCalendarsForUser() to retrieve calendars for conflict checking. It never calls CalDavBackend::getSubscriptionsForUser(), which is the separate method that handles external ICS subscriptions (calendartype = 1 in oc_calendarobjects).
This can be confirmed in the database: subscribed calendar events are stored with calendartype = 1, while native calendar events use calendartype = 0. The conflict engine only queries calendartype = 0.
PR nextcloud/server#48621 extended conflict detection to include shared calendars (calendars shared between Nextcloud users), but subscribed calendars were not included in its scope.

While working around this limitation by importing the ICS feed as native calendar events, two additional issues were discovered that also prevent conflict blocking, even for native events:

  1. Missing STATUS field — the conflict engine appears to require STATUS:CONFIRMED to treat an event as blocking. The RFC 5545 spec defines STATUS as optional, with absence implying confirmed. The engine should treat missing STATUS as CONFIRMED by default.
  2. Zero-duration all-day events — the data.gouv.fr public holiday feed (and likely others) produce events where DTEND = DTSTART, which is technically an RFC 5545 violation (spec requires DTEND strictly after DTSTART for VALUE=DATE events). The engine silently ignores these events instead of either blocking the slot or warning the user.

These two issues are independent of the subscribed calendar problem but compound it when using the import workaround.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with CalendarProvider.php and trace how CalDavBackend::getCalendarsForUser() supplies calendars for conflict checking, then compare it with getSubscriptionsForUser(). Review the existing conflict-detection behavior and define completion as selected external ICS calendars blocking appointment slots; the STATUS and zero-duration event concerns are additional scope to clarify.

Written by the indexing model from the issue text.

Assessment

Tech stack
php
Domain
backend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.