Show Calendar URL in Web UI

[tbsbdr]

Initial Checklist

• I understand this is a user story and questions should be posted in the Community Discussions
• I searched issues and couldn’t find anything (or linked relevant results below)

User Story

As a user, I want to look up my personal calendar URL so that I can connect a third party application to it (e.g. Thunderbird, Apple Calendar).

User Value

Promote Calendar availability

Acceptance Criteria

• account page has a new panel (same architecture as app token panel)
• panel is only visible if a OPTIONS to the server URL (from config) urlJoined with path /.well-known/caldav responds with 301 and a location header set to /caldav/
• panel title is Calendar and shows a small badge with text NEW (technical note: oc-tag with attribute :rounded="true")
• panel content consists of:
  • a short message which explains that the user has their own calendar available for integration into third party apps (thunderbird, apple calendar, etc)
  • configuration:
    • url: render the server url, can be copied to clipboard via button
    • username = render the opencloud username, can be copied to clipboard via button
    • password = show a hint that an app token needs to be generated and then can be used.

[rhafer]

In theory with opencloud-eu/opencloud#773 it should be enough if the carddav/caldav clients would configure http://<my.cloud.domain>/caldav or http://<my.cloud.domain>/carddav as their base url and discover calenders and address books from there.

However, at least in the current Thunderbird this does not work for address books (https://bugzilla.mozilla.org/show_bug.cgi?id=1925006)

As a workaround we could display the full URL for the defaults:

Addressbook: https://<my.cloud.domain>/carddav/<user-id>/def-addressbook/
Calendar: https://<my.cloud.domain>/caldav/<user-id>/def-calendar/

[tammi-23]

panel is only visible if a OPTIONS to the server URL (from config) urlJoined with path /.well-known/caldav responds with 301 and a location header set to /caldav/

After thorough evaluation, this requirement cannot be reliably fulfilled using browser-based JavaScript due to platform limitations.

• The browser automatically follows 301 redirects.
• Even with fetch or using GET directly the browser does not expose the Location header of a redirect due to security and CORS restrictions.
• As a result, client-side code cannot detect whether a redirect happened or where it pointed to.

-> This makes it impossible to implement logic that depends on detecting a 301 and a Location header from a browser context alone.

Alternative approach:
As an Idee, instead of relying on the redirect, just checking directly whether the /caldav/ endpoint is reachable.

A 200 or 204 response from /caldav/ can be safely interpreted as CalDAV being available, fulfilling the intent of the original requirement. Or do I miss something if I do it this way?