Differential D14

Add tests for iTip handling with event is calendars already.
ClosedPublic
Actions

Authored by • knauss on Jun 11 2015, 9:53 AM.

Details

Reviewers

mollekopf

Maniphest Tasks

T451: Invitation handling

Summary

Do not trigger dirty fields with no changes

Only executing a set function should not automatically add fields to
isDirty, where there were no changes.

Do not increment revision, if only a schedulingid is added

Search for existing incidences also by instanceIdentifier

When we have also to use other clients, that update the calendar we have
to make sure, that kontact is RFC conform. Other clients, do not use
scheduling Id, so we have to make sure, we find the incidences by
uid+recurrence id.

Make sure, that cancel mails are sent, if event is deleted

This change was done to fix the itiphelper tests.

Diff Detail

Branch

dev/itip_update

Lint

No Lint Coverage

Unit

No Test Coverage

Event Timeline

• knauss updated this revision to Diff 25.Jun 11 2015, 9:53 AM

• knauss retitled this revision from to Add tests for iTip handling with event is calendars already..

• knauss updated this object.

• knauss edited the test plan for this revision. (Show Details)

• knauss added a reviewer: mollekopf.

• knauss added a task: T451: Invitation handling.

some cleanup

Some questions/comments of the patch

akonadi/calendar/CMakeLists.txt
9	This is needed to activate the itiphandler test ; problem with jenkis on kde infrastructure, so they can't run the tests, and the tests are fragile. randomly breaks, because of sqlite.
akonadi/calendar/tests/itiphandlertest.cpp
373	Well I would say, that the uid matches with the schedulingId. Otherwise we can't detect the event anymore with wallace/rcm, if they are different.

• knauss added inline comments.Jun 11 2015, 10:39 AM

akonadi/calendar/incidencechanger.cpp
676	The end of the mailschedular is not connected to anything, so it is completly async. This reluts for the test in a QWARN QCoreApplication::postEvent: Unexpected null receiver, because the MailSchedular is deleted with the end of the method.

• knauss mentioned this in T451: Invitation handling.Jun 11 2015, 10:43 AM

If we can't restore this check somehow, the code and the comment above should be removed?
Or at least it should become a FIXME explaining why we had to disable this and how it should be fixed better

mollekopf added inline comments.Jun 12 2015, 1:20 PM

akonadi/calendar/scheduler_p.cpp
242–253	If we can't restore this check somehow, the code and the comment above should be removed? Or at least it should become a FIXME explaining why we had to disable this and how it should be fixed better
386–413	If we can't restore this check somehow, the code and the comment above should be removed? Or at least it should become a FIXME explaining why we had to disable this and how it should be fixed better