This is a minor releases covering a wide span of bug fixes and features to harden Davis and make it even more robust and resilient to various clients' behaviors and auth provider shenanigans.

⚠️ Read the changelog and the "How to upgrade" section below carefully

📰 Main new features or changes

• ✨ New page: Diagnostics, at /dashboard/diagnostics (#297) to ease debugging and find misconfigurations (migrations you have not run, mail settings, DAV endpoint URL, timezone configuration, etc ...)
• ✨ New command: php bin/console davis:mail:test [email protected] (#296). Sends one message with the actual mail settings to test them
• 🔒 The shared directory is no longer writable by every account (#285). Any signed-in user can read it. Only admins can write, unless you set WEBDAV_PUBLIC_DIR_WRITABLE=true. See the upgrade note below.
• 🐛 Events are saved even when there is a failure sending invitations (#296)
• 🔒 An account cannot be saved without an email address (#296). An empty address quietly stops every invitation from that account. See the upgrade note below.
• 🔤 LDAP is no longer case-sensitive for usernames (#289). Davis now uses the spelling the directory returns. See the upgrade note below.
• 💪🏼 Frontend better validation and hardening (CSRF, CSS injection) (#290, #295)

🐛 Other bug fixes

• CardDAV sync no longer loses changes and sync reports are much faster (#287) (based on @AnnoyingTechnology's work)
• Saving a property no longer fails or adds up rows (#288)
• Address books can be created without a name (#286) (Turns out the name is optional in CardDAV)
• Subscribing to a calendar feed no longer fails when clients don't send default (#286)
• The API answers when no key is set (API_KEY is empty by default) (#298)
• The profiler no longer runs in production (#284)
• Fix edge cases where a public calendar was not readable by everyone (#298)
• Deleting an address book no longer crashes (#298)

⚙️ Misc

• Docker images now use PHP 8.4 (#299), up from 8.3.
• nginx and Caddy examples improvements and Dockerfile and env refactors to harden production and dev setup (#292)
• /.well-known/caldav and /.well-known/carddav are now handled by Davis (#289) - No web server rule is needed, and it allows sub directories
• Added logs on sending invitations to debug more easily (#296)
• Repeated failed logins are throttled now (#292)
• Performance improvements (new SAPI, allowing streaming responses) (#300)

How to upgrade

0. Back up your database

This is a safety precaution in case you end up messing with a migration or the database in general. It's highly recommended, even if you know exactly what you're doing.

1. Update the code and migrate

You can now update the code (either directly or get the up to date container), and then run the remaining migrations with:

bin/console doctrine:migrations:migrate --allow-no-migration

2. Update or add necessary env vars

WebDAV shared directory (only if WEBDAV_ENABLED=true)

If you relied on the shared directory being writable by everyone, add:

WEBDAV_PUBLIC_DIR_WRITABLE=true

Otherwise only admins can write there from now on. Everyone can still read it in any case

3. LDAP accounts stored under a different spelling

What changed. Davis used to store whatever username the person typed. It now stores the spelling your directory returns. So if someone logged in as ALICE and your directory says alice, Davis used to create the account as ALICE, and from now on it looks for alice.

What you would see. That person logs in fine but their calendars and contacts are gone — the data is still there, filed under the old spelling. If they typed their name two different ways over time, you may also have two accounts for them, one of them empty.

Find out if you are affected. Both lists should contain each person once, spelled the way your directory spells them:

SELECT username FROM users ORDER BY username;
SELECT uri FROM principals WHERE uri NOT LIKE '%calendar-proxy%' ORDER BY uri;

If a person appears twice, delete the empty account from the dashboard first, then follow the rename below for the one that kept the data.

To rename an account, back up your database, then run the block below. Replace ALICE with the spelling currently stored and alice with the spelling your directory returns

BEGIN;
UPDATE users                 SET username     = 'alice'            WHERE username = 'ALICE';
UPDATE principals            SET uri          = replace(uri, 'principals/ALICE', 'principals/alice')        WHERE uri = 'principals/ALICE' OR uri LIKE 'principals/ALICE/%';
UPDATE calendarinstances     SET principaluri = 'principals/alice' WHERE principaluri = 'principals/ALICE';
UPDATE addressbooks          SET principaluri = 'principals/alice' WHERE principaluri = 'principals/ALICE';
UPDATE calendarsubscriptions SET principaluri = 'principals/alice' WHERE principaluri = 'principals/ALICE';
UPDATE schedulingobjects     SET principaluri = 'principals/alice' WHERE principaluri = 'principals/ALICE';
UPDATE propertystorage       SET path = replace(path, 'calendars/ALICE/', 'calendars/alice/')       WHERE path LIKE 'calendars/ALICE/%';
UPDATE propertystorage       SET path = replace(path, 'addressbooks/ALICE/', 'addressbooks/alice/') WHERE path LIKE 'addressbooks/ALICE/%';
UPDATE propertystorage       SET path = replace(path, 'principals/ALICE', 'principals/alice')       WHERE path LIKE 'principals/ALICE%';
COMMIT;

The principals line also renames that person's two delegation entries, so you do not need to touch those separately. Run the two SELECTs again afterwards to confirm.

4. Accounts without an email address

An account whose email is empty never sends invitations (but it was hard to debug properly). The dashboard now refuses to save one, but existing accounts are untouched. To find all of the offending accounts:

SELECT uri, email FROM principals WHERE email IS NULL OR email = '';

The address has to be the one the account's calendar client sends as the event organiser, otherwise Davis has nothing to send an invitation on behalf of. You can check the mail settings themselves with php bin/console davis:mail:test [email protected].

5. Web server configuration

If your web server rewrites /.well-known/caldav or /.well-known/carddav itself, you can drop those rules. They take precedence over Davis and will send clients to the wrong place on a sub-directory installation.

6. Reverse proxy on a PHP built without IPv6

If your PHP was built with --disable-ipv6 and you set SYMFONY_TRUSTED_PROXIES, your proxy has to reach Davis over IPv4 or every request returns a 500. Point it at 127.0.0.1 rather than localhost, which usually resolves to ::1 first. See the README for details.

Full Changelog: v5.4.4...v5.5.0

This is mainly a security release. All users are encouraged to upgrade.

• 🔒 Fixed an ACL bypass in the DAV server: appending ?sabreAction=asset to a URL skipped every permission check, letting any authenticated user read other users' events, contacts and files, and letting anonymous clients overwrite existing objects. The shortcut is now limited to the browser plugin's assets on the DAV root
• 🔒 Empty passwords are now rejected by all authentication backends. With LDAP, an empty password was passed to ldap_bind, which some directories (notably Active Directory) treat as a successful anonymous bind, allowing a login as any user
• 🔒 Destructive actions in the admin dashboard are now protected against CSRF: deleting users, calendars and address books, sharing and revoking calendars, and managing delegates are now POST requests carrying a token, instead of plain GET links
• 🔒 The dashboard and the API now check that a calendar or address book belongs to the user in the URL before showing, editing, sharing or deleting it. Deleting a calendar that was shared with a user only removes that share and no longer touches the owner's calendar; a calendar can no longer be shared with its own owner
• 🐛 The API no longer deletes all of a user's subscriptions and inbox items when one calendar is deleted, and GET /api/v1/calendars/{userId} no longer fails for users who have a calendar subscription

API note: PUT/PATCH/DELETE /api/v1/calendars/{userId}/{calendar_id} and the /shares endpoints now return 400 when calendar_id is a calendar merely shared with the user. DELETE on such an instance removes the share only.

What's Changed

• Fixed security hole by @SeLLeRoNe in #268
• Fixed Invitation replies (accepted / declined / tentative) sent by e-mail showing the attendee as "(null)" in some mail clients, Apple Mail in particular (db8e571)
• Security fixes in #283

New Contributors

• @SeLLeRoNe made their first contribution in #268

How to upgrade

Nothing to do if you're on v5.4.3

Full Changelog: v5.4.3...v5.4.4

What's Changed

• Shared calendars now inherit the calendar colour upon seeding in #266

This is a minor upgrade that embarks new minor dependencies releases.

How to upgrade

Nothing to do if you're on v5.4.2

Full Changelog: v5.4.2...v5.4.3

What's Changed

• Dashboard fixes in #256 by @lukastrkan

This is a bugfix release correcting various small bugs around user deletion

How to upgrade

Nothing to do if you're on v5.4.1

Full Changelog: v5.4.1...v5.4.2

What's Changed

This is a bugfix release correcting a bug where subscriptions would be deleted upon calendar deletion.

How to upgrade

Nothing to do if you're on v5.4.0

Full Changelog: v5.4.0...v5.4.1

This release fixes the public calendar behaviour that was not consistent and refactors the birthday service to have a more robust synchronization. The included migration file will take care of doing the necessary changes in the database, 💁🏼‍♂️ do not forget to run the migrations.

What's Changed

• Update german translation by @King3R in #235
• Add French translation
• Lots of CI and Docker build improvements
• Update to Symfony 7.4
• Changes in user parameter in dashboard urls
• Improved and fixed the public calendar feature in #239
• Add (limited) API endpoint by @unkn0wnAPI in #237
• Refactored the Birthday service (automatic birthday calendar)

How to upgrade

0. Back up your database

This is a safety precaution in case you end up messing with a migration or the database in general. It's highly recommended, even if you know exactly what you're doing.

1. Update the code and migrate

You can now update the code (either directly or get the up to date container), and then run the remaining migrations with:

bin/console doctrine:migrations:migrate --allow-no-migration

Full Changelog: v5.3.0...v5.4.0

What's Changed

• PHP-imap replacement in #198 (Thanks @Ramblurr and @n-connect for your help!)
• Update dependencies
• Minor CS fixups

How to upgrade

If you're on v5.2.0, there is no database migration, but the IMAP configuration has changed following the removal of php-imap as a dependency and the usage of https://www.php-imap.com/ as a replacement (context)

New config format

You need to update your configuration to use the new format. The flags are now standalone parameters that you need to fill:

Before

IMAP_AUTH_URL={imap.gmail.com:993/imap/ssl/novalidate-cert}

After

IMAP_AUTH_URL=imap.mydomain.com:993
IMAP_ENCRYPTION_METHOD=ssl
IMAP_CERTIFICATE_VALIDATION=false

The rest of the configuration is unchanged.

Full Changelog: v5.2.0...v5.3.0

What's Changed

• Added an automatic birthday calendar in #190
• Update dependencies (notably Symfony 7.3)
• Fix the standalone docker image to pass X-Forwarded-* headers in #217
• Minor fixups in the README

How to upgrade

0. Back up your database

This is a safety precaution in case you end up messing with a migration or the database in general. It's highly recommended, even if you know exactly what you're doing.

1. Update the code and migrate

You can now update the code (either directly or get the up to date container), and then run the remaining migrations with:

bin/console doctrine:migrations:migrate --allow-no-migration

There is a new BIRTHDAY_REMINDER_OFFSET env var (default to PT9H), check the README for more information.

Full Changelog: v5.1.3...v5.2.0

What's Changed

• [Feature] Add calendar public flag option by @1Luc1 in #200
• Switch to bigint for occurence timestamps in #186
• Move docker env vars to .env by @eosti in #210
• Various other small updates for Docker + documentation

How to upgrade

0. Back up your database

This is a safety precaution in case you end up messing with a migration or the database in general. It's highly recommended, even if you know exactly what you're doing.

1. Update the code and migrate

You can now update the code (either directly or get the up to date container), and then run the remaining migrations with:

bin/console doctrine:migrations:migrate --allow-no-migration

Also, there is a new PUBLIC_CALENDARS_ENABLED env var (default to true, maintaining the previous behaviour), check the README for more information.

Thanks @1Luc1 for your help

Full Changelog: v5.1.2...v5.1.3

What's Changed

• Fix .env overriding in #204 - mainly used for NixOS
• 🇩🇪 German translation by @King3R in #206

How to upgrade

Nothing if you're on v5+

Full Changelog: v5.1.1...v5.1.2