Currently the iTIP Processor doesn't have any clue as to what you wanted your status to be (since the iMIP bar handles that). So to support delegation to people not on the invitation list of the event we must do the following: 1. Change iMIP-bar.js to add the non-invited individual to the event with their desired status (accept/tentative/decline etc) 2. Have a hard look at the way that REQUEST methods are handled in calItipProcessor.js in order to be sure that all delegation methods are properly addressed. 3. The code in calItipProcessor.js::getReplyStatus that references this bug should be changed, to reference an appropriate error message. If you hit that code after changing imip-bar.js then that means that adding you to the attendee list back in imip-bar didn't succeed.
Component: Lightning Only → E-mail based Scheduling (iTIP/iMIP)
QA Contact: lightning → email-scheduling
Version: Trunk → unspecified
The case where I'm seeing this is when invites are sent out to a mailing list. We'll probably be moving to a public CalDAV calendar for this sort of event when we migrate to Lightning but I figure this is a fairly common case.
That is correct. Additionally, there is also the option of aliases that point to the same account (distributed mail services and support organizations will use). I had added some identities to match those aliases and mailing lists, and encountered a different error : Error: [Exception... "'Error: _getReplyStatus: You are not on the list of invited attendees, delegation is not supported yet. See bug 420516 for details.' when calling method: [calIOperationListener::onOperationComplete]" nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "JS frame :: file:///home/jlewis/.thunderbird/2qszt5yk.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calMemoryCalendar.js :: anonymous :: line 317" data: no] Source File: file:///home/jlewis/.thunderbird/2qszt5yk.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calMemoryCalendar.js Line: 317
I just noticed the behavior the ACC/DECL are displayed also I'm not on the invitation list. Unstanding the status of the current code, I recommand -- at a minimum -- to display an alert for the user like "You are not part of invitation ...etc etc delegation etc ...". Currently when using the buttons in this situation nothing happens -- only the Error Console show a msg. But the normal user will never look onto that one. So if for the next release the delegation can't be solved, please add an alert to the user!
I agree with Günter. Until this is resolved, the user should get an alert.
(In reply to comment #4) I ask to put this bug in 0.9 because it is a serious lack IMHO for the use of Lightning in company
Even if I don't want to reply, this makes the invitation non-addable to my own calendar. Re comment #4, for mailing lists you most likely *are* part of the invitation, even though technically you're not.
add #1 Mail List If you receive an invitation via a mailing list your name should be included in the ICS file as an attendee. Isn't? (Can't check for that at the moment ;) So the main question is: does LG check the ICS file attendee list against the receiver account list?
Dunno if it *should* or not, but from outlook it isn't.
(In reply to comment #9) Which OL version? And you say the attendees name isn't in the mail hdr (as to/cc) nor in the ICS file? (In reply to comment #7) > Re comment #4, for mailing lists you most likely *are* part of the invitation, > even though technically you're not. Please define also "even though technically you're not" with #7.
The mail headers which the ICS is coming through has the To:, and sometimes (if you aren't specified in the headers in cases such as BCC's) it just arrives in your mailbox via the SMTP "RCPT TO:" command. I'm on many mailing lists where the originator of the message blasts the appointments out to an alias, rather than adding each individual. The strong case here is a team environment, where an alias dumps to each user, but isn't rewriting the ICS mime component for the users to include their individual addresses in the "attendees". This is the "you *are* part of the invitation" while still being technically not in the list of invited attendees. A simple work around : pop up the error message stating "if this is in error, please ensure that the identities associated with this account match the list of attendees" so that someone can just create an identity to match the alias. However, if we currently add the aliases/lists as identities, we get another error in the system. I don't have my current system up to get the actual error message, but it can be found by duplicating the issue and then adding the identity : 1 - Create a mailing alias 2 - Send an appointment to that mailing alias 3 - Try to accept it (it won't give any indication unless you have the error console open - this is where we should pop up a message) 4 - Enter the account preferences 5 - Add the alias as an identity for the same account 6 - Try to accept the appointment again Hopefully, this will narrow things down a bit.
(In reply to comment #10) > Which OL version? This was outlook2003. > And you say the attendees name isn't in the mail hdr (as to/cc) nor in the ICS > file? Exactly. It's To: firstname.lastname@example.org and the ics has ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="FOOBAR":MA ILTO:email@example.com > (In reply to comment #7) > > Re comment #4, for mailing lists you most likely *are* part of the invitation, > > even though technically you're not. > Please define also "even though technically you're not" I meant that in this case I am part of group2 (a "list" of people, I'm not sure if outlook/exchange call them lists) and therefore invited, but there is no way to know that for the application.
(In reply to comment #11) I see the point, but please how do you reply ... and more important how does the ORGANIZER differentiate the responese from you and the other attendees? It's my understanding the ORG has (with what you describe with the list) only one attendee: the list. So how can he/she track the responses etc??
The responses and "acceptances" always come back from the individuals, not from the list in general.
(In reply to comment #14) > The responses and "acceptances" always come back from the individuals, not from > the list in general. > And that's the point I don't understand here. From my view the ACC/DECL etc response generated by the client (here LG/SB) would have to insert the repliers name to construct the ATTENDEE item detail. Right? If that's not the case the ORGANIZER would receive a response with the list name as an ATTENDEE. If that's the case the calendar app of the ORG would have to combine the mail sender name with the ICS based response. Sounds a bit tricky for OL etc. So what look like the ACC/DECL response if you received the invitation as a group member? Can you post an example?
Evolution handles this ok, http://svn.gnome.org/viewvc/evolution/trunk/calendar/gui/e-itip-control.c?view=markup see the functions update_item and update_attendee_status, the case that "%s", _("This response is not from a " "current attendee. Add as an attende?")); in particular.
I see something very much like this, but it seems that I _am_ in the invitation: I have an ICS file with the following reference to me: ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Rose, Chr is":MAILTO:firstname.lastname@example.org This is in an account for that email address, and I have the identity "Chris Rose" with address email@example.com associated with that account. However, I get the error that references this bug when I attempt to accept the invitation, which seems to me to be a bit of a bug. Is this related? Error: [Exception... "'Error: _getReplyStatus: You are not on the list of invited attendees, delegation is not supported yet. See bug 420516 for details.' when calling method: [calIOperationListener::onOperationComplete]" nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "JS frame :: file:///home/rosec/.thunderbird/zr183cf3.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calStorageCalendar.js :: anonymous :: line 596" data: no] Source File: file:///home/rosec/.thunderbird/zr183cf3.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calStorageCalendar.js Line: 596
Further examination shows that the key here is that the account in question is not the default account, it's my secondary account. So looks like you need to have the primary account in the invitation list, not just any old account.
Just to mention my posting with Bug 428274 – Can't accept Invitation when received via a mailgroup since Lightning 0.8 Both bug "descriptions" go into the same direction: - handling invitations where the recipient /attendee is as part of an mail-list - how to REPLY (accept/decline etc) With both bug discussions there is the idea to handle it as DELEGATION. I think that's NOT RFC compliant! A REPLY of an ATTENDEE as part of a list/group has to follow the definitions shown with rfc2445#section-4.2.11 Group or List Membership DELEGATION is something else !!!
Gunter in comment #20 is right ! being part of a group : http://tools.ietf.org/html/rfc2445#section-4.2.11 DELEGATION : http://tools.ietf.org/html/rfc2445#section-4.2.5 If I understand correctly Delegation is the act to assign someone else to represent ourself to the event It's something else !!
Perhaps a bit OT, but re comment 7 -> i learned that while outlook (2003) does send out such invitations to lists, the invitations replies won't get back to the sender. For it to work one has to "expand" the list in outlook so that each individual address is invited.
I've just figured out that this bug is the cause of a recurring issue I've been having, driving me nuts: people in my company do use Outlook and send to Exchange "list" email-IDs which results in my individual mail address not showing up in the list of attendees and therefore the event fails to add to my calendar - with absolutely no indication that anything has gone wrong. Only by checking the error log did I spot this bug ID. Therefore I agree with Comment 4 & 5 regarding an alert, and also with comment 20 - this is not the same as delegation. Any alert should be carefully worded, because I am *definitely* on the invite list (by virtue of being a member of the "list" e-mail ID stored in exchange). To get around this and other issues, I still have to run Outlook in a VmWare session so that I have a "real" calendar working somewhere, although I keep trying to switch to Lightning...
Not sure if comment #15 has been answered clearly, but to add to it : In outlook 2003, if I receive an invite because I am part of a list, I reply back to the sender. The next time an update or another activity is done on the invite by the sender, then my name/email (along with others' who have also replied to the invite)is also added *explicitly* in the To/CC list (apart from the list address, of course). My name is definitely added if I have Accepted or marked tentative. Not sure if I receive updates if I declined. BTW, as others have pointed out, this is a *major* issue in many orgs, where Outlook is the de-facto standard and a bunch of us "rebels" are trying to use TB/Lightning :)
Hello Philipp, How we can get some traction on this bug? I am ready to help with the coding Kind Regards
Christophe, are you still a student? We're currently discussing GSoC Projects and this might be one. We are still evaluating the possibilities though, we should have the final ideas up by March 29th at latest. If not we can start right away. I'd suggest we discuss any API related decisions together, then you're free to start coding. I'll ping some people to help you with the API decisions if you want, if you like you can do a proposal yourself though.
Hello Philipp, My student time are far away :(..No I am just a old guy of 35 years interested in open source and trying to give a hand with its limited knowledge. I think it is better if you (as a group) define the API as you surely know better all the insides of TB and will try to implement them. Kidn regards
Summary: Allow iTIP processor to support delegation to uninvited attendees → Allow iTIP processor to support delegation to uninvited attendees (forward event invitation)
Hello Philipp, I want to delegate or add someone to an event I am not the organizer so I I understand the rfc correctly, Lightning should: A1 send an invitation to the event to the person I want to add so I must add 2 property ATTENDEE;DELEGATED-FROM="MAILTO:firstname.lastname@example.org":MAILTO: email@example.com ATTENDEE;DELEGATED-TO="MAILTO:firstname.lastname@example.org","MAILTO:jqpublic@ host.com":MAILTO:email@example.com A2 send an update to the organizer to ask him to accept or not the new attendee: I am not sure of this second step 5clearly here we should touch impi-bar.js). Should the original organizer be able to accept new attendees and how are they registered in the event to be sure to get the updated information if the event changes location/time etc.... OK and the most important, in which part of the code should I look to have this working. (calItipProcessor.js?) Thanks
Christophe, I must say I'm not really an expert on the itip code, but I'll do my best to help. I'm not sure your scenario is pure delegation. > Delegation is defined as the process by which an "Attendee" grants > another CU (or several CUs) the right to attend on their behalf. This sounds to me like its only meant that you as an attendee can say that someone else will be setting your event details. This sounds a bit more like what you need: > 18.104.22.168. Sending on Behalf of the Organizer Here it is described, that an attendee can update the event as if he were the organizer, using the SENT-BY parameter. The next option is described just thereafter: > 22.214.171.124. Forwarding to an Uninvited CU This scenario suggests, that the even it merely forwarded to an uninvited user. The uninvited user can then send a REPLY to the organizer, and the organizer can decide if the user should be part of the event. I would suggest implementing the suggestion in 126.96.36.199. This means you need to make sure that its possible to forward the event, and in return the organizer needs to be notified that a new attendee has been added, and if he wants to accept or decline this attendee. The code is in calItipProcessor.js, while the ui code is probably in lightning/content/imip-bar.js. There's also base/modules/calItipUtils.jsm which may be of help. Disclaimer: I may be wrong, please feel free to correct me if something sounds fishy to you :-)
Hello, That was I meant the 188.8.131.52. I have gone through the code and I think I should touch 1.lightning/content/lightning-common-sets.js and the function doCommand to add the forward or should we consider it as a modify and not change that. 2.calendar/base/content/calendar-item-editing.js and function OpenDialog or clone this one for the forward and then call http://mxr.mozilla.org/mozilla/source/calendar/base/content/calendar-summary-dialog.js and call the UpdateAttendees function plus some xul element Could someone confirm that the steps are ok before I start coding so it will save some time for everybody to get it right at the beginning. Kind Regards
(In reply to comment #33) > Hello, > That was I meant the 184.108.40.206. > > I have gone through the code and I think I should touch > 1.lightning/content/lightning-common-sets.js and the function doCommand to add > the forward or should we consider it as a modify and not change that. In an ideal world, the user should be able to just click "forward" as if he would forward the email using Thunderbird. This might be a bit tricky, since you'll have to open a compose dialog that contains the .ics attachment in the right way (i.e with Content-Type: text/calendar; method=REQUEST). I'd suggest checking how Thunderbird opens the compose dialog and hook in there somewhere to correct the content type (if needed). Possible issues here are that for some mail/calendar user agents, the ordering of the attachments in the mime part is important (hence the Outlook 2003 compatibility dialog). The situation may have changed with a later Thunderbird though. > 2.calendar/base/content/calendar-item-editing.js and function OpenDialog or > clone this one for the forward and then call > http://mxr.mozilla.org/mozilla/source/calendar/base/content/calendar-summary-dialog.js > and call the UpdateAttendees function > > plus some xul element There are a few different scenarios where you will need to hook in. I don't think any changes to calendar-item-editing are required, since mostly user interaction happens in the imip bar or invitations dialog. * The organizer receives an email from the uninvited attendee. - If the server supports server-side scheduling, then UI changes will need to be made to base/content/calendar-invitations-dialog.xul/js so that the organizer is made aware that its a new attendee. I'm not sure of the full extent of this change, someone with more knowledge about server-side scheduling needs to help you here. I'm also not sure what happens to the attendee list of the existing event in this case. - If this is client-side scheduling, then it will be a real email in the organizer's inbox. He will see it and get the usual blue imip-bar. You will need to add UI to make the organizer aware that accepting this update will add a previously uninvited attendee to the event. I hope this doesn't put you down, I'd be delighted if you could get this feature working, it would be a great improvement for Lightning! I'm happy to help you with any details, as far as I know the code and I'm sure that someone else (Simon?) can help you with the server side scheduling issues. For a start it would also be sufficient to only take care of the client-side scheduling case, we can take care of server-side scheduling later on.
Hello Philipp, Ok so we 'just'need to invoke the compose method/function with right parameters for a first step.... I will try to find where to hook up or how it is invoked in lightning code Best
Hi all, We have already implemented this feature in Lightning Inverse edition (http://www.sogo.nu/fr/downloads/frontends.html) I think it would be wise to simply merge that code in the upstream version. All the code is already there and has been tested in real-life environments.
Hello Wolfgang, oh it will be so great. Could you do it, I mean the merge Thanks a lot in advance Best regards
Wolfgang, thanks for the note! Maybe you could work together with Christophe so we can merge in this feature. I'm happy to review it, but depending on the patch we should probably merge it after the upcoming release (i.e because of strings).
Hello Wolfgang, I have been through some of your code and as it is well commented, I think there is only 4 or 5 files to modify. The only thing that could be a bit difficult is that you have created an specific ACL manager. How is it involved in the process? If you could give me some indications, so that I can start... Kind Regards
Hello, I have started by looking at the imip-bar.js from lighning and the one of the inverse Edition...They are so different....I will try with other files first..but it is going to take times grrrrr Anyhelp would be appreciated. Kind Regards
You might want to take a look at the hg log of that file to see what has changed inbetween. Also, check out: http://mxr.mozilla.org/comm-central/source/calendar/base/modules/calItipUtils.jsm I've moved a few functions into that file since TB Conversations needed it.
Hello Wolfgang, By any chance do you think you will have time to merge your changes in here so that this bug can make some progress... Thanks
Initial patches still need some bugfixes, but they look very promising!
Assignee: nobody → christian.kulpa
Status: NEW → ASSIGNED
Great. I guess more information can be found at http://almostintelligent.de/2012/08/13/gsoc-update/. Though, I could not see the code.
Hello Any news...What it is needed to make it moving Thanks
We have a growing number of users that would like to see this feature... would love to see some progress or offer assistance if someone wants to point me in the right direction.
This has been open since 2008? You have got to be kidding.
You need to log in before you can comment on or make changes to this bug.