Closed Bug 373663 Opened 17 years ago Closed 13 years ago

Processing iTIP responses for email aliases

Categories

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

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 428274

People

(Reporter: matp75zilla, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: 

Using Thunderbird 2.0pre (20070226) with lightning 0.5pre (2007030803)

Since patch in bug 334685 landed, I've got an accept and reply button associated with an invitation.

When I'm invited with my primary email address and choose accept or decline, an email response is sent.
As this wasn't always working, I've  discovered this is not working when I'm invited on one of my email aliases.
Unfortunalely, I receive invitation on two different email adresses.


Reproducible: Always




in the patch attached to bug 334685, we can read


+        var foundMyself = false;
+        var attendee = itemList[0].getAttendeeById("mailto:" +
+                                                   this.mDefaultIdentity.email);
+        if (attendee) {
+            myPartStat = attendee.participationStatus;
+            foundMyself = true;
+        }
+
+        if (!foundMyself) {
+            // I didn't find myself in the attendee list.
+            //
+            // This can happen when invitations are sent to email aliases
+            // instead of mDefaultIdentity.email (ex: lilmatt vs. mwillis),
+            // or if an invitation is sent to a listserv.
+            //
+            // We'll need to make more decisions regarding how to handle this
+            // in the future. (ex: Prompt? Find myself in list?)  For now, we
+            // just don't send a response.
+            return;
+        }

So it looks like implementation is not complete.

My opinion is it should try each of my email aliases (including my primary address)
The reply should use the same address as my invitation use (to make it work correctly at the other end)
(using some variable to remember the email address to use or may be it will already do it like for a standard mail reply ? )
Blocks: 334685
somehow related (does it need a separate bugid ?), resolution should also handle the case where the invitation is made to a group.
Example (real invitations I'm receiving) :
invitation to a company event (ie everybody@company.com is invited, not the individuals but the mail server sends the invitation to everyone)
invitation to a mailing list 
I have 2 POP3 account setup in Thunderbird, and invitations are only processed for my primary account.  I am using the latest nightly build of Lightning (Sept 5th) and Thunderbird 2.0.0.6

I routinely get invitations sent to both accounts
I'm also seeing this (no mail when accepting an event sent to an alias) on build 2007101603 of Lightning.
I started to work on this issue. There are several places where the default Email-User is referenced. I need to get this one fixed - therefore I am start working on it. Even if I have several questions - hopefully getting them answered in the IRC.
Right now imip-bar.js is assuming that the default email-id is the right one. From there on, a couple of things are going wild. At least I got it nailed down to the last point in calItipEmailTransport.js. 
Hopefully I will find some spare time in the next week or two.
Jochen
(In reply to comment #0)
> +            // We'll need to make more decisions regarding how to handle this
> +            // in the future. (ex: Prompt? Find myself in list?)  For now, we
> +            // just don't send a response.

There are many reasons that no mail address of the attendee list matches any of one's mail addresses. Some are already mentioned here and I really don't want to expand this list...

IMHO the message should always be created, at least as long as we still get the compose dialog to finally send it.

CC'ing Clint to comment on this.


Another (nice) feature would be, to automatically select the correct identity when sending replies to invitations, as it is done by "Reply"/"Forward".
But maybe this is something for another bug...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Internal Components → Lightning Only
QA Contact: base → lightning
Blocks: 404900
I'm not sure what has changed since the bug was filed, but the current situation is the following:

It still doesn't work. But I recognized that getAttendeeById is called twice, the first time with the correct address (the one the mail was sent to) and a second time with the default mail address. So I looked for the callers, and I found that the first call is done in imap-bar.js in setAttendeeStatus(), which is called by setAttendeeResponse(). The address used there is determined by getMsgRecipient() which checks the recipients and CCs for any of your mail addresses.
The second call is located in calItipProcessor.js, _getReplyStatus(), which itself is called by _continueProcessingItem(). There the address is transport.defaultIdentity.

Well, if we could somehow hand the address of the first call over to the second one, it should work. That would have to start in doResponse(), which is called by setAttendeeResponse() as well and so could take the address determined before as an additional parameter. However, the problem would be that the parameter would have to be added to a couple of functions until _continueProcessingItem() would finally be reached, including some functions which are defined in interfaces. But copying the getMsgRecipient() function from imip-bar.js to calItipProcessor.js also doesn't sound like the best solution...

Does anyone have ideas how this could be done in a better way?
Component: Lightning Only → E-mail based Scheduling (iTIP/iMIP)
Flags: wanted-calendar0.9+
QA Contact: lightning → email-scheduling
Flags: wanted-calendar0.9+ → wanted-calendar0.9-
This reads like a dupe of bug 418345. Reporter, could we close this one?
Oops, wrong bug id. I meant bug 428274.
For me this looks the same and the reporter has not answered for 2 years.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.