Red Hat Bugzilla – Bug 698243
Alarms can't be set on meetings/appointments filed by others
Last modified: 2015-09-27 22:12:13 EDT
Description of problem: If your caldav calendar contains meetings or appointments created by other people you are prevented from setting your own alarm. Expected results: Be able to set as many additional alarms as I need to to remind myself to actually attend those meetings appointments, especially when the owner didn't set any alarm at all. Also needed to remove alarms for optional meetings I do not want to be bothered about. Additional info: Apparently already fixed upstream.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Should be doable by something close to the upstream fix from [1]. [1] https://bugzilla.gnome.org/show_bug.cgi?id=594153
Created attachment 493552 [details] evo patch for evolution; I'm building a test package with this included at http://brewweb.devel.redhat.com/brew/taskinfo?taskID=3272324
Alarm dialog is now editable. But it looks like alarm do not stick, not sure if that's an issue with the patch or a problem related to the server (zimbra).
It seems to stick on the server for me (at least when I modify the event with evolution master). Is it recurring on a single event which forgets your alarm change, please? Also, I suppose it's a CalDAV calendar pointing into your Zibra calendar, which is writeable for you. Am I right?
(In reply to comment #7) > It seems to stick on the server for me (at least when I modify the event with > evolution master). Is it recurring on a single event which forgets your alarm > change, please? Seem happening on most events I do not own. So far I found only one event where I changed the alarm (one was present) and it seem to be sticking although I see no change on the alarm in the zimbra web interface (not sure if I am supposed to). This is a single day event, yet on another single day invite with no alram it didn't stick. I also wasn't able to make it stick to recurring events, whether I choose to change just one instance or the whole series. > Also, I suppose it's a CalDAV calendar pointing into your Zibra > calendar, which is writeable for you. Am I right? Yes.
Could you run evolution-data-server in a terminal and see what it receives from the server and what it tries to send there, please? You can do that by running this command: $ CALDAV_DEBUG=all /usr/libexec/evolution-data-server-2.28 &>log.txt it'll capture all CalDAV communication between evolution and the server, showing also raw event data. Note that only one e-d-s can be running in the system, thus run evolution --force-shutdown first. Feel free to send me the log privately, to not expose any sensitive information in the bugzilla. Only name the bug in the subject, otherwise I may overlook and let it stay in a junk folder. What I tried seems to work fine here, and I did it on both recurring and single events I have in my private Zimbra calendar, events not organized by me.
New data point. As part of the previous tests I tried to add an alarm to a recurring event through evolution. Apparently it was set on a single occurrence. Today I was checking the zimbra interface and zimbra always showed an alarm regardless of which view (single instance/whole series) of that event I was looking at. Yet evolution didn't show anything. Via the zimbra web interface I removed the alarm from the series setting the rminder to never and saved, then reopened the series and set the alarm to 15 min. Shortly after that evolution started showing an alarm on the event.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
Simo, just wondering, there was done a Zimbra update since your last report. Did the Zimbra update have any good influence on this issue? Also, if I understand comment #11 properly, then it means you have it working finally, even the Zimbra interface and evolution interface are both slightly out of sync. Am I correct? I want to be sure we've this fixed as you requested.
(In reply to comment #13) > Simo, just wondering, there was done a Zimbra update since your last report. > Did the Zimbra update have any good influence on this issue? Also, if I > understand comment #11 properly, then it means you have it working finally, > even the Zimbra interface and evolution interface are both slightly out of > sync. Am I correct? I want to be sure we've this fixed as you requested. I have official RHEL bits, and I can't edit alarms. I was able to edit them with the temporary packages you built back then, but see comments. Currently not working in RHEL.
In a scratch build that mcrha gave me today*, actions with alarm (add/modify/delete) of events scheduled by someone else work for me. * evolution-2.28.3-25.2.el6.x86_64
Devel-acking, patch available.
Upstream fix is part of 2.32.3, thus marking as a dependency of the rebase bug.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-1540.html