1. 04 Feb, 2020 1 commit
    • Timur Kristóf's avatar
      [libcontacts] Use libphonenumber for number matching. Contributes to JB#38835 · cdb00054
      Timur Kristóf authored
      This commit yields a significant improvement to how our phone number
      matching works. It gets rid of a lot of false positive matches.
      
      Previously we used a "minimized" number which we stored in the cache
      and used for matching. This lead to false positives between numbers
      for which the "minimized" number was the same when the full wasn't,
      for example when the area code of the number differs in only one digit.
      
      Examples of solved false positive matches:
      "+36 20 123 4567" and "+36 30 123 4567" were matched incorrectly.
      "+36 20 123 4567" and "+44 20 123 4567" were matched incorrectly.
      
      The new approach is to cache the full phone number and perform the
      matching between the full numbers using libphonenumber, which has
      a quite resilient algorithm for this. Local numbers and
      international direct dial (IDD) are still matched:
      
      Examples of local and IDD numbers that still work:
      "+36 20 123 4567" still matches "06 20 123 4567" (local)
      "+36 20 123 4567" still matches "00 36 70 381 0581" (IID)
      
      Limitations:
      We currently do NOT pass a default region code to libphonenumber,
      which means that some false positives can still occour in edge
      cases when a country code would be required to distinguish between
      the two numbers. This only happens when some numbers are supplied
      in a non-international format.
      
      Examples of remaining false positives:
      "06 20 123 4567" is a false positive match of "+1 0620 123 4567"
      "00 36 20 123 4567" is a false positive match of "+1 00 36 20 123 4567"
      
      We deem that the remaining false positives are unlikely enough that
      they don't matter in practice. If this becomes relevant, we will need
      to make it possible to pass a region code to the matching algorithm.
      cdb00054
  2. 29 Jan, 2020 2 commits
  3. 19 Nov, 2019 1 commit
  4. 03 Jul, 2019 1 commit
    • chriadam's avatar
      [libcontacts] Update section bucket index cache after deletions. Contributes to JB#46496 · c7112dae
      chriadam authored
      When a contact is deleted, we need to recalculate the section bucket
      index cache as that contact may have been the only contact in a given
      section bucket (display label group).
      
      However, since updating the section bucket index cache is an expensive
      operation, we should only do this once per bulk deletion, so this
      commit also adds support for bulk deletion operations.
      c7112dae
  5. 28 May, 2019 1 commit
  6. 16 May, 2019 1 commit
    • chriadam's avatar
      [libcontacts] Also update section bucket index cache during list... · 74aa135a
      chriadam authored
      [libcontacts] Also update section bucket index cache during list synchronisation. Contributes to JB#45836
      
      Batch updates are handled via list synchronisation.  We need to
      ensure that we update the section bucket index cache of any model
      after a list synchronisation occurs.
      74aa135a
  7. 30 Apr, 2019 1 commit
    • chriadam's avatar
      [libcontacts] Explicitly tell models to update section bucket index caches. Contributes to JB#45504 · 689011e6
      chriadam authored
      When contact data changes in the backend and we have pulled these
      changes into the model, we need to tell the attached models that
      they need to recalculate their cache of section bucket indexes.
      
      Note that we cannot have a single cache of section bucket indexes
      which the models read, as models can have a search filter applied
      which means the indexes of contacts in the seaside cache won't
      necessarily match what the model expects.
      689011e6
  8. 17 Apr, 2019 1 commit
  9. 15 Apr, 2019 1 commit
  10. 08 Mar, 2019 1 commit
  11. 30 Aug, 2018 2 commits
  12. 14 Nov, 2017 1 commit
  13. 10 Oct, 2016 1 commit
  14. 20 Mar, 2016 1 commit
  15. 04 Mar, 2016 1 commit
  16. 30 Oct, 2015 1 commit
  17. 26 Aug, 2015 1 commit
  18. 24 Aug, 2015 1 commit
  19. 19 Aug, 2015 4 commits
  20. 06 Aug, 2015 1 commit
  21. 04 Aug, 2015 1 commit
  22. 08 Apr, 2015 1 commit
    • chriadam's avatar
      [libcontacts] Run tests with privileges · 96732850
      chriadam authored
      The contact cache provided by libcontacts is intended for use by
      privileged applications only.  Its functionality does not make sense
      for non-privileged clients, and cannot be tested correctly when
      run in non-privileged mode.
      96732850
  23. 06 Mar, 2015 1 commit
  24. 05 Mar, 2015 1 commit
    • mvogt's avatar
      [libcontacts] Some scripts imply name token ordering · f4c2e52e
      mvogt authored
      For a specific set of character scripts, if a contact's first and last
      names are entirely composed of that script, then that (most likely)
      implies a cultural ordering for given/family name tokens that should
      override the device setting.
      f4c2e52e
  25. 16 Feb, 2015 1 commit
    • chriadam's avatar
      [libcontacts] Improve vCard contact import API · 813eafc0
      chriadam authored
      This commit improves the SeasideImport API by allowing clients to
      specify their own SeasideContactBuilder implementation when
      converting the list of Versit documents into storage QContacts.
      
      The SeasideContactBuilder allows the client to parametrise things
      like the contact filter used to determine the subset of mergable
      contacts, the merge strategy to use, and so on.
      813eafc0
  26. 12 Feb, 2015 1 commit
    • Richard Braakman's avatar
      [performance] Avoid resolving addresses multiple times · 4bfe8804
      Richard Braakman authored
      Parts of commhistory (GroupManager) will send a stream of
      resolve requests with many duplicates. This used to be
      tolerable because requests were handled slowly in the
      event loop, but now that they have higher priority it has
      become a problem.
      
      I went for the simple solution of ignoring requests that
      are identical to still-active requests (same uids, same
      listener, same requireComplete flag). It's not optimal (we
      could combine more requests into the same backend query if we
      tried), but it solves the problem without adding a lot of
      bookkeeping.
      4bfe8804
  27. 04 Feb, 2015 1 commit
  28. 01 Dec, 2014 1 commit
  29. 21 Oct, 2014 1 commit
  30. 17 Oct, 2014 1 commit
    • Richard Braakman's avatar
      [performance] Schedule resolveAddress immediately · e2ab0615
      Richard Braakman authored
      resolveAddress requests are done with one query at a time, in
      order to correlate the results with the looked-up addresses.
      Doing them sequentially via UpdateRequest events added a lot
      of overhead in the form of coordination between threads.
      
      This commit creates a dedicated QContactFetchRequest for each
      resolveAddress call, so that the events for starting them can
      arrive all together in the backend thread and the events
      announcing the results can arrive all together in the UI thread.
      They will still be processed sequentially, but this change cuts
      out the delay between finishing one request and starting the next.
      
      In tests with 10k contacts and a recent contacts list with limit=20,
      this reduced the resolve time from 1s to 0.3s.
      e2ab0615
  31. 15 Oct, 2014 2 commits
  32. 17 Sep, 2014 1 commit
  33. 12 Sep, 2014 1 commit
    • Richard Braakman's avatar
      [libcontacts] make sure UpdateRequest processing continues · ff84e74f
      Richard Braakman authored
      The logic for scheduling UpdateRequest events broke down when
      m_contactsToAppend went empty during a fetch request; even though
      more contacts were coming in through contactsAvailable, no more
      UpdateRequest events would be scheduled until the whole request
      was complete.
      
      Fixed by making m_updatesPending the definitive flag for whether
      there is an UpdateRequest event on the queue, rather than leaving
      it on during the whole fetch request.
      
      This change is safe because the flag was only inspected by the
      requestUpdate() helper and had no side meanings. Now all
      UpdateRequest event scheduling goes through requestUpdate().
      ff84e74f
  34. 26 Aug, 2014 1 commit