Merge Conflicts

Every vessel and the office run their own database, and the data transfer exchanges changes between them. For most records it is clearly defined who may change what and when, so the two sides never collide.

Audits and inspections are the exception: office and vessel may work on the same record in parallel. If both sides change the same record between two data transfers, that is a real conflict.

When the next transfer arrives, the newer version is kept and the discarded one is logged as a conflict. Nothing is merged automatically and nothing is thrown away — the discarded values are held as a snapshot until somebody decides what should happen.

What counts as a conflict

Only a genuine collision: both sides changed the same record after the last successful transfer. Edits that merely follow one another — one side this week, the other three weeks later — are ordinary replication and are not flagged.

Detection covers audit and task data. All other data follows field-level ownership rules during replication and cannot produce this kind of conflict.

Finding open conflicts

While conflicts exist, the User Dashboard shows a Replication Merge Conflicts entry. It is a summary grouped by data type with a count per type, so a large backlog stays readable instead of becoming one endless list. Show Details opens the individual conflicts of that type.

The entry has to be enabled per role in the User Dashboard configuration and requires the corresponding access right.

Deciding a single conflict

Opening a conflict shows:

• Conflict details — which record, its status, and who transferred it. Open Record opens the underlying task in its normal view; for other record types it lists the record's fields.
• Record context — the key fields in plain language, so it is clear what is being decided about.
• Local against remote — who edited the kept version and who the discarded one, with times and vessel names.
• Field differences — only the fields that actually differ. The kept local value is marked green, the discarded remote value red. A current value that already matches the discarded one is highlighted, meaning it has been applied and needs no action.

Then, per differing field, choose Use Local or Use Remote. The fields are independent — mixing them is the normal case, not an exception. When everything is decided, close the conflict with Mark as Resolved, or with Ignore if the remote change is deliberately dropped. Either way it stops counting on the dashboard.

A value chosen here is written back through the ordinary save path. That means it is stamped correctly and travels to the other side with the next transfer, like any other change.

Why automatic change stamps are not offered

Every record carries fields the system maintains itself — when it was last changed, by which user, from which vessel — plus the record's own identifier. These always differ when two sides touch the same record, because they describe the conflict rather than being the data in dispute. Choosing a value for them would have no effect, since they are set again on the next save. They are therefore left out of the field list. Who changed what and when is still visible, in the local-against-remote header above.

When there is nothing to decide

Sometimes the field list is empty and the view says only the automatic stamps differ. That is a normal outcome, not an error: both sides saved the same record, but no user data actually ended up different.

There is nothing to choose then — but the conflict still has to be closed with Mark as Resolved or Ignore, because the dashboard keeps counting it until somebody does.

A typical case

The office adds a corrective action to a finding. On board, the chief officer closes the same finding before the next transfer. After the transfer the conflict shows two differing fields. Take Use Remote for the corrective action text, so the office's addition survives, keep Use Local for the status, so the closure stands, and mark the conflict resolved.

Both resolving and ignoring record who decided and when, and stay visible in the history afterwards.