RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 698243 - Alarms can't be set on meetings/appointments filed by others
Summary: Alarms can't be set on meetings/appointments filed by others
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: evolution
Version: 6.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: beta
: ---
Assignee: Milan Crha
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 883010
Blocks: 960054
TreeView+ depends on / blocked
 
Reported: 2011-04-20 14:06 UTC by Simo Sorce
Modified: 2015-09-28 02:12 UTC (History)
3 users (show)

Fixed In Version: evolution-2.32.3-2.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-21 05:01:45 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
evo patch (7.05 KB, patch)
2011-04-20 17:21 UTC, Milan Crha 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 594153 0 None None None Never
Red Hat Product Errata RHSA-2013:1540 0 normal SHIPPED_LIVE Low: evolution security, bug fix, and enhancement update 2013-11-21 00:40:51 UTC

Description Simo Sorce 2011-04-20 14:06:38 UTC 
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.
Comment 3 RHEL Program Management 2011-04-20 15:34:58 UTC 
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.
Comment 4 Milan Crha 2011-04-20 16:51:14 UTC 
Should be doable by something close to the upstream fix from [1].

[1] https://bugzilla.gnome.org/show_bug.cgi?id=594153
Comment 5 Milan Crha 2011-04-20 17:21:48 UTC 
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
Comment 6 Simo Sorce 2011-04-20 18:00:23 UTC 
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).
Comment 7 Milan Crha 2011-04-21 08:19:09 UTC 
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?
Comment 8 Simo Sorce 2011-04-21 12:09:54 UTC 
(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.
Comment 10 Milan Crha 2011-04-21 16:57:47 UTC 
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.
Comment 11 Simo Sorce 2011-05-05 14:13:51 UTC 
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.
Comment 12 RHEL Program Management 2011-07-06 00:07:23 UTC 
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.
Comment 13 Milan Crha 2012-02-08 13:51:14 UTC 
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.
Comment 15 Simo Sorce 2012-02-08 14:28:03 UTC 
(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.
Comment 16 Suzanne Logcher 2012-02-14 23:08:53 UTC 
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.
Comment 17 David Jaša 2012-04-10 16:54:17 UTC 
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
Comment 18 Milan Crha 2013-05-07 07:58:14 UTC 
Devel-acking, patch available.
Comment 20 Milan Crha 2013-05-09 18:05:44 UTC 
Upstream fix is part of 2.32.3, thus marking as a dependency of the rebase bug.
Comment 26 errata-xmlrpc 2013-11-21 05:01:45 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.