Ask for precision about how works contact and calendar sync in sfos [answered]

Hi,

Some detailed information about this topic can be found at https://sailfishos.org/wiki/Contacts

Basically, SailfishOS uses a native SQlite3-based backend for the QtPIM API to store contacts. Unfortunately, it's based on what is now an old version of the QtPIM QtContacts API - and that version doesn't properly support separated addressbooks. This lack, combined with a UI decision which I will describe in more detail below, is a major cause of most of the issues with contact synchronisation, as contacts are currently separated in the backend via simple tags (in a field called QContactSyncTarget - a simple text field describing which account the contact came from), and heuristically aggregated together.

(The original design for the People application required that no intermediate prompts be required when creating a contact, and thus we couldn't explicitly ask the user which collection (i.e., account) the contact should be stored in. As a result, the backend has to be "clever" to determine which contacts from which sources are actually the same, and in determining which contacts to upsync where, when the contact is created on the device. Once we update our backend to properly support the separated collections in the new QtPIM QtContacts API, I will also ensure that we revisit this design choice...)

Currently, we don't sync any contact data from one online source with any other online source. This is because, originally, we had ToS requirements with one of the online providers, which prevented us from doing that at all. However, that online provider no longer supports contact synchronisation, so I suspect that this is no longer an issue (but I am not a lawyer...) Note that if you sync a contact from, say, CardDAV, and then modify it locally on the device, the local modifications will have "local device" ownership (and thus be eligible for upsync to other online services, not just the carddav server).

This also explains the behaviour of the backup function: it only backs up data which has "local device" ownership.

I don't understand your fourth point about the "share" function - it uses the same export method as the "backup" function, so the data should be identical.

Best regards, Chris.

@chris.adams i'm glad that you see the thread and of your answer.
That's for me clear that you cannot really be up to date for this ToS Requrements.
But maybe you and your team may give some technical tipps for better experience, on giving the optimal links between these providers and these providers. And tells diplomatically that between this one and this one, may be complicated.

for example, seems to me that

• exchange and webdav (caldav/carddav) are not share compatible because technically (bug or don't know what technical incompatibility), or ToS Requirement.
  
• Google cal+contact not share compatible with webdav, technically or ToS Requirement.
  

For the 4th point, i was able to fill all my contact in the vcf with the share function, that the backup was not able to do this. I explain you the context.
In 2014 i had a google phone, calendar and contact in google account.
Then i bought the jolla phone, and bound it to this account.
In 2015/2016 i decided to go away from google, and make a try with memotoo and fruux (to test). And it worked with both: But i was not satisfied from the both solutions. i created maybe some contacts into it. Last year i decided to synchronise with cozy and their webdav (you know the story and the issues). And i was never able to synchronise my contact with cozy. My vcf in backup was really short. around 50 contacts, normally i had near of 400.

Shortly i was able to clean my contacts, and share i out through may, and import again in sfos. Did you saw it?
Now sync works fine between sfos and cozy for the contact. but seems that exchange active-sync is blind for it with sfos. And active-sync is able to sync calendars but cozy not...
Shortly told. backup function ,and share function don't make the same things. But maybe my case is maybe a special one.
Do you see what i mean now? Thanks a lot for answering, and have a good continuation.

I think most of the issues you describe are simply due to our current (lacking) backend support for separated addressbooks. Once we implement that properly, you will be able to choose precisely which addressbooks should be enabled for synchronisation elsewhere (and to which specific accounts).

Unfortunately until we do that, there's not much advice I can offer. The backups will only contain data which is tagged as "local" data (i.e., data which was added manually on the phone).

@chris.adams thank you for your comment, which is quite interesting.
i had a feeling on this way but couldn't described it as you do. I find quite good that you feel where is the point of this issue.
Just a little question, for a short term, or transition.
Would it be possible and could help us having a kind of flags/tags by each contact which indicate in which account it has its entry? do you see what i mean?
Just for having (as user) an overview where (which account) is bound the contact (would include the sim card too). I would be interested on it until a the review that you've spoke about comes (seems to be planed for a far future).

You should be able to see that in the UI if you attempt to view the links for the contact (e.g., a linked contact will have various constituent contacts, each providing different data fields). But the UI won't say precisely which pieces of data come from which constituent, unfortunately - again, this is something that in the future will become much clearer once we have properly-separated addressbooks.