Avoid local changes after replication

Question

I have a Notes application that is used offline on a local replica most of the time. Users can create and update documents. On the server, an agent processes all new documents.

The idea is that - once the agent processed the documents - the users are no longer allowed to update the documents.

In general, this is quite simple to setup by setting author access on the documents processed by the agent.

But, because users work on the local replica and the agent runs on the server, this scenario is possible:

• user creates document offline
• replication of document (creating of doc on server)
• agent runs on server / user updates document locally
• replication of document (updating author access locally / updating changes on server) ==> Causes save conflict or inconsistent data

Is there a way to make sure that the user can no longer update a document once it is replicated to the server. Or is there a way to force the agent to run on replication and immediately replicate the access update?

I was thinking of creating a button the user can click to replicate/update all documents, but to avoid users that forget to click the button, I prefer the default replication settings to make sure everything is replicated when possible.

Answer 1

When I investigated a few years ago replication does a "pull", then a "push", so doing something on the server won't work. There are a couple of options.

1. A separate "flag" document which server processing updates, instead of updating the actual document. This would allow for updates causing a second set of processing.
2. Store a config document / environment variable with the last replicated date, and check against that in the Form's queryModeChange and queryOpen (if editMode). You can then prevent editing if the document was created before the last replicated date.

Answer 2

Instead of using Author fields for the "wrong" reason, I'd add a non-editable Status field, with values like "Initial", "Ready", and all the rest you might need. Then, replication should be set up differently, using a formula that only replicates documents with Status!="Initial". The user might have 2 buttons to save a document: one just saves to the local database and the other also changes the status to Ready. Once Status="Ready", the user can no longer modify the document.

By the way, did you set document replication to "Merge conflicts"? You might reduce the number of conflicts considerably.

Answer 3

One alternative would be to set up the form so that the user never actually saves the document locally. Instead, the document is emailed to the server where an agent triggered by mail delivery performs the actual update. When the agent is done with the update, it sends an email back to the user telling him/her that the updates are available and instructing them to replicate in order to retrieve them. If the Notes client is actually being used for email, you can probably even put a button into the email and say "Click here to replicate and open your document".