LocalDataStore query doesn't support Role in Object's ACL

[bayareahank]

I found this out while investigating a whole group of objects that were pinned successfully but then missing in subsequent queries, as I mentioned in #535

I checked the local datastore using sqlite DB viewer, the data is indeed stored in local cache. Then I found out the reason why they don't show up in queries, they all use role based ACL, and didn't list the current user explicitly in object's ACL. So while current user has role that enables access to data from DB/server side, local datastore doesn't acknowledge that role in query. On a second check, indeed all the objects in local data store that has role based ACL but without mentioning current user id explicitly are skipped in query, except those set to readable publicly.

The work around this is pretty straight forward, you simply add an entry in the object ACL to make it readable to current user explicitly, before pinning it. BTW, you may need to adjust ACL of includedKeys objects as well, to make local query working. Pin and unpin objects are tested not impacted by this missing feature.

  acl.setReadAccess(true, for: currentUsr)

Not sure whether people have found this before, or my setup is triggered by an accident (I use release 1.17.3, swift 5.2.2, xcode 11.4.1, built for iPhone). But this thing is potentially pretty big, especially at a time that people pay stronger attention to privacy.

I also suspect that "Not supported in offline cache" bug I mentioned in #535 is related to this. The object is readable to current user, yet it includes a pointer to another class of object, which is readable to user by role, but didn't mentioned current user explicitly in its object ACL, thus rending the whole read process failed for that type of data when querying local data store.

[bayareahank]

Turns out the correct way to have role support in localstore is to set role public readable, as below:

   roleACL.setPublicReadAccess(true)

Without this, role won't work in local store query.

Earlier on I was worried that making role readable publicly may leak its members, I verified from client side that reading role members would only return none other than the inquirer itself, if the user has the designated role. So considerations has been taken in avoiding leaking.

Closing this issue. It would help to dress this in the document.