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

[Stephan Diestelhorst]

Sergio,
  any update on the matter below?

Thanks,
  Stephan

On 21 September 2011 13:16, Stephan Diestelhorst
<stephan.diestelhorst at gmail.com> wrote:
> 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/