We have problems when users edit replication or save conflicts. Users get mixed up with local and server replicas etc. and as usual there is a save conflict with $conflict field in a database. Now, user opens this conflict document and saves it and $conflict field is lost!. Both documents are main documents after this, so there is no means to collect them in special view.
I asked IBM and this is normal way Notes works. For us it gives a lot of trouble because we use Notes as invoice handling system and after this kind of behaviour you have double invoices in system.
user opens this conflict document and saves it and $conflict field is lost!..I asked IBM and this is normal way Notes works.
Yes, that is the way it works. It’s a great feature, in that it allows you to decide to keep either the “winner” or the “loser” in a conflict situation.
So you’re saying that your users are editing conflict documents instead of resolving the conflicts first? Obviously, the best solution is for your users to stop doing that, since it’s the wrong way to deal with conflict documents, but if you’re asking how to protect your users from themselves and bulletproof the system against their mistaken behavior, I have some suggestions:
Enable document locking on the db to reduce the likelihood of conflicts in the first place.
Add a condition to your existing view selection formulas to exclude conflict documents, and add an additional view that does display them (along with their conflicting parent documents, of course). Assign one or more users to be responsible for managing replication conflicts when they arise, and give them access to the conflict view. You can optionally set up an agent (scheduled or update-triggered) to notify these users when a conflict occurs.
Download one of the many versions of the Difference Of Two Documents agent which are floating around all over the place – for example the one in the sandbox – and let your conflict-managing users use that to make the task of conflict resolution much, much easier.