Closed Bug 1273793 Opened 8 years ago Closed 3 years ago

added calendars could be set with "read only option" accordingly to its real permissions

Categories

(Calendar :: Internal Components, enhancement, P2)

Lightning 4.7
enhancement

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1665203

People

(Reporter: ldu.linagora, Unassigned, Mentored)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160502160818

Steps to reproduce:

On a Caldav server (reproduced with Oracle Convergence Communication), userA has read only permissions on userB calendar and don't display it.

1. UserA adds a remote calendar and fills the url field with the userB caldav URL
2. UserB calendar is added


Actual results:

UserB calendar is added but it's not set with the read only option. So there is no padlock icon and userA feels as he can create events on this calendar: it is possible to begin a drag and drop or to select this calendar in the event creation dialog.

With Lightning 3.3.3, it was the opposite: every calendars were added with the read only option, even those with write permission. The user had to un-check the option in the calendar properties to be able to create events on it. 

When userA tries to really validate an event in userB calendar, the permission is denied (so it's OK)


Expected results:

The added calendars could be set with "read only option" accordingly to its real permissions.

Also about the behavior of Lightning 3.3.3 (read only option for every added calendar) , one of my customer says this is a courtesy behavior and is OK with that.
This seems to be an enhancement request :
 - When subscribing to a calendar, lightning could retrieve current-user-privileges and set the calendar in read-only if privileges do not allow write.

Current behaviour is that the user has to manually set the calendar in read-only.
Confirming this as an enhancement. When implementing, we should consider integrating the ACL interfaces in the code better, this way we could present this independent of the caldav provider. The Provider for Google Calendar does this already manually.

This could also be fixed in the caldav provider to retrieve the current-user-privileges and change the calendar to readonly
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Component: Calendar Views → Internal Components
Ever confirmed: true
The fix in the caldav provider qualifies as a good first bug. I'm happy to mentor anyone wanting to fix this.
Mentor: philipp
Keywords: good-first-bug
Hi
    Is this still open. I want to take this one.
Hi, this bug is still open. It requires some understanding (or reading) of https://tools.ietf.org/html/rfc4791 on how to do a current-user-privileges query, and needs to be integrated with the detection code in https://dxr.mozilla.org/comm-central/source/calendar/providers/caldav/calDavCalendar.js

Let me know if you want to work on this, we should chat on IRC if you are available.
Hi, I am sorry. But I taken up a few other issues, and so working on them. I wont be able to work on fix anytime soon. If anyone else is willing to contribute. Go ahead please!
Hey Philipp
I would like to take this as my first bug.
I shall go through the reading and work on this. I would be glad if you mentor me for the same.

Regards
Indranil
Hi Indranil, I'm happy to help you on this issue. Comment 5 is a start, if you need more help please contact me!
Assignee: nobody → indraniltiwary
Status: NEW → ASSIGNED
Assignee: indraniltiwary → nobody
Status: ASSIGNED → NEW
Summary: A calendar in read only mode is not set as read only option when a user subscribes to it → added calendars could be set with "read only option" accordingly to its real permissions
Assignee: nobody → nobody

Is this ticket still open? My team for a university course wants to work on this as one of our first bugs.

This should be low hanging fruit indeed, a fix was very much welcome (a user speaking)

Probably a good start for the protocol side is https://stackoverflow.com/questions/57116267/determine-access-rights-for-caldav-calendars - in wireshark I see, that lightning currently does not request "current-user-privilege-set" when doing a PROPFIND

Some intricacies on client side may be, how to handle user overrides, e.g. the server permits writing but the user deliberately sets to read-only? I'd go for the lightning checking on each start-up and unconditionally un/checking the read-only padlock depending on the server granted perms.

Go for it!

Priority: -- → P2

This got fixed for CalDAV in bug 1665203. Continuing with others in bug 1715756.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.