GNOME Bugzilla – Bug 594153
Allow setting alarms on any meeting
Last modified: 2010-08-06 08:38:25 UTC
When you receive meetings from others you are not allowed to set your own alarms. This makes it effectively impossible to manage alarms for yourself the way you find them effective. Control is totally in the hands of the owner which may decide to set no alarms or set them in an inconvenient way for other participants. Alarms are clearly a personal choice and shouldn't be controlled by the owner of the event.
I think I remember Milan Crha mentioning this is a Zimbra issue. Like it treats all appointments as meetings or something. Not sure exactly. He can clarify when he returns next week.
Created attachment 142503 [details] Set alarms at accept time Users should be able to set the alarms when they accept an appointment.
Some IRC chatter: <dave_largo> xkahn, mbarnes: That mockup is very cool and useful. One thing to keep in mind is that I don't know if attendees can change the alarm in other backends, like Groupwise too. <dave_largo> Right now the sender determines the alarm <mbarnes> hmm, maybe it's not a Zimbra-specific issue then <xkahn> mbarnes: The request might be seen as a feature request to allow Evolution to keep its own set of alarms separate from the events on the server <mbarnes> wonder if iCalendar allows you to reference event objects from alarms without actually embedding the alarm in the event
I'd like to stress 2 points I wouldn't want to be forgotten 1. Alarms are not changable no matter what backend. Either via caldav or accepting the meeting into a local calendar on file will have the effect that I can't set the alarm. If the remote server prevents you from changing it is the remote server problem, but at least in the local calendar I should be able to set whatever alarm I want. 2. Alarms should be changeable at any time not just at accept time.
I'm using the Evolution Exchange backend 2.28.1 with Evolution 2.28.1 and I'm suffering from the same issue. Any meeting I have accepted from a colleague says: (:lightbulb:) Event cannot be fully edited, because you are not the organizer I agree with idra that I should be able at the very least to edit the alarm information at any time, and probably the "Show time as busy" flag as well, since neither of these should have any relation whatsoever to the original meeting request! As a final note of interest, I *am* able to edit and save locally both the "Summary" and "Description" portions of the same meeting, after agreeing to a "Changes made to this item may be discarded if an update arrives" popup.
Yup it really is a killer. It worked before I'm sure or else it always put an alarm in. Is there an option to enable alarm for all meetings as default, better to have an alarm you can ignore than miss an appointment.
Confirming this, in my case getting meeting invites via Exchange. I'm shocked that this is an issue, and it really is a show-stopper for using Evolution's calendar.
Using Microsoft Exchange: this works in 2.22.3 (Debian Lenny) and is broken in 2.28.2 (Debian Squeeze). In 2.22.3, I can modify alarms at acceptance time or at a later date. This is not server restricted; I can still make alarm modifications via MS Outlook and other MS Outlook clients will see the change but Evolution will not. What can we provide to help track this down and get it resolved?
Created attachment 159724 [details] [review] Patch to re-allow local editing of alarms This is a very simple patch (perhaps overly simple, but it does what I want) that allows me to edit alarms again locally. This does not propagate alarms up to the server, but at least now I have control over whether or not I can actually have an alarm pop up! Patch against HEAD of the 'gnome-2.6.28' branch of the Evolution git repository (currently 02486bc4e2592b75c8e6d6a7205c052d2eccd36d) but applies cleanly and works with the released evolution-2.28.3.1 as well.
P.S. I found the root cause when this behaviour changed: http://git.gnome.org/browse/evolution/commit/?id=0597b877c5bf4d21ac4048742ddf6b11e24877ba
After more digging, here's the complete root cause. In the commit I mention above, Matthew Barnes converted much of the event editing GUI to use GTKUiManager code, and in doing so missed a couple subtleties in calendar/gui/dialogs/event-page.c that decides which widgets should be sensitized or not depending on event ownership, read-only status, and so on. Basically the old BonoboUI actions "/commands/ActionShowTimeBusy" and "/commands/ActionAlarm" previously were set sensitive/insensitive based on the "read_only" status of the event being edited. After the change, these were all lumped together with everything else in the new "individual" action_group, which is now set as sensitive if the event is !read_only AND (here is the change) if the meeting's owner is the user currently editing the event. Based on this more careful analysis I am presently working on a more appropriate patch than the quick&dirty one I posted above... stay tuned.
Created attachment 159826 [details] [review] Fix part 1/3: Alarms are now editable again
Created attachment 159827 [details] [review] Fix part 2/3: View menu items are active again Related to the alarm issue: The View menu items "Time Zone" and "Category" were being deactivated improperly.
Created attachment 159828 [details] [review] Fix part 3/3: Attachment bar is disabled appropriately Related to the alarm issue: The add and remove actions of the attachment bar were not being deactivated properly.
Okay, those are my more-fine-grained and, I believe, fully correct patches. They were made against the current HEAD of the gnome-2-28 branch of git://git.gnome.org/evolution They apply cleanly to the last stable 2.28.3.1 release of evolution, which is what I am presently running. They also apply cleanly to the current HEAD of the master branch of git://git.gnome.org/evolution Upstream: Please consider these for inclusion as soon as possible, this bug is a show-stopper for many users. Users: If you have the technical ability to test these patches, please do so, and report your success (or lack thereof) here.
Patches tested on Evolution 2.28.3 (Ubuntu Lucid Lynx 10.04 x86_64) latest packages. Successfully added alarm to previous un-editable appointment. Thank you, Jim!
All three patches look beautiful, thanks for fixing my screw ups Jim! I rewrote the third patch because there's an easier way: use an EBinding to keep the two GtkActionGroup:sensitive properties in sync. It avoids the need for a custom signal handler. Committed each patch separately to master and gnome-2-30 branches. The following links are for the third patch. Follow the "parent" link for the second patch and again for the first patch. http://git.gnome.org/browse/evolution/commit/?id=3cda4f0d94c083199e89dae893ff5991ea3498c3 http://git.gnome.org/browse/evolution/commit/?h=gnome-2-30&id=c6c287d275f761e88c37bb7dbcf4676bf1363602
Also committed to gnome-2-28 branch by request. Distros will have to pick this up for themselves though. http://git.gnome.org/browse/evolution/commit/?h=gnome-2-28&id=22e540a225da939e9de02912d638402d2353b129
*** Bug 598594 has been marked as a duplicate of this bug. ***
*** Bug 625304 has been marked as a duplicate of this bug. ***