auto-discovered read-only caldav calendars don't get set as read-only
Categories
(Calendar :: Provider: CalDAV, defect, P2)
Tracking
(thunderbird_esr78 wontfix)
Tracking | Status | |
---|---|---|
thunderbird_esr78 | --- | wontfix |
People
(Reporter: justdave, Assigned: lasana)
References
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
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.
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
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.
Comment 2•3 years ago
|
||
Assignee | ||
Comment 3•3 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #2)
https://stackoverflow.com/questions/57116267/determine-access-rights-for-caldav-calendars
I stand corrected. Thanks!
Assignee | ||
Comment 4•3 years ago
|
||
Assignee | ||
Updated•3 years ago
|
Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/c6ac24fa0f69
Detect read-only caldav calendars via current-user-privilege-set. r=darktrojan
Comment 7•3 years ago
|
||
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.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•