[4.0.1.45] Non-jailed contacts SQLite database no longer updated

Bug Reports
#1

REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product): 4.0.1.45
HARDWARE (Jolla1, Tablet, XA2,…): XA2 Ultra, X
UI LANGUAGE: German
REGRESSION: (compared to previous public release: Yes, No, ?): Yes

DESCRIPTION:

The file ~/.local/share/system/Contacts/qtcontacts-sqlite/contacts.db is no longer updated after the upgrade to SFOS 4. I suppose that the new contacts database is now persisted at ~/.local/share/system/privileged/Contacts/qtcontacts-sqlite/contacts.db, but as long as third-party apps can’t use Sailjail (see https://github.com/sailfishos/sailjail-permissions), some devs like me need an up-to-date contacts database. :wink:

PRECONDITIONS:

None

STEPS TO REPRODUCE:

  1. Open Contacts
  2. Change an arbitrary contact (e.g. first name)
  3. Open the SQLite database at ~/.local/share/system/Contacts/qtcontacts-sqlite/contacts.db with the tool of your choice, search for the entry in the table Contacts. See that the old name is still there.

If you want to be 100% sure that it’s not persisted, you may do a restarted between 2) and 3) - no changes on my devices…

EXPECTED RESULT:

  • The database is updated properly

ACTUAL RESULT:

  • Database content is not updated and becomes stale

ADDITIONAL INFORMATION:

As the files contacts.db-shm and contacts.db-wal were there at least on one device, I suppose that the database is actually loaded and you may even try to update it. It could even be related to the obvious schema change between SFOS 3.4 and SFOS 4 as I noticed several differences (e.g. less columns in the table Contacts).

10 Likes
[4.0.1.45] Hundreds of contacts lost after update
Whisperfish - The unofficial SailfishOS Signal client
#2

Whisperfish is affected too, thanks to @Nokius for finding that out!

3 Likes
#3

i have a similar problem too, incoming call numbers cannot be identified against my stored contacts, somehow the country code prefix is not added to find the match.

1 Like
#4

I’m having a look in Whisperfish for this problem. Entering the jail isn’t too difficult (see link down below), but it’s not right yet:

  • You need the Privileged permission on top of the Contacts permission, because the database is in a privileged directory.
  • the FireJail/SailJail interface is not stable, as emphasized by @abranson on IRC
  • I needed to add my own permission in order to open the .local/share/harbour-whisperfish data storage. Probably we’re meant to migrate that with a oneshot systemd service on boot or something, to .local/share/my-org/harbour-whisperfish, but that’s not very nice. I wonder what Jolla does with their own apps for this.

Aside from that, the schema indeed changed a lot. I’ll probably be calling into the com.jolla.contacts.ui dbus interface soon now.

3 Likes
#5

@Ygriega using org.nemomobile.contacts/PeopleModel 1.0 from QML is quite simple and works very well. On 4.0, you need to enter the SailJail though, and that means making two separate launchers if you want to keep 3.4 compat.

For contact lookup, I’ve been using the RecipientField from the non-official/unstable Sailfish.Contacts since 3.3, and still works. This might be a work around for you too :slight_smile:

#6

Thanks for the research and the tips. but only accessing DBus might be an option as Sailjail is not yet final and the Nemo contacts model is not allowed for Harbour, see https://github.com/sailfishos/sdk-harbour-rpmvalidator/blob/harbour-qa/allowed_qmlimports.conf

As long as we’re in EA, I’m still waiting for Jolla to comment on this issue here. Keeping the database in the filesystem with stale content doesn’t make any sense from my perspective, so I suppose, they need to react accordingly. We’ll see what happens…

1 Like
#7

Had no clue that accessing the Sqlite was permitted in Harbour! Then of course non of my research really applies to you, sadly. Let’s hope they provide us with a real solution indeed. I’ve in the meanwhile made the necessary changes in Whisperfish (including the jail…)