Closed Bug 377403 Opened 14 years ago Closed 13 years ago

[Proto] Event dialog: iTIP Invitations not sent

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: cmtalbert, Assigned: michael.buettner)

Details

Attachments

(3 files, 2 obsolete files)

When using the prototype event dialog, no compose window is launched once you add attendees to the event and close the window.

== Steps to Reproduce ==
1. Create an event with the prototype event dialog
2. Add attendees
3. Click OK on attendees pane
4. Click "Save and Close"
5. Event is created, but no compose window is opened to send email to the selected attendees

== Actual ==
No compose window opens, you have no way to invite these people to the event

== Expected ==
We should open the compose window in the same way that the old dialog does, and we should also NOT open the dialog for calendars that are using the WCAP or Google providers since those use different invitation management systems

== Other Information ==
The logic that does the "open compose window to send an invitation" is actually in the "on new/modify event" callbacks in calendar-item-editing.js

Here is one example of the callbacks:
http://lxr.mozilla.org/mozilla1.8/source/calendar/base/content/calendar-item-editing.js#49

As you can see, it calls checkForAttendees: http://lxr.mozilla.org/mozilla1.8/source/calendar/base/content/calendar-item-editing.js#335

The Attendee sending logic does need to be more formalized than its current incarnation.  For some mistaken reason, I thought that putting the attendee handling items into the event dialog callbacks would enable attendee handling for both attendee dialogs, but that obviously did not work.  I think as part of the formalization of our invitation management and attendee management, we will correct this problem.
The Prototype Event Dialog uses exactly the same callbacks as the standard dialog does. I assumed that there's some magic happening with the checkbox you recently added to the standard dialog and that this is why it somehow doesn't work with the prototype dialog. I just had a look on checkForAttendees() in calendar-item-editing.js and found that you're using an X-MOZ-SEND-INVITATIONS to decide whether or not invitations should be send by mail or not, [1]. Events created/modified with the prototype dialog don't have this property.

For now, I only see the solution to add the checkbox to the prototype dialog as well. Christian, any comment on this? Do you have a clever alternative?

[1] http://lxr.mozilla.org/seamonkey/source/calendar/base/content/calendar-item-editing.js#348
(In reply to comment #1)
Mickey, that's got to be it.  I was kicking myself for not catching this in my earlier testing, but I'd forgotten about that new checkbox functionality.

Flags: blocking-calendar0.7?
I know that you're all busy but I'd like to say that some of us nightly testers are waiting for this bugfix so that we can test and begin using iMIP with the prototype event dialog.  If the new dialog will be in 0.7, then perhaps early testing of its iMIP functionality would be a good idea.  It seems that the bug is "stuck" waiting for Christian's approval, so I've taken the liberty of CCing him.

I've been happily using many of the other features of the prototype event dialog for several months.  Thanks for that.
Flags: blocking-calendar0.7? → blocking-calendar0.7+
Thanks's for CCing me ;-)
I have to admit that I would not expect the Compose Window after closing the event dialog. I would would expect a modified version of the "Send Message" dialog, which pops-up to inform users about the progress of sending out the invitation. 

Instead of "Sending Message - XYZ" the dialog should say "Sending Invitation - Event Request: ABC".

Displaying the Compose Window would make the work flow of inviting peoples unnecessary complex.
(In reply to comment #4)
> Displaying the Compose Window would make the work flow of inviting peoples
> unnecessary complex.
But gets me another level of safety before spamming people ;)
In addition to the safety factor, another reason is that it's sometimes nice to type a little explanation to the attendees (1) when you create an event or (2) when you edit parts of an event and re-send the invitation or (3) when you delete an event and want to explain why.  In other words, it's a way of describing things about an event in a personal way; things that don't belong in the event's Description Field.  Of course you can send a second email to achieve this, but then you have to re-type the names of the attendees and you hope that everyone reads the extra email before they receive the meeting invitation.

Another advantage of using the composition window is that you can choose from which Thunderbird identity/account you want to send the invitation (unless this preference is eventually added to the properties of each calendar so that it's automatic).

There might be better ways to do these things than with a regular composition window, and perhaps opening the composition window could be optional on a case-by-case basis.

One suggestion that I would like to make is, if a checkbox is used in the prototype event dialog like it is in the old one, I would prefer that all such checkboxes are in the main dialog rather than in the 'invite attendees' child dialog.  This would avoid the need to open the child dialog in order to see or change the status of the checkboxes.  Or perhaps there is a better way to do all of this than with checkboxes.
I can see valid use-cases for both work-flows. An alternative way to handle this would be to show a small confirmation dialog when you save an event that contains attendees (and is not a calendar that handles invitations on the through the server):
-----------------------------------------------
|    Do you want to edit the event invitation |
|    before sending it?                       |
|                                             |
|         [YES]           [NO]                |
|    [] Do this automatically next time       |
-----------------------------------------------
I like the idea of having an option. But I would find it somehow distracting being ask all time, if I want to edit or not. I also have a problem with the "[ ] Do this automatically next time" option. It is unclear and users would not know how to turn the dialog on again. Once the check box has been marked. Therefore another option would be needed.

I agree to Pete that it would make sense to offer the option directly in event dialog. From my point of view there a two possible places for the option.

1. Directly under the Attendees List in the "main" event dialog
   The option should only be visible if Attendees have been added. 

   | Category:   [None     \/]    Calendar  [Private   \/]
   | Attendees:  joe.user@example.com
   |             [ ] Edit invitation email before sending

2. In the Options menu of the Event dialog

Maybe we also want to rename "Save and Close" to "Send and Close" if attendees have been added.
> 1. Directly under the Attendees List in the "main" event dialog.

I like that location for the checkbox.


> Maybe we also want to rename "Save and Close" to "Send and Close"
> if attendees have been added.

Actually, it might be very useful if you can somehow enable both buttons on the toolbar when there are invitees (regardless of the current calendar provider).  This would give people the option of saving an event without sending any emails.  I can think of several benefits:

1) If you start to create a meeting invitation on day one but you have to wait until day two before you can complete the invitation (e.g. because you're waiting for someone to send you a document that you want to attach to the invitation), or

2) After you send the invitation, you might want to make minor changes to the event (for example in the Description field) without bothering everyone with another email invitation.

3) This might nicely address some of the concerns that were mentioned in Bug 374757.  That bug asks for the ability to not send an email at all.  It seems that the functionality that was added to Lightning in that bug is not currently available in the prototype event dialog.  Perhaps the code has already been written and simply needs to be called by the prototype event dialog.

I wonder if it's possible to communicate to providers such as Google and WCAP whether the user wants to only save the event or whether the user wants to save the event and send an email.  It would be nice if Lightning could communicate this desire based on which toolbar button the user clicks.  However, even if some providers don't support this, I think that it would still be very nice if we could do this with other providers such as ICS.
Hello
Following the last comment, I'd like to describe my own particular case : I'm in a company that uses Outlook/Exchange for mail/calendaring, but I'm using Thunderbird/Lightning on an exception basis, and I have my work calendar set as a Google Calendar. Yet, I don't want my invitations to be sent be Google directly (I just don't want my company to know that my calendar is hosted elsewhere). Instead, TB itself should send the invitations.
So, having an option to have the invitations sent "locally" by TB instead of using the provider capability would be very helpful.
This was my 50cts comment ! 
Attached image Toolbar screenshot
Regarding having the "Save" and "Send" buttons on the toolbar at the same time, I noticed that Thunderbird has both of these buttons on its toolbar in the composition window by default.  So, maybe there's also a way to have both in Lightning's event dialog if they are located in logical parts of the toolbar.  For example, I've attached a screenshot, but don't laugh at my lack of artistic/design skills.  :)
Summary: iTIP Invitations not sent when using prototype event dialog → [Proto] Event dialog: iTIP Invitations not sent
Pete, +1
Regarding opening the composition window to send invites, I'm thinking now that this might be more trouble than it's worth, and perhaps it's simply not necessary.  Plus, some of the MIME problems in bug 377761 might be caused by using the composition window.

For comparison, Outlook 2007 does not allow the user to type a personal message with iMIP emails.  However, it has a feature that I consider to be more useful.  There's a button on the toolbar called "Message to attendees" which allows you to send a personal message at any time to all invitees without having to re-type everyone's email addresses and without having to send any iMIP stuff.  Perhaps such functionality is a reasonable replacement to using the composition window.

My only hesitation is that it would still be nice to have some control of when an email is sent, either with a checkbox or (preferably) with separate toolbar buttons for Saving vs. Sending.

I think that this bug is blocking useful testing of bug 377761 because we have no obvious way in 0.7pre to send iMIP test emails.  One current workaround is to use Lightning 0.5 in a separate Thunderbird profile, but that could create invalid tests because of the older code base.

Suggestions for the purpose of this bug:

   1) for now, always send iMIP emails when we click "Save & Close"
   2) don't use a composition window

Suggestions for possible spin-off bugs:

   1) offer a way to control saving vs. sending, and restore the functionality of Bug 374757.  Also possibly consider ICS vs. Google/WCAP, etc.

   2) offer a way for the user to choose which Thunderbird identity/account to use with iMIP (perhaps in the properties of each calendar)

   3) and there's klint's request to send invitations from a Google-based calendar by using Lightning's iMIP functionality instead of Google's.
   4) add a button to the toolbar that's called something like "Message to Attendees" that allows us to send a non-iMIP email to all attendees at any time
I like your proposals, Pete. It will allow to test bug 377761 in a short term. But then suggestion #1 would be mandatory shortly after !

By the way, isn't suggestion #3 just a kind of extension of suggestion #2 ? which would be a control over which identity & method should be sending invites ? 
for instance, something like "select method&identity for invite" per calendar :
- "local/identity1"
- "local/identity2"
- "remote/default calendar provider identity" 

Of course, if the provider allows to select an identity among many, then the remote section would be different.

Taking this bug
Assignee: nobody → ctalbert
(In reply to comment #14)
>    4) add a button to the toolbar that's called something like "Message to
> Attendees" that allows us to send a non-iMIP email to all attendees at any time
> 

It seems that this is already being implemented as part of bug 373761.
Reassigning to me as discussed on this weeks' status meeting.
Assignee: ctalbert → michael.buettner
Attached image dialog with checkbox (obsolete) —
This screenshot shows how the dialog looks like with the checkbox added that was available in the original dialog.
Attached patch patch v1 (obsolete) — Splinter Review
This patch adds the checkbox as shown in the previously posted screenshot. Under the hood I'm using the same mechanism of signaling whether or not invitations should be send by utilizing the X-MOZ-SEND-INVITATIONS property.
Attachment #280721 - Flags: ui-review?(christian.jansen)
Attachment #280721 - Flags: review?(daniel.boelzle)
Mickey, would it be possible to align the "Attendees:" label with the Attendee list?


| Attendees: Attendee 1, Attendee 2, Attendee 3,
|            [X] Send attendees invitation via email

(In reply to comment #21)
> Mickey, would it be possible to align the "Attendees:" label with the Attendee
> list?
Sure, master, sure...
Attachment #280720 - Attachment is obsolete: true
Attached patch patch v2Splinter Review
Corresponding patch that realizes the better alignment stuff...
Attachment #280721 - Attachment is obsolete: true
Attachment #280732 - Flags: ui-review?(christian.jansen)
Attachment #280732 - Flags: review?(daniel.boelzle)
Attachment #280721 - Flags: ui-review?(christian.jansen)
Attachment #280721 - Flags: review?(daniel.boelzle)
(In reply to comment #8)

And, will there also be an additional option like 
 
               [ ] Edit invitation email before sending

... that, when unchecked, would allow to send the invitation directly without opening the mail composer ?

Then this would likely solve half of bug 377761, wouldn't it ?
That would be pretty nice for 0.7 !!

Thanks !
 
Comment on attachment 280732 [details] [diff] [review]
patch v2

ui=christian
Attachment #280732 - Flags: ui-review?(christian.jansen) → ui-review+
The ui is ok, but it causes the following errors (on Mac):

Error: this.mDefaultIdentity has no properties
Source File: file:///Users/cj93695/moz/sbird-out/dist/xpi-stage/lightning/components/calItipEmailTransport.js
Line: 65
---------------
Error: uncaught exception: [Exception... "'[JavaScript Error: "this.mDefaultIdentity has no properties" {file: "file:///Users/cj93695/moz/sbird-out/dist/xpi-stage/lightning/components/calItipEmailTransport.js" line: 65}]' when calling method: [calIItipTransport::defaultIdentity]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: chrome://calendar/content/calendar-item-editing.js :: checkForAttendees :: line 442"  data: yes]

(In reply to comment #26)
> Error: this.mDefaultIdentity has no properties

See Bug 374759. You need to select a valid email account as your default account.
(In reply to comment #24)
> And, will there also be an additional option like 
> ... that, when unchecked, would allow to send the invitation directly without
> opening the mail composer ?
The mail will only be send if the option has been checked. Currently, this always involves the mail compose window. We probably will need to be a bit smarter for the final version, but that's what we currently have. As a side note, you can always send mails to the attendees, this feature has been introduced with Bug 373761, also see [1].

[1] https://bugzilla.mozilla.org/attachment.cgi?id=276402
(In reply to comment #28)
Yes, I know about sending invites or mails to the attendees that will open the compose window. The problem is that the compose window breaks the MIME structure of the calendar invite and the new structure is not recognized by Outlook 2003 as a valid calendar event. That is why I'd like the mail to be sent directly by the calendar, based on the option. But I agree that this is the purpose of bug 377761, which is unfortunately postponed for the moment. So, I guess I'll wait and stop flooding this bug with my comments ! Wish I was a developer and could contribute ;) But I'm not !!
Thanks for your patience
Comment on attachment 280732 [details] [diff] [review]
patch v2

>diff -a -x CVS -U 8 -pN -rN mozilla_ref/calendar/prototypes/wcap/sun-calendar-event-dialog.js >+    var sendInvitesCheckbox = document.getElementById("send-invitations-checkbox");
>+    if (item.getUnproxiedProperty("X-MOZ-SEND-INVITATIONS") != null) {
>+        sendInvitesCheckbox.checked = (item.getUnproxiedProperty("X-MOZ-SEND-INVITATIONS") == "TRUE");
>+    } else {
>+        sendInvitesCheckbox.checked = false;
>+    }
Use plain hasProperty for the checkbox default as discussed on IRC.

>+        var sendInvitesCheckbox = document.getElementById("send-invitations-checkbox");
>+        if (sendInvitesCheckbox.checked) {
>+            if (!item.getUnproxiedProperty("X-MOZ-SEND-INVITATIONS")) {
>+                setItemProperty(item, "X-MOZ-SEND-INVITATIONS", "TRUE");
no need to test for property

>+            }
>+        } else {
>+            if (item.getUnproxiedProperty("X-MOZ-SEND-INVITATIONS")) {
no need to test for property

>+                item.deleteProperty("X-MOZ-SEND-INVITATIONS");
>+            }
>+        }
>     }

r=dbo with this fixed
Attachment #280732 - Flags: review?(daniel.boelzle) → review+
patch checked in on trunk and MOZILLA_1_8_BRANCH

-> FIXED
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.7
Verified with lightning 2007092403
Status: RESOLVED → VERIFIED
Component: Internal Components → E-mail based Scheduling (iTIP/iMIP)
QA Contact: base → email-scheduling
You need to log in before you can comment on or make changes to this bug.