https://bugs.kde.org/show_bug.cgi?id=527662
Bug ID: 527662
Summary: DAV resource resets locally customized calendar
display names to server-provided names
Classification: Frameworks and Libraries
Product: Akonadi
Version First unspecified
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: DAV Resource
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
DESCRIPTION
I am using KOrganizer/Kontact with an Akonadi DAV Groupware resource to access
my own calendar and several shared calendars belonging to colleagues. All
calendars are hosted on the same institutional CalDAV server, which provides
access to Exchange calendars.
Each calendar is configured through its own CalDAV URL within a single DAV
Groupware resource. Since the calendars belong to different people, I have
assigned individual display names to distinguish them in KOrganizer.
However, these custom display names are overwritten during calendar
synchronization. Most calendars revert to the generic name "Calendar", making
it practically impossible to distinguish between them.
This setup worked previously, although I cannot pinpoint the exact version when
the issue first appeared. I suspect it may have started around KDE PIM 6.8.0
(August 2026).
STEPS TO REPRODUCE
1. Configure an Akonadi DAV Groupware resource with multiple CalDAV calendars
belonging to different users. The server returns the same `DAV:displayname`
("Calendar") for these calendars.
2. Assign individual display names to the calendars in KOrganizer.
3. Right-click the DAV Groupware resource (in my case, "Uni Rostock") and
select "Update Calendar" ("Kalender aktualisieren").
4. Observe the calendar names after synchronization.
OBSERVED RESULT
The individually assigned display names are immediately replaced with the
server-provided name "Calendar" after synchronization.
The issue is reproducible every time I manually refresh the DAV Groupware
resource.
EXPECTED RESULT
Locally assigned calendar display names should be preserved during
synchronization, particularly for shared calendars where the user may not have
permission to modify the server-side calendar name.
SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 6.8.1
KDE Frameworks Version: 6.31.0
Qt Version: 6.12.0
Graphics Platform: Wayland
Kernel Version: 7.2.11-zen1-1-zen (64-bit)
kdepim-runtime: 26.08.2-1 (KDE PIM 6.8.2)
akonadi: 26.08.2-2
korganizer: 26.08.2-1
ADDITIONAL INFORMATION
**CalDAV server behavior**
I verified the server-side display names using HTTP PROPFIND requests for the
`DAV:displayname` property.
Both my own calendar and a shared calendar belonging to a colleague return:
`<D:displayname>Calendar</D:displayname>`
Both requests succeed with HTTP 200 OK.
The CalDAV URLs follow this pattern:
`https://caldav.example.org/users/[email protected]/calendar/`
Interestingly, Outlook on the web displays the shared calendars under their
respective owners' names, independently of the underlying CalDAV display name.
**Potential regression in KDE PIM 6.8**
Two changes in `kdepim-runtime`, included in KDE Gear 26.08.0, appear
potentially relevant:
1. "Dav: Dont ignore ENTITYDISPLAY collection changes"
https://github.com/KDE/kdepim-runtime/commit/30ab4c7785fc5ab8e6d567f4c2fad0bec5a9b7a8
This commit introduces `setKeepLocalCollectionChanges({})`, apparently
disabling the previous preservation of local `EntityDisplayAttribute` changes
during collection synchronization.
2. "Dav: Add collectionChanged displayName attribute sync"
https://github.com/KDE/kdepim-runtime/commit/879edd6328a2051625eb700df868ec2b2f042abb
This commit adds synchronization of locally changed calendar display names to
the DAV server.
I suspect these changes may have affected the handling of locally customized
names for shared calendars, particularly when the server reports identical
display names for calendars belonging to different users. However, I have not
verified that either change is responsible.
**Database backend**
Around the same period, I migrated Akonadi from MySQL to SQLite because of
other database-related issues. To the best of my recollection, the calendar
naming problem already existed before this migration, so I suspect the two are
unrelated.
--
You are receiving this mail because:
You are watching all bug changes.
