[kcalcore] [Bug 389336] New: current mDirtyFields handling in IncidenceBase implementation causes issues with event revision counts (iCal SEQUENCE property)

[Jochen Trumpf]

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-bugs at kde.org
          Reporter: Jochen.Trumpf at 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 the assignee for the bug.