[Kde-pim] Seeking advice on how to fix bug 282346

[Stephan Diestelhorst]

On Tue, Sep 20, 2011 at 9:21 PM, Stephan Diestelhorst
<stephan.diestelhorst at gmail.com> wrote:
> Dear KDE PIM hackers,
>  I decided that I have moaned about PIM bugs long enough and
> started looking into https://bugs.kde.org/show_bug.cgi?id=282346
>
> Quick summary is that the calendar sends out event updates, on
> changing an appointment even though:
>
> * I am not the organiser of the event
> * I disabled Groupware communication to work around the issue
>
> Digging through the code, and using GDB, I confirmed the following
> flow of code (on 4.7.0):
>
>  bool IncidenceChanger::Private::performChange
>    ( Change *change ) at calendarsupport/incidencechanger.cpp:99
>
>  CalendarSupport::IncidenceChanger::Private::changeIncidenceFinished
>    (this=0xc81910,) at calendarsupport/incidencechanger.cpp:233
>
>  CalendarSupport::InvitationHandler::sendIncidenceModifiedMessage
>    (this=0x7fffffffcfc0,     method=KCalCore::iTIPRequest,
> incidence=..., attendeeStatusChanged=false) at
> calendarsupport/next/invitationhandler.cpp:374
>
> Interestingly, IncidenceChanger::Private::performChange
> (calendarsupport/incidencechanger.cpp) contains all the proper logic:
> it checks KCalPrefs::instance()->mUseGroupwareCommunication and then
> displays a message box, if I am not the organiser of an event, via
> InvitationHandler::handleIncidenceAboutToBeModified
> (calendarsupport/next/invitationhandler.cpp)
>
> However, it seems the logic has been duplicated and split to handle
> asynchronous Akonadi interaction through new Akonadi::ItemModifyJob(...)
> and then void IncidenceChanger::Private::changeIncidenceFinished( KJob *j ).
>
> That function does not check for the mUseGroupwareCommunication flag,
> nor does it present the user with a dialog box when he is not the organiser.
> Through handler.sendIncidenceModifiedMessage(...) which eventually
> ends up calling
>   ...
>    } else {
>      return d->sentInvitation( KMessageBox::Yes, incidence, method );
>    }
> sending out invitations, although the user is not the organiser nor has group-
> communication enabled and never has a chance to intercept.

After digging through current GIT, I have found that the code flow is
still present
that way. The two changesets that introduce this regression are:

commit d75ba75aea478f754b12f4a1c245dab2d4eb50d9
Author: Sergio Martins <iamsergio at gmail.com>
Date:   Sun Mar 13 21:10:36 2011 +0000

    Only ask to send invitations when the ItemModifyJob completes, and
not before.

    Otherwise we would be sending invitations when the job failed.

    Part of kolab/issue4096

commit d5b228631ecf89df4b9e3c9e3c4e8d866e72a11d
Author: Sergio Martins <iamsergio at gmail.com>
Date:   Sun Mar 13 21:04:35 2011 +0000

    New method, handleIncidenceAboutToBeModified() which contains the
invitation code
    that should be executed before the ItemModifyJob.

    If the user isn't the organizer, it asks the user if he really
wants to modify the incidence.

    Regarding invitations, there are questions that must be made
before the ItemModifyJob and
    questions that must be made after. Before this commit it wasn't
possible to make this distinction.

    Part of kolab/issue4096.

Sergio, could you comment on my observations?

Many thanks,
  Stephan
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/