Has anyone come across a problem when using Reader & Author fields in an application (see below)
A user (userA) has access to a document and replicates the database locally.
They then have their access revoked by an administrator (on the server copy)
When replicating (logged in as userA) the document is not removed from the local replica.
However if I then login as a user with access to the document and replicate the change in security is made to the local replica, and switching id to userA means the document is no longer visible locally.
This however poses as serious problem as the users invoking the replication must be the user logged into the client (userA).
Subject: Issue with Replication when using Reader & Author fields
Once user A loses the rights to read the document on the server, his replication process cannot see that document on the server copy. Thus, it cannot replicate the new Reader Fields to the local copy to “lock” him or her out.
Indeed, I suspect that the replication process would consider that as the document exists in local, but does not seem to exist in server, it would treat is as a “new” document, and try to add it to the server copy. The server won’t allow that, as it does exist, and the user does not have access.
So, what should Notes do ? It cannot delete the local document as it does not see a deletion stub when replicating. It cannot update the Readers field to the new values as it cannot “see” the changed document. How would you expect it to handle this situation ?
Realistically, as they did have access when the document was first created, it could have been printed, or copied to a new database, or the user might simply not replicate at all. Fundamentally, once you give data to someone, you cannot take it back.