448553 - Can't configure calendar with an email address for which no email account is configured

Status: RESOLVED WORKSFORME

(Calendar :: General, defect)

Description

[Bernard Desruisseaux]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Build Identifier: Lightning/0.9pre (build 2008072818)

The email address specified in the configuration of a calendar is used by Lightning to figure if one is the organizer of an event, or simply an attendee. When Lightning figures the user is only an Attendee, Lightning will prevent the user to change anything except his participation status as well as the reminders.

In delegation scenarios (Mary configures Bob's calendar for which she has write access to) this doesn't work well.  Mary has actually no way of specifying Bob's email address when she configures Bob's calendar unless she also configured an email account for Bob as well.

Reproducible: Always

Steps to Reproduce:
1. Create new calendar to access someone else's calendar.
2. Notice that you can't specify that person's email address unless you happen to have an email account configured with that person's email address.
Actual Results:  
The calendar configured to access someone else's calendar is configured with no email address (i.e., None) or the wrong email address and Lightning will not figure out whether the calendar owner is the organizer of a meeting or not properly. As such, the user will not be able to accept or decline meeting invitations on behalf of the calendar owner.

Expected Results:  
Lightning should allow users to specify email addresses for which no email account is configured, or better yet, in the case of CalDAV, automatically figure out the email address(es) of the calendar owner from the CALDAV:calendar-user-address-set property defined on the principal resource of the calendar owner.

As a workaround one can create a dummy email account configured with the email address of the other user.

Comment 1

[Daniel Boelzle [:dbo]]

The detection whether an item is an invitation copy or not is not necessarily bound to the configured email address internally. Providers like caldav certainly should use the calendar user address to test that (and IIRC we do that in the caldav sched patch).
The email address configuration primarily serves for choosing a valid account for sending out iMIP. It's not targeting towards delegation support, but solves some of the issues we had with mailing list invitations. I think we need more UI/prefs to support delegation.

Comment 2

[Bernard Desruisseaux]

The behavior I observed was most likely due to:

https://bugzilla.mozilla.org/show_bug.cgi?id=454998#c4

> Cause: We didn't query for the principal ns and outbox etc in case scheduling
> has been disabled.

Since this issue has been resolved (or so I think!) it doesn't matter anymore which email address is configured to get the delegation scenario described above to work.

This bug can probably be closed.

Comment 3

[Daniel Boelzle [:dbo]]

Resoling WFM per comment #2.