Closed Bug 1665203 Opened 3 years ago Closed 2 years ago

auto-discovered read-only caldav calendars don't get set as read-only


(Calendar :: Provider: CalDAV, defect, P2)

Thunderbird 81


(thunderbird_esr78 wontfix)

91 Branch
Tracking Status
thunderbird_esr78 --- wontfix


(Reporter: justdave, Assigned: lasana)




(1 file)

Thunderbird 81.0b3 (64-bit) Mac

I have a Zimbra server with about 10 calendars on my account, but 6 of those are shared calendars that I don't have write access to. When adding the account to Apple Calendar, they correctly get flagged as read only, so Calendar won't let me create new events on them. When adding them to Thunderbird with the new calendar autodiscovery, they do not get flagged read-only (which is obvious in TB because it puts a lock next to read-only calendars in the UI), and it lets me create new events on them (which go away the next time I sync).

Doing further testing, I'm not sure this is related to auto-discovery. If I use the direct URL of the calendar to load it directly, it still doesn't automatically set the read-only flag.

Priority: -- → P2
Assignee: nobody → lasana

From what I can tell, there isn't anything in the related specs to indicate a calendar is read-only. I'm still looking into it but I think the only option might be to attempt to write to the calendar and detect whether we have access.

(In reply to Magnus Melin [:mkmelin] from comment #2)

I stand corrected. Thanks!

Target Milestone: --- → 91 Branch

Pushed by
Detect read-only caldav calendars via current-user-privilege-set. r=darktrojan

Closed: 2 years ago
Resolution: --- → FIXED
Pushed by
follow-up - Have CalDAVServer respond when asked for calendar privileges. rs=bustage-fix

We should do another bug to set .ics calendars as read-only by default as well. Those can be writable served purely over HTTP and HTTP PUT is ok'd by the server, though I'd imagine that is rare.
I tested a fastmail .ics calendar now and seems we silently ignore that the save didn't really take effect. The local copy shows the non-existant change until refresh though.

See Also: → 1715756
You need to log in before you can comment on or make changes to this bug.