https://bugs.kde.org/show_bug.cgi?id=389336
Bug ID: 389336
Summary: current mDirtyFields handling in IncidenceBase
implementation causes issues with event revision
counts (iCal SEQUENCE property)
Product: kcalcore
Version: git
Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: kdepim-b...@kde.org
Reporter: jochen.tru...@anu.edu.au
Target Milestone: ---
To reproduce the issue:
1) Accept an event invitation from kmail that you are not the organizer of (not
sure if this is really necessary but it is the case that I fully tracked down).
2) Edit the event in korganizer and be careful to ONLY add an alarm.
3) Get the event organizer to send you an event update, for example, with a
changed location.
4) Observe how the location change is shown in "reverse logic".
5) Try to accept the changed invitation and get the "This is not an update"
error.
What happens under the hood:
Step 2) above should not lead to an increment of the event revision (iCal
SEQUENCE property). At least that is the intent of the
allowedModificationsWithoutRevisionUpdate logic in
akonadi-calendar/incidencechanger.cpp lines 1022ff.
Two things are going wrong, though, and if you watch the actual akonadi payload
(e.g. in akonadiconsole), you will see that the revision gets incremented
TWICE!
So by the time the organizer sends an update, the local copy is seemingly
newer, leading to the incorrect display in kmail as well as the error in Steps
4) resp. 5) above.
One of the revision count increments is caused by lines 657ff in
incidenceeditor/incidencedialog.cpp. This seems to be an unconditional
increment in this context and I have no idea why it would be there. It appears
to preclude any form of "smart" handling of changes within akonadi.
The other revision count increment is due to a failure of the
allowedModificationsWithoutRevisionUpdate logic mentioned above. In that
function, the dirtyFields() call on the incidence returns many more fields than
just IncidenceBase::FieldLastModified and IncidenceBase::FieldAlarms. On my
machine it lists a total of 10 fields, including FieldRevision due to the
previous increment in incidencedialog.cpp.
The issue seems to be that some of the modifier methods in IncidenceBase and
its children set the respective dirty flag even if the value of the property
has not changed. For example, setOrganizer in IncidenceBase does not check the
previous value and setSecrecy in Incidence or setTransparency in Event fail
similarly. On the other hand, some of the set methods do this correctly, for
example setUid in IncidenceBase. On my machine, I have observed incorrect
behavior for Description, Recurrence, Attachment, Secrecy, Transparency,
Attendees, and Organizer (and possibly for Alarms and Revision as well, but
that might be confounded with the other issues described here).
Additionally, toggling the alarm on the event (e.g. via the context menu in
korganizer) seems to set IncidenceBase::FieldUnknown in dirtyFields() where it
should probably be FieldAlarms. With FieldUnknown, toggling the alarm causes
similar issues as described here.
While you are fixing this, the logic in
allowedModificationsWithoutRevisionUpdate should probably be expanded to also
allow modifications of Categories (not 100% sure about this but I would think
that categories are a local property given that they map to akonadi tags). Many
people are colour-coding their agendas using (local) categories and in the
current implementation that breaks invitation updates.
I am more than happy to try suggested fixes if needed.
--
You are receiving this mail because:
You are watching all bug changes.
