Closed Bug 1670416 Opened 4 years ago Closed 3 years ago

webdav acls not checked during setup

Categories

(Calendar :: Provider: CalDAV, enhancement)

Thunderbird 82
enhancement

Tracking

(thunderbird_esr91+ fixed, thunderbird92 affected)

RESOLVED FIXED
93 Branch
Tracking Status
thunderbird_esr91 + fixed
thunderbird92 --- affected

People

(Reporter: dpa-mozilla, Assigned: lasana)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

With 82.0b2 I click "+ add calendar”, enter as server https://aaa.bapha.be, without user name, do Offline Support. → Find Calendars.

TB finds three calendars. I click on Properties.

For anonymous access the calendars are read-only, but the Properties do not show autmatic a tick before 'Read Only'. Neither do the WebDAV calls utilize the WebDAV ACL.

Actual results:

On setting up calendar use WebDAV ACL to find out, if a calendar is read-only and fill this in the Calendar Properties

Now for https://aaa.bapha.be two calendar-home-sets are returned, so to test this first https://bugzilla.mozilla.org/show_bug.cgi?id=1670415 has to be fixed.

xref bug 306495

Should hook up calACLUtils.jsm where appropriate I guess.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Has this been fixed with bug 1665203 and is therefore a duplicate?

Per bug 1714586 the Calendar component overall does not work, so I cannot test if this has been fixed.

It seems that TB 91.0a1 does it right.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE

TB91-release does not make HTTP calls, during calendars setup, to find the ACL. In turn it does not mark as READ-ONLY calendars, which are READ-ONLY. This is a regression.

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Lasana, can you check this?

Flags: needinfo?(lasana)
Assignee: nobody → lasana
Flags: needinfo?(lasana)
Status: REOPENED → ASSIGNED
Target Milestone: --- → 93 Branch

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/81e03162ca75
Detect read-only acl privs for C:calendar-home-set. r=darktrojan

Status: ASSIGNED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → FIXED

Please request 91 uplift.

Comment on attachment 9237774 [details]
Bug 1670416 - Detect read-only acl privs for C:calendar-home-set. r=darktrojan

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined: Some caldav calendars will not be marked as read-only resulting in an error if the user tries to write to them.
Testing completed (on c-c, etc.): trunk
Risk to taking this patch (and alternatives if risky): Should not be too much, just an addition to the properties requested.

Attachment #9237774 - Flags: approval-comm-esr91?

Comment on attachment 9237774 [details]
Bug 1670416 - Detect read-only acl privs for C:calendar-home-set. r=darktrojan

[Triage Comment]
Approved for esr91

Attachment #9237774 - Flags: approval-comm-esr91? → approval-comm-esr91+

To my knowledge, TB91 cannot manage (create, delete, edit) the calendars theirselves, it can only create, delete edit events in existing calendar. For the read-only detection it is therefore only significant, if the calendar-URL is read-only. Why does the change title state, that the acl privs on the calendar-home-set are checked?

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: