GNOME Bugzilla – Bug 420513
when adding an invitee to an existing meeting, there is no option to send to new attendee only
Last modified: 2009-07-27 15:36:58 UTC
when adding an invitee to an existing meeting, there is no option to send to new attendee only Steps To Reproduce: 1) Create a meeting 2) Add an attendee 3) Save it 4) Open the meeting and add another attendee. 5) While saving there is no option to send to new attendee only
Created attachment 84965 [details] [review] Send invitation to new attendee only
+static GPtrArray *list_all = NULL; Having a global vairable for this purpose is incorrect. The memory is not freed anywhere. It better to have the code for poping up the dialog in send-comp.c, since this is would be required for tasks component also. The new attendee will not be able to see the already exising attendees with the patch. Instead of creating a component with only new attendees, if you could set the 'To' list to New attendees alone that would allow the new attendees to see the old attendees as well.
Bumping version to a stable release.
Downstream bug https://bugzilla.novell.com/show_bug.cgi?id=207981
Created attachment 117139 [details] [review] proposed evo patch for evolution; A bit longer patch, but it's just because of the prototype changes. New string added. As far as I tested it it works fine. It fixed also the issue when the cancellation component has been send to some removed attendee(s), then no change has been send to the remaining attendee(s) for the meeting. I also noticed, when adding new attendee and remove it immediately, then the cancellation component has been send to him. No more now.
New string... Chen, if it can't go today, then cant be for this release :-)
I tried out the patch and it worked fine. I tried with exchange back end as we don't support resend / modification in group wise back end. Suggestions =========== -> New string in the dialog should be shifted to start up instead of middle and it would be good to make it bold (if it doesn't violate HIG) -> Should we add something in subject line of meeting request if organizer decides to send update to all attendees. My concern is how will existing attendees identify that there has been update in existing meeting and they need to accept new one. Like if we change the time, it can be identified easily but i am not sure about identifying update when we add a new attendee. I am also not sure how useful my suggestion is. Issue ===== -> One of the attendee accepted the meeting request, updated mail has been sent to organizer, organizer also clicked on 'updated status' button. But changes of role were getting reflected only in organizer's calendar means accepted / declined, in other attendees calendar, role field still says 'Required participant' - could be known issue but i came to know just now.
Created attachment 117833 [details] Screenshot of dialog
The only reason to have it centered is that I didn't want to hack the dialog so much. It's created in e-error.c and traversing children of the dialog->vbox seemed to me like a quite big hack. But if you really want this, I can do that.
It would be cleaner to have a gslist instead of multiplexing attendee emails with a ; inside a single string. Calling comp_editor_* functions from itip_utils would break abstraction. It would become hard if we want to move comp_editor separately into EDS. Instead of using only_attendees boolean in itip_send_comp, users can be filled in with new attendee email ids. Then I think we would send emails to only new attendees.
Chen, I would like to discuss it, before resending patch. Thanks. I can move those function from comp-editor-utils to some comp-util or something, but I do not think it'll have any impact on movement of CompEditor from evo to eds, you should move comp-editor-utils anyway, and it'll save few lines of code, to have it as it is now. Using GSList* instead of char* sounds good to me, but I cannot reuse the 'user' parameter of the itip_send_comp, because comp-editor.c:real_send_comp uses both of them.
Chen?
I think having comp-editor-utils is just fine. Somehow i thought it wrong initially, sorry for that. You can use GList instead of char* in that case.
Created attachment 137017 [details] [review] proposed evo patch ][ for evolution; Here's a patch which: a) is updated to actual sources b) indents checkboxes to the left in a question dialog (yup, there can be up to two now) c) uses GSList instead of gchar * for a list of new attendees Chen, what do you think about Akhil's comment #7? Move it to a new bug/patch?
I assume that this patch just incoporates the comments from comment#10. Just looked through the patch and it looks good. For comments from Akhil, the UI will handle if there is an update of the meeting using the sequence number. But to show the field thats updated, would be an enhancement. Other attendees wont get the role udpates as the notifications are only sent to organizer.
plz announce the string/ui changes to the doc/translation teams.
Created commit e3cef9b in evo master (2.27.6+)