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)
Calendar
E-mail based Scheduling (iTIP/iMIP)
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 ? )
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
Comment 2•17 years ago
|
||
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
Comment 3•17 years ago
|
||
I'm also seeing this (no mail when accepting an event sent to an alias) on build 2007101603 of Lightning.
Comment 4•17 years ago
|
||
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
Comment 5•16 years ago
|
||
(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
Updated•16 years ago
|
Component: Internal Components → Lightning Only
QA Contact: base → lightning
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?
Updated•16 years ago
|
Component: Lightning Only → E-mail based Scheduling (iTIP/iMIP)
Flags: wanted-calendar0.9+
QA Contact: lightning → email-scheduling
Updated•16 years ago
|
Flags: wanted-calendar0.9+ → wanted-calendar0.9-
Comment 7•16 years ago
|
||
This reads like a dupe of bug 418345. Reporter, could we close this one?
Comment 8•16 years ago
|
||
Oops, wrong bug id. I meant bug 428274.
Comment 9•13 years ago
|
||
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.
Description
•