Akonadi: Lookup Contact by UID Help please

[Daniel Vrátil]

On Thursday, 17 August 2017 15:18:45 CEST Klaas Freitag wrote:
> Am 18.04.2017 um 22:52 schrieb Daniel Vrátil:
> 
> Hi,
> 
> some other findings on this issue, which was fixed a while ago.
> 
> >> I reproduced the issue on a simple test case. the problem seems to be a
> >> combination of how we index the UID and your specific UID format - the
> >> dash- separated strings. All our unit tests only used simple UID strings
> >> (like "uid1"), which worked. Just changing the testcase UID to
> >> "abcd-efgh-1234-5678" broke the test. I'm looking into it now.
> > 
> > I pushed a fix to akonadi-search that should make searching by UID work.
> > If you want to have it locally, you can build akonadi-search from
> > Applications/17.04 branch locally for now, the patch will be present in
> > next bugfix release on May 11.
> 
> I realized that with Akonadi 17.04.3, the search again was not working.
> I found that akonadi-search, which is a separate package on my distro,
> was not installed, and installed it.
> 
> After that, the search still was not working. Also not after restarting
> Akonadi. I had to remove the addressbook agent in akonadiconsole and add
> a new one. After that it works again.

The fix for the issue required that everything is re-indexed by the Indexing 
Agent. I don't know why the re-indexing did not trigger for you after you 
installed akonadi-search, but I assume it might have been due to some left-
over configuration back from when you actually had akonadi-search installed.

For normal users upgrading to 17.04 should trigger re-indexing that would 
index the contacts properly, making the UID search work again.

Dan

> 
> Is there a possibility to find a more user friendly solution for this case?
> 
> Thanks,
> 
> Klaas
> 
> >> On Tuesday, April 18, 2017 9:07:20 PM CEST Klaas Freitag wrote:
> >>> Am 18.04.2017 um 12:01 schrieb Daniel Vrátil:
> >>> Hi Dan,
> >>> 
> >>> thanks for your help. We make progress ;-)
> >>> 
> >>>>> The UID that I have stored in Kraft is
> >>>>> df6748f1-c13d-438c-a4d3-86d395630f92. But look what delve is
> >>>>> retrieving
> >>>>> as the UID, it is kind of scrambled. The name rubilos markotiris makes
> >>>>> sense.
> >>>>> Can you explain that?
> >>>> 
> >>>> The "scrambling" is because for some reason, the UID is indexed as a
> >>>> plain
> >>>> text, so Xapian indexes each part of the UID independently (split by
> >>>> the
> >>>> dash- signs) an in arbitrary order. It means that you should be able to
> >>>> search for any contacts with UID that contains "438c", but that does
> >>>> not
> >>>> really make any sense and nobody will ever do it. We should fix this
> >>>> and
> >>>> only index UIDs as terms.
> >>>> 
> >>>> In Akonadi Console -> Browser open your contacts collection where the
> >>>> contact you are trying to search for exists and click the contact. In
> >>>> the
> >>>> lower part go to the "Internals" tab and check the "ID". It should say
> >>>> 3.
> >>>> If it does, then we have a problem somewhere in Akonadi.
> >>> 
> >>> That seems to be the case. The ID _is_ 3.
> >>> 
> >>> I tested something different and searched for the email rather than the
> >>> the UID, otherwise no change. That worked perfectly fine, the Contact
> >>> was returned.
> >>> 
> >>> So the problem seems to only exist when searching for UID.
> >>> 
> >>> Just a wild guess: Maybe there is a number versus string problem
> >>> somewhere in the underlying code? Maybe the UID is expected as numerical
> >>> type somewhere?
> >>> 
> >>> thanks,
> >>> 
> >>> Klaas


-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20170817/1b5efce5/attachment.sig>