1217505 - CALDAV owner isn't shown as event organizer with a read-write subscribed calendar

Status: UNCONFIRMED

(Calendar :: Provider: CalDAV, defect)

Description

[diesmo]

Attachment: Proposed patch for calDavCalendar.patch

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

Steps to reproduce:

Subscribe to a calendar for which you have read-write access (e.g my boss).

Create an event, and open the attendees dialog.

Look at the first attendee, which happens to be the organizer.


Actual results:

The organizer is me


Expected results:

The organizer should be my boss which is the owner of the calendar, i 'm just setting the meeting for him, i do not want to attend it.

The problem seems to be in components/calDavCalendar.js, line 1812.

When computing the calendar principal to use, the code retrieves the current user, or the calendar owner.

if (cuprincipal) {
                thisCalendar.mPrincipalUrl = cuprincipal;
                cal.LOG("CalDAV: Found principal url from DAV:current-user-principal " + thisCalendar.mPrincipalUrl);
            } else  if (owner) {
                thisCalendar.mPrincipalUrl = owner;
                cal.LOG("CalDAV: Found principal url from DAV:owner " + thisCalendar.mPrincipalUrl);
            } 

It should retrieve the calendar owner, and only if it does not exists, fallback to current principal.

if (owner) {
                thisCalendar.mPrincipalUrl = owner;
                cal.LOG("CalDAV: Found principal url from DAV:owner " + thisCalendar.mPrincipalUrl);
            } else if (cuprincipal) {
                thisCalendar.mPrincipalUrl = cuprincipal;
                cal.LOG("CalDAV: Found principal url from DAV:current-user-principal " + thisCalendar.mPrincipalUrl);
            }

Comment 1

[Philipp Kewisch [:Fallen][☁️📆]]

Comment on attachment 8677569 [details] [diff] [review]
Proposed patch for calDavCalendar.patch

Review of attachment 8677569 [details] [diff] [review]:
-----------------------------------------------------------------

Preferring DAV:owner over current-user-principal would mean you can pretty much remove the code that checks for current-user-principal, since all servers support DAV:owner, but not all servers support current-user-principal.

That said, I don't think we should unconditionally use the owner. While this might fix the case for delegated calendars, it will break group calendars. See bug 787780 for where the patch landed. Note also, that if you are creating the event in your manager's calendar you have still organized the event. The manager may be the chair and attendee, but since you created it you are organizing it.

I'm all for making things more configurable, but delegation support in Lightning is very basic at the moment and I'd prefer to have a complete solution instead of adding a specific change that only fixes one case but may break others.


Moving forward, it would be helpful to revise the organizer identity selection. Right now the organizer is actually the configured organizer in the calendar dialog. It should be possible to have multiple identities and they should default to the email addresses in the calendar user address set. With this in place we could allow selecting calendar owner identities, current user identities, and also the available email identities.


As a stopgap measure, can you try adding your manager's email address as an identity to your email account? Alternatively you can also use his identity if you have added his account. Note that email invitation will then be sent with the manager's identity.

Comment 2

[diesmo]

Hello,

I found an example here : https://tools.ietf.org/html/rfc5545#page-113

-------------------------------------------------------------------
The following is an example of this property used by another
 calendar user who is acting on behalf of the organizer, with
 responses intended to be sent back to the organizer, not the other
 calendar user:

 ORGANIZER;SENT-BY="mailto:[e-mail]":
   mailto:[e-mail]
-------------------------------------------------------------------

This illustrates our usecase (i'm acting on behalf of my boss).

my guess is that we need to identify the type of the calendar being used (calendar-user-type) : INDIVIDUAL, GROUP, RESOURCE

if the current calendar is GROUP or RESOURCE, the ORGANIZER should never be the group or the resource, as this makes no sense. the group or resource can only be an attendee. 
if the current calendar is INDIVIDUAL, then our usecase applies.

Maybe the correct behaviour is :
 - if calendar type is INDIVIDUAL, ORGANIZER = owner (or defaults to authenticated user), and add a SENT-BY= authenticated user's email (defaults to current-user-principal, email and current-principal might differ, though)
 - otherwise (GROUP, RESOURCE, ...), ORGANIZER = current-user

Any advice on this ?

Comment 3

[diesmo]

Attachment: fix-organizer-for-delegated-calendar.patch

If the current calendar is of type INDIVIDUAL  and owner is available, use :
 - owner as organizer
 - authenticated user's scheduling outbox

Otherwise (GROUP calendar for instance), keep using authenticated user as organizer.

The scheduling outbox part is discussed in bug 428035.

Comment 4

[Philipp Kewisch [:Fallen][☁️📆]]

Comment on attachment 8770708 [details] [diff] [review]
fix-organizer-for-delegated-calendar.patch

Review of attachment 8770708 [details] [diff] [review]:
-----------------------------------------------------------------

Unfortuantely I'm not sure how to proceed here, removing myself from review.