431522 - Can't add an invitation to an event if the same event is already in one of your calendars

Status: VERIFIED FIXED

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

Description

[Olivier Migeot]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: 2008033120

This sounds quite logical, but it becomes annoying when you use to read your colleagues' calendars.

For example, I'm having to (remote webdav) calendars in TB/Lightning: Mine (RW, showing alarms and displayed) and my Boss' (RO, not showing alarms and hidden most of the time). This way, I can quickly check my boss' events, but they don't come into my way. My boss has the opposite setup on his Lightning.

The problem arise when my boss sends me an invitation : he creates an event, adds me as an attendee and sends the invitation. When I receive it, I can't accept or refuse it because "That message contains an event that is already in your calendar" (hand-made translation from French locale). Of course I have it, since my boss calendar is in my calendars list.

I don't remember I add the problem on previous versions of Lightning nor on Sunbird.

I'm note sure what is the better way to deal with this, but since accepted invitations seem to go the first calendar by default, the existence of the event should only be checked upon that same calendar.

Reproducible: Always

Steps to Reproduce:
1.Add two remote calendars (CA & CB) to user A.
2.Add CB & CA to user B.
3.Create an event through user A on CA, and invite user B to it.
4.Through user B, try to accept the afforementioned invitation. You can't.
Actual Results:  
You can't add the event because "it is already in your calendar"

Expected Results:  
It should add until it's already in the same calendar you want/need to add it.

Comment 1

[Daniel Boelzle [:dbo]]

Confirming. IMO we need some UI to better specify what calendars are owned/managed/act as landing zones for invitations (don't nail me on the right term) in contrast to what calendars are subscribed for simple reading purposes. Only that set of calendars needs to be taken into account when processing iTIP.

Comment 2

[Olivier Migeot]

Maybe we should just allow to link calendars to e-mail identities (in Lightning only, I guess).

Comment 3

[Daniel Boelzle [:dbo]]

With the patch for bug 421886 I've changed detection to only take writable calendars into account. So if you mark the organizer's calendar as "read-only", you shouldn't have a problem anymore.

Comment 4

[Ryan Steele]

(In reply to comment #3)
> With the patch for bug 421886 I've changed detection to only take writable
> calendars into account. So if you mark the organizer's calendar as "read-only",
> you shouldn't have a problem anymore.
> 

Consider this situation:  There is a conference room calendar to which anybody in an organization may add events.  If there's no event scheduled in a particular time slot, any user is free to book the conference room.  Suppose I organize the event (so, [e-mail] is the organizer), and add it to the conference room calendar.  If I add myself to the invitees list to which the iTip requests are sent, I can't use the proposed 'workaround', because I need to add the invitation to my personal calendar as well.  The behavior, then, is that I get an iTip event for which the only way to add the event is drag the .ics attachment to the Calendar button.  The suggestion by Olivier Migeot sounds like a feasible solution to this, though. E.g., if Lightning doesn't find the event on a calendar for which a corresponding email identity exists in T-Bird, give the user the option to Accept or Decline.  Does this sound like a good approach to the problem?

Comment 5

[Daniel Boelzle [:dbo]]

Ryan, I am wondering why you add yourself to the attendees list, because you're already stated to be the organizer. Organizer's could accept to participate (PARTSTAT=ACCEPTED, although I think we're still lacking UI for that).

Comment 6

[Ryan Steele]

(In reply to comment #5)
> Ryan, I am wondering why you add yourself to the attendees list, because you're
> already stated to be the organizer. Organizer's could accept to participate
> (PARTSTAT=ACCEPTED, although I think we're still lacking UI for that).
> 

Hi Daniel,

It's because I'm adding the event to the conference room calendar so that others know the conference room is booked at that time.  But, I don't want people to have to check the conference room calendar AND my own calendar to see if I'm busy at that time - I just want them to be able to look at my calendar and see that event.  Does that make sense?

Comment 7

[Daniel Boelzle [:dbo]]

(Assuming If I get your scheme of scheduling for a resource right)
I think it makes more sense to create a virtual user for the resource and invite that to meetings, instead of allowing everybody to write into that shared calendar. I think you shouldn't have a problem then.

Comment 8

[Ryan Steele]

I'm not sure that really solves the problem.  If the virtual user creates the event in the conference room, it would still have to send invitations to the invitees.  If an individual is subscribed to the conference room calendar so they can see the events on it, they're not going to be able to accept/decline that invitation to those events for their personal calendar.  They'll be forced to drag and drop the .ics attachment. I really think Oliver's suggestion is the most elegant way to handle this, but I'm happy to be given a reason why that's not the case.

Comment 9

[Daniel Boelzle [:dbo]]

The virtual (resource) user wouldn't send invitations, but is only invited. Someone needs to act on its behalf, i.e. accept/decline invitations, essentially managing the resource. By accepting an invitation, those will be placed into the shared resource calendar and provide freebusy information for the booked resource.
I think this is the common way it's done in shared calendaring, e.g. a secretary manages a resource's calendar.

I am not sure whether linking email addresses to calendars is the way to go; what if you link one email address to multiple calendars?

Comment 10

[Ryan Steele]

(In reply to comment #9)
> The virtual (resource) user wouldn't send invitations, but is only invited.
> Someone needs to act on its behalf, i.e. accept/decline invitations,
> essentially managing the resource. By accepting an invitation, those will be
> placed into the shared resource calendar and provide freebusy information for
> the booked resource.
> I think this is the common way it's done in shared calendaring, e.g. a
> secretary manages a resource's calendar.

This seems like it's just adding more hoops to jump through.  We were doing as you suggested, but our secretary left on medical leave for a month, so that's just an extra contingency.  Even if the user scheduling event invites the conference room virtual user, they would have to log in again as that user to accept the invitation.  The goal (in my mind) is convenience.  A user should be able to create a conference room event on that calendar, and send an invitation to all attendees, themselves included.

> 
> I am not sure whether linking email addresses to calendars is the way to go;
> what if you link one email address to multiple calendars?
> 

Perhaps then, it only prompts for the invitation to be added on the calendars associated with that email for which the event does not exist.

Comment 11

[u186330]

(In reply to comment #10)
> A user should be able to create a conference room event on that calendar, and 
> send an invitation to all attendees, themselves included.

FWIW, Sun's Java calendaring system does the opposite. You create an event in your calendar, and invite both people and resources (rooms). Resources, as opposed to people, just accept all invitations automatically (if there's no conflict of course). This is IMHO the most intuitive approach. If you need more than one resource for the same meeting (e.g. a room, a projector and a video link to another continent), it's probably the only sane one.

I don't know whether it can be implemented entirely on the client side, or one needs to plug into the calendaring server.

Comment 12

[Bas van den Bosch]

This is a logical thing indeed. But this only works with wcap or perhaps some caldav servers, there's no sane way to do this in webdav (where would you sent the email to?). I think Ryans usecase in comment 6 is valid and Oliver Migeut proposal in comment 2 is too. I read both my email from work and my private email in TB when I'm at home and use multiple calendars too. When I create an event, there's no way of telling under which idenity I created the event. This would be solved when I'm able to denote none, one or more identities to the calendar. If none, I could use it for the conference-room (or create an identity "conference-room" and use it to book the room and then invite myself to it). 

Comment 13

[u186330]

(In reply to comment #12)
Your proposal still doesn't make it possible to invite more than one resource to the same event. 

For webdav calendars, one could associate a mailbox with each resource, and use a perl script to manage invitations. That would work today, but it's not an out-of-box solution, you need someone to implement it.

For the future, Sunbird could be changed to do it client-side if the calendar in question is known to belong to a resource. I *think* it's possible, but not too sure. You would create an event as yourself, not as a made-up resource identity. For people participants, you send out e-mail invitations as usual; but for resources, the client just modifies the calendars directly, *as if* an invitation was sent and accepted.

Comment 14

[Daniel Boelzle [:dbo]]

Attachment: WIP patch - v1

Although this is just a work in progress patch, I am requesting UI review for adding a mail account drop down box to both
- the calendar creation wizard
- the calendar properties dialog

After all I think specifying an email account to be used for scheduling per calendar is the best approach, because we could fix
- this bug
- bug 428274 adding an attendee for the configured email identity, sending a REPLY (this is valid per RFC2446)
- bug 432660

Comment 15

[Bas van den Bosch]

> FWIW, Sun's Java calendaring system does the opposite. You create an event in
> your calendar, and invite both people and resources (rooms). 

Daniel, would your patch work with the sun calendar server or do you need to put a calendar-type of "resource" in the dropdown-list of emailadresses too? 

You leave the possibility of not assigning an emailaccount to a calendar, are the calendars which don't have an emailaccount treated as a resource and thus (I think) are they shown in the freebusy-grid automatically when inviting attendees? 

As in a short while the string-freeze will be set, I hope you get the ui-part through in time, perhaps you already have a screenshot for Christian to make life easier for him?

Thanks for bug 423660 btw :-)

Comment 16

[Bas van den Bosch]

should be bug 432660 of course. 

One last question comes to mind: Will I be able to specify multiple emailaccounts in the dropdown? We don't support delegation yet (and will not support this on branch since branch will be obsolete after 0.9). Of course I could accept an invitation in my personal calendar and then change the invite to my work-calendar but it would be nice to be able to choose from calendars when reeiving aan invite.

Comment 17

[Daniel Boelzle [:dbo]]

(In reply to comment #15)
> > FWIW, Sun's Java calendaring system does the opposite. You create an event in
> > your calendar, and invite both people and resources (rooms). 
> 
> Daniel, would your patch work with the sun calendar server or do you need to
> put a calendar-type of "resource" in the dropdown-list of emailadresses too? 
It adds an option for outbound iTIP-based calendars (e.g. storage, ics) to choose an email account being used for sending requests etc. The default identity of that account is used as the organizer for new events, and it could be used to send a REPLY on mailing list invitations (where the correct attendee could not be determined). Deliberately adding an attendee for those REPLies is valid due to RFC 2446; the organizer is free to deny the REPLY when receiving it.

> You leave the possibility of not assigning an emailaccount to a calendar, are
> the calendars which don't have an emailaccount treated as a resource and thus
> (I think) are they shown in the freebusy-grid automatically when inviting
> attendees? 
The default account is used (per default). If it's not set, any account is taken. However, if no account is specified at all, we need to disable iTIP scheduling; I'll take care of that, thanks.

> As in a short while the string-freeze will be set, I hope you get the ui-part
> through in time, perhaps you already have a screenshot for Christian to make
> life easier for him?
I just helped him to repair his build env, he ought to be able to apply and test patches again.

(In reply to comment #16)
> One last question comes to mind: Will I be able to specify multiple
> emailaccounts in the dropdown? We don't support delegation yet (and will not
> support this on branch since branch will be obsolete after 0.9). Of course I
> could accept an invitation in my personal calendar and then change the invite
> to my work-calendar but it would be nice to be able to choose from calendars
> when reeiving aan invite.
You could already choose into what calendar the invitation copy should be placed (assuming you have multiple calendars) when receiving an invitation. 
But no, (at least for now) you can only tiee one account to a calendar and that email account will be used for sending out REPLYs, or sending REQUESTs.

Comment 18

[Christian Jansen]

Comment on attachment 328752 [details] [diff] [review]
WIP patch - v1

Looks good for me. ui=christian.

Comment 19

[Daniel Boelzle [:dbo]]

Attachment: [checked in] just the string for upcoming string freeze

Comment 20

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I took a short look at the patch. Do you really want the user to select the account? I would assume its more useful to let the user select any *identity* from any account, otherwise you can only use the default identity of the account to send messages?

Comment 21

[Daniel Boelzle [:dbo]]

(In reply to comment #20)
I initially thought about that, too, but opted for this solution for the sake of simplicity. Just curious: I've talked about that UI to Christian and the first question he raised was "You hopefully don't offer all 27 identities, most referring to the same email addresses, don't you?".

Comment 22

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Do they really mostly refer to the same email? I have two accounts, one with my domain which has several different identities I could all imagine that I'd like to send invitations for, i.e mozilla at kewis ch connected to a team calendar, uni at kewis ch connected to a university calendar, and so on. Thunderbird also offers all identities in the picker for the identity in the compose message dialog.

Comment 23

[Daniel Boelzle [:dbo]]

Attachment: WIP patch - v2

After all I agree it makes sense to display all identities:
- added option "None"
- now displaying all identities
=> rerequesting UI-review

Comment 24

[Christian Jansen]

Comment on attachment 329338 [details] [diff] [review]
WIP patch - v2

ui=christian

Comment 25

[Daniel Boelzle [:dbo]]

strings checked in; r-over-the-shoulder=philipp

Comment 26

[Daniel Boelzle [:dbo]]

Attachment: patch - v1

Comment 27

[Daniel Boelzle [:dbo]]

Attachment: patch - v2

This patch adds the possibility to configure an email identity (or none) for a calendar, both calendar creation wizard and properties page. This is useful in various ways:
- we could determine a proper ORGANIZER for REQUESTs (and show it in the attendees dialog)
- we could determine what attendee is going to REPLY
- we could better determine the target calendar for incoming REQUESTs
- Even though a calendar's identity is not directly listed in the attendees list, we could REPLY on such REQUESTs (bug 428274).
- we could determine what account to take for sending out REQUESTs (bug 432660)

Moreover, the patch
- adds a pref for sending out invitations (bug 441528)
- fixes bug 445299
- consolidates some of the item editing code
- fixes to send out proper CANCEL mails only for removed attendees
- the read-only-summary dialog is now correctly raised for iTIP/iMIP invitation copies, you can REPLY from within the views
- fixed calItipItem::clone
- adds the identity to the calendar chooser dialog (more UI tweaking needed though)
- removes calICalendar::sendItipInvitations, adds more fine-grained calISchedulingSupport::canNotify(method, item) instead
- adds calIAttendee::toString()
- changed iMIP DECLINED items, so users could still decide to attend later on (or finally delete the item)
- fixes provider's to only pass back undecided invitations on ITEM_FILTER_REQUEST_NEEDS_ACTION (instead of all): memory/storage
- implements a workaround for bug 416975 in invitation manager

Comment 28

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 329813 [details] [diff] [review]
patch - v2

> opCompleteListener.prototype = {
Since you moved the opCompleteListener call to calTransaction, shouldn't you also move the prototype there?

> 
>+                var identity = cal.getProperty("imip.identity");
>+                if (identity !== null) {
>+                    identity = identity.QueryInterface(Components.interfaces.nsIMsgIdentity);
>+                    var idCell = document.createElement("listcell");
>+                    idCell.setAttribute("label", identity.identityName);
>+                    listItem.appendChild(idCell);
>+                }
>+
This means the email will also show for the import dialog, maybe you want to pass a window argument.
>+    toString: function calAttendee_toString() {
>+        var ret = (this.id || "unknown");
>+        if (ret.match(/mailto:/i)) {
>+            ret = ret.substring("MAILTO:".length);
>+        }
var ret = (this.id || "unknown").replace(/^mailto:/i, "");


>+/* Shortcut to the account manager service */
>+function getAccountManager() {
>+    if (getAccountManager.mObject === undefined) {
>+        getAccountManager.mObject = Components.classes["@mozilla.org/messenger/account-manager;1"]
>+                                              .getService(Components.interfaces.nsIMsgAccountManager);
>+    }
>+    return getAccountManager.mObject;
>+}
This function might be better kept in lightning/content/lightning-utils.js


>+        itipItem.setAttendeeStatus(att.id, att.participationStatus);
>+        var myPartStat = att.participationStatus;
>+        var name = att.toString();
>+        LOG(name + ": PARTSTAT=" + myPartStat);
Is the LOG() needed here?
> 
>-          // set 'mIsReadOnly' if the calendar is read-only
>-          if (calendar && calendar.readOnly) {
>-              this.mIsReadOnly = true;
>-          }
>+          this.mIsReadOnly = calendar.readOnly;
isCalendarWritable() ?

>+    canNotify: function cGC_canNotify(aMethod, aItem) {
>+        // XXX needs further refinement
>+        switch (aMethod) {
>+            case "REQUEST":
>+            case "CANCEL":
>+            case "REPLY":
        return (aItem.organizer.id.toLowerCase() ==
                "mailto:" + this.session.userName.toLowerCase());

should do it

>+            default:
>+                return false;
>+        }
>     }
> };


r=philipp

Comment 29

[Daniel Boelzle [:dbo]]

(In reply to comment #28)
> (From update of attachment 329813 [details] [diff] [review])
> > opCompleteListener.prototype = {
> Since you moved the opCompleteListener call to calTransaction, shouldn't you
> also move the prototype there?
IMO a matter of taste.

identity.QueryInterface(Components.interfaces.nsIMsgIdentity);
> >+                    var idCell = document.createElement("listcell");
> >+                    idCell.setAttribute("label", identity.identityName);
> >+                    listItem.appendChild(idCell);
> >+                }
> >+
> This means the email will also show for the import dialog, maybe you want to
> pass a window argument.
for what purpose? suppressing the email addresses?

> >+    toString: function calAttendee_toString() {
> >+        var ret = (this.id || "unknown");
> >+        if (ret.match(/mailto:/i)) {
> >+            ret = ret.substring("MAILTO:".length);
> >+        }
> var ret = (this.id || "unknown").replace(/^mailto:/i, "");
done

> >+/* Shortcut to the account manager service */
> >+function getAccountManager() {
> >+    if (getAccountManager.mObject === undefined) {
> >+        getAccountManager.mObject = Components.classes["@mozilla.org/messenger/account-manager;1"]
> >+                                              .getService(Components.interfaces.nsIMsgAccountManager);
> >+    }
> >+    return getAccountManager.mObject;
> >+}
> This function might be better kept in lightning/content/lightning-utils.js
This would require the base components to include it; I doubt we want that.

> >+        itipItem.setAttendeeStatus(att.id, att.participationStatus);
> >+        var myPartStat = att.participationStatus;
> >+        var name = att.toString();
> >+        LOG(name + ": PARTSTAT=" + myPartStat);
> Is the LOG() needed here?
no, removed

> >-          // set 'mIsReadOnly' if the calendar is read-only
> >-          if (calendar && calendar.readOnly) {
> >-              this.mIsReadOnly = true;
> >-          }
> >+          this.mIsReadOnly = calendar.readOnly;
> isCalendarWritable() ?
I am not quite comfortable with what's going on in that code, so I left it as is (my changes just make the code more slim, but doesn't change behaviour).

> >+    canNotify: function cGC_canNotify(aMethod, aItem) {
> >+        // XXX needs further refinement
> >+        switch (aMethod) {
> >+            case "REQUEST":
> >+            case "CANCEL":
> >+            case "REPLY":
>         return (aItem.organizer.id.toLowerCase() ==
>                 "mailto:" + this.session.userName.toLowerCase());
> 
> should do it
That would mean you want client iMIP on REPLY?


Checked in on HEAD and MOZILLA_1_8_BRANCH => FIXED.

Comment 30

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

(In reply to comment #29)
> > This means the email will also show for the import dialog, maybe you want to
> > pass a window argument.
> for what purpose? suppressing the email addresses?
Yes, or rather showing the email addresses. I don't think the import calendar dialog needs those email addresses.


> > >+function getAccountManager() {
> > This function might be better kept in lightning/content/lightning-utils.js
> This would require the base components to include it; I doubt we want that.
So we have things in base that require the Thunderbird account manager? Unless its totally unreasonable, I think those things should live in lightning/ I guess something tbd in a followup bug.

> 
> > >+    canNotify: function cGC_canNotify(aMethod, aItem) {
> > >+        // XXX needs further refinement
> > >+        switch (aMethod) {
> > >+            case "REQUEST":
> > >+            case "CANCEL":
> > >+            case "REPLY":
> >         return (aItem.organizer.id.toLowerCase() ==
> >                 "mailto:" + this.session.userName.toLowerCase());
> > 
> > should do it
> That would mean you want client iMIP on REPLY?
actually, the switch statement is probably not needed at all. client iMIP should always be used when you are not the organizer, since you can't modify items of other Google users by default. Does this sound reasonable?

Comment 31

[Daniel Boelzle [:dbo]]

(In reply to comment #30)
> (In reply to comment #29)
> > > This means the email will also show for the import dialog, maybe you want to
> > > pass a window argument.
> > for what purpose? suppressing the email addresses?
> Yes, or rather showing the email addresses. I don't think the import calendar
> dialog needs those email addresses.
I think that's obsolete; Christian thinks it's information overload to show the email addresses and wants them to be removed.

> > > >+function getAccountManager() {
> > > This function might be better kept in lightning/content/lightning-utils.js
> > This would require the base components to include it; I doubt we want that.
> So we have things in base that require the Thunderbird account manager? Unless
> its totally unreasonable, I think those things should live in lightning/ I
> guess something tbd in a followup bug.
Yes, we've code that deals with iTIP/iMIP processing in base. I think that's OK, if guarded with !isSunbird(). It's preferred that we seperate that code into components etc, but some places aren't worth to do that IMO.

> > > >+    canNotify: function cGC_canNotify(aMethod, aItem) {
> > > >+        // XXX needs further refinement
> > > >+        switch (aMethod) {
> > > >+            case "REQUEST":
> > > >+            case "CANCEL":
> > > >+            case "REPLY":
> > >         return (aItem.organizer.id.toLowerCase() ==
> > >                 "mailto:" + this.session.userName.toLowerCase());
> > > 
> > > should do it
> > That would mean you want client iMIP on REPLY?
> actually, the switch statement is probably not needed at all. client iMIP
> should always be used when you are not the organizer, since you can't modify
> items of other Google users by default. Does this sound reasonable?
I.e. if I change the PARTSTAT of an invitation via modifyItem, google will not keep care of sending out an iMIP REPLY message? Please fix that code in a follow-up gdata bug.

Comment 32

[Daniel Boelzle [:dbo]]

Attachment: [checked in] remove email adresses from calendar chooser

Comment 33

[Andreas Treumann]

Checked in nightly build 2008072219 -> VERIFIED