Re : Re: "Open Invitations" and akonadi_search_resource

Le dimanche 17 juillet 2022 à 4:20 PM, Sandro Knauß <[email protected]> a écrit :

> Hi,
>
> > I suppose the akonadi_search_resource was supposed to display these
> > invitations so the filter model made sure we didn't display the invitation
> > twice. But since this resource disappeared/broke, we now don't have any
> > invitations displayed anymore.
>
>
> The akonadi_search_resource is not broken - you can check it via
> akonadiconsole, that there you find invitations. The search resource is
> relaying on the Akonadi Search and you can see it as a persistent search. You
> can see the query string, if you go to Interals tab in akonadiconsole in
> folder properties.
>
> The main reason for this persistent search is, that you may want to show
> invitations in an different color and to always see them even if the calendar
> is not displayed. If you read an email of an invitation in kmail the
> invitation is automatically added to you default calender. You can answer the
> invitation later via KOrganizer and don't need to to this in KMail.

Thanks for the background on how this is supposed to work. I agree that this
seems to be the ideal way to do it.

Now it seems that something is not working correctly for me (and a few other
people) as the internal tab in akonadiconsole is empty. (see attached screenshot)
For me, the collection also appears empty in korganizer and I'm pretty sure I got
a lot of invitations to work meetings (too many in my opinion).

I will try to debug this locally, now that I have some overview this might
be easier ;)

>
> > I wonder if we shouldn't just change the condition in
> > calfilterpartstatusproxymodel to by default only hide invitations where we
> > are attendees and that we explicitly declined and maybe add an API to
> > display all invitations (in case the user wants to also see the declined
> > invitations).
>
>
> Why to add another API? You can define the mBlockedStatusList and you have
> Akonadi Search that gives you all exactly what you what to have ;)

Yeah but I have no idea how to access the internal calfilterpartstatusproxymodel
it seems to not be exported and is only available as an implementation detail of
the ETMCalendar.

> The only difference is, that the collection is a virtual one (isVirtual=True).
> That implies that parentCollection != storageCollection. For virtual one the
> parentCollection is the search folder and the storageCollection is pointing to
> the collection, where the event is stored.
>
> Btw. the proxy model makes sure that events comming from virtual collections
> (like this Open Invitations collection) are always displayed:
>
> https://invent.kde.org/pim/akonadi-calendar/-/blob/master/src/
> calfilterpartstatusproxymodel_p.cpp#L91
>
> Maybe we need to move the SearchCollectionHelper, that take care about the
> search query, to a place where also kalendar can use it:
>
> https://invent.kde.org/pim/korganizer/-/blob/master/src/helper/
> searchcollectionhelper.h

Yeah akonadi-calendar, seems like the ideal place for this as it does not relly
on QWidgets. I'll submit a PR once I get a better overview of why the stuff
is not working locally and hopefully have a fix for it ;)

Thanks,
Carl

>
> Cheers,
>
> Sandro