Subscribing to calendars does not respect `X-WR-CALNAME` or `NAME` calendar properties

I am not sure this is the correct repo to report this, sorry if not.

Steps to reproduce

1. Create a new calendar in Nextcloud
2. Copy the private link of the calendar
3. Add the calendar via + -> New subscription from link

I am using a Nextcloud calendar but any endpoint with a calendar would work the same.

Expected behaviour

The calendar should be named after the X-WR-CALNAME or NAME calendar properties.

Actual behaviour

The calendar gets named after the domain name of the subscription link.

It could be argued that this is preferrable as it allows the usre to identify the calendar by the domain name instead of whatever cryptic name the ics file may contain. However, the user most probably copied the share link of the calendar from an application that already depicted the calendar name to the user and this is how the user identified the calendar they wanted to sync. Changing the name of the calendar upon subscribing in Nextcloud probably causes more confusion. Also, if the user wants to use the same calendar name as in the original app where the calendar lies, they have to go back and forth between Nextcloud and the other app, or look into the ics file which is much more complex for casual users.

Calendar app

2.3.4

CalDAV-clients used: None

Client configuration

Browser: Firefox Nightly 95.0a

Operating system: Macos

Server configuration

Operating system: Ubuntu 20.04.2 LTS

Web server: Apache

Database: MariaDB

PHP version: 8.0.3

Nextcloud Version: 22.2.3

Updated from an older installed version or fresh install: updated from 21

List of activated apps:

accessibility
comments
deck
files_external
files_versions
lookup_server_connector
password_policy
settings
text
user_ldap
activity
contacts
encryption
files_pdfviewer
files_videoplayer
news
photos
sharebymail
theming
user_status
admin_audit
contactsinteraction
extract
files_rightclick
firstrunwizard
nextcloud_announcements
privacy
support
twofactor_backupcodes
viewer
calendar
cookbook
federatedfilesharing
files_sharing
health
notes
provisioning_api
survey_client
twofactor_nextcloud_notification
weather_status
circles
dashboard
federation
files_texteditor
integration_google
notifications
recommendations
systemtags
twofactor_totp
workflowengine
cloud_federation_api
dav
files
files_trashbin
logreader
oauth2
serverinfo
tasks
updatenotification

Nextcloud configuration:

<?php
$CONFIG = array (
  'passwordsalt' => 'salt',
  'secret' => 'secret',
  'trusted_domains' =>
  array (
    0 => 'domain',
  ),
  'datadirectory' => '/var/www/html/nextcloud/data',
  'dbtype' => 'mysql',
  'version' => '22.2.3.0',
  'overwrite.cli.url' => 'url',
  'dbname' => 'dbname',
  'dbhost' => 'localhost',
  'dbport' => '3306',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'user',
  'dbpassword' => 'pass',
  'installed' => true,
  'htaccess.RewriteBase' => '/',
  'instanceid' => 'id',
  'theme' => '',
  'loglevel' => 0,
  'maintenance' => false,
  'overwrite' =>
  array (
    'cli' =>
    array (
      'url' => 'url',
    ),
  ),
  'htaccess' =>
  array (
    'RewriteBase' => '/',
  ),
  'updater.release.channel' => 'stable',
  'config_is_read_only' => true,
  'app_install_overwrite' =>
  array (
    0 => 'calendar',
  ),
  'twofactor_enforced' => 'true',
  'twofactor_enforced_groups' =>
  array (
    0 => 'admin',
  ),
  'twofactor_enforced_excluded_groups' =>
  array (
  ),
  'updater.secret' => 'secret',
);

Logs

Web server error log (e.g. /var/log/apache)

nothing relevant

Log file (data/nextcloud.log)

nothing relevant

Browser log

nothing relevant

The issue names no files or tests. Start by tracing the “+ → New subscription from link” flow and how the subscribed ICS calendar is named. Done means the calendar name comes from X-WR-CALNAME or NAME rather than the subscription URL’s domain, with coverage for the reported behavior.