One-Way Calendar Synchronization

One-way synchronization copies the Primary calendar onto the Secondary calendar. Primary is the only side that writes. An edit made on Secondary is replaced by the Primary copy on the next pass. An event that exists only on Secondary, and was never linked to Primary, stays where it is.

The mode applies to calendar synchronization. Contacts and presence keep their own sync. One-way mode chooses who wins a calendar conflict. It does not choose Initial, Incremental, or BadSyncTokens. That choice is made by Scenario Selection.

These settings are read once at startup. The service reads appsettings.json, then appsettings.{Environment}.json, then exactly one environment file. It uses the first file it finds: .env.Development, then .env.development, then .env. An empty line in that file leaves the previous value in place. Restart the service after a change.

Turn one-way sync on

One-way mode is Service__SyncDirection=1. 0 is two-way, and it is the default. Service__SyncType stays 0 or 1. 2 is invalid: the service stops at startup and logs that one-way moved to SyncDirection.

SyncType selects the two-way copy. With SyncDirection=1 the one-way branch runs for both 0 and 1, so Sensitive scrubbing stays on the two-way Sensitive path. Presence has its own direction and does not read Service__SyncDirection.

The writer is the higher-priority client in the pair. The pair’s Source and Target labels do not choose the writer.

Parameter	Meaning & Usage	Example	Applies To
`Service__SyncDirection`	`0` = two-way, `1` = one-way.	`1`	Docker, Binary
`Service__SyncType`	Content of a two-way copy. `0` = Full, `1` = Sensitive.	`0`	Docker, Binary
`EventSyncClients__0__Priority`	Conflict rank of client 0. Smaller wins, including negative numbers. Set an integer on every client.	`0`	Docker, Binary
`EventSyncClients__1__Priority`	Conflict rank of client 1.	`10`	Docker, Binary

If every client has an integer Priority, the smaller number writes. Equal numbers: the smaller client index wins. If any client has no Priority, or the value is not an integer, every client is ordered by its index instead. Index 0 then writes onto index 1.

Exchange writes, Nextcloud receives, because Exchange is client 0 and no Priority is set:

Service__SyncType=0
Service__SyncDirection=1
EventSyncClients__0__Identifier=ews
EventSyncClients__1__Identifier=dav

Nextcloud writes, because its Priority is smaller:

Service__SyncType=0
Service__SyncDirection=1
EventSyncClients__0__Identifier=ews
EventSyncClients__0__Priority=10
EventSyncClients__1__Identifier=dav
EventSyncClients__1__Priority=0

After a restart, the startup log contains a === Startup === block with Service:SyncDirection and an EventSyncClients priority section. The first client in that list is the writer.

What happens to an event

Situation	Result
The event is linked on both sides	Secondary is updated with the contents of Primary. The Secondary identifier is kept
The event exists only on Primary	A copy is created on Secondary.
The event exists only on Secondary and has no link to Primary	The event stays. It is not created on Primary and it is not deleted.
The mailbox owner is not the organizer	Secondary receives a personal meeting. Attendees and their responses are written into the description as `email [Accepted]`, `[Tentative]`, `[Declined]`, or `[Awaiting]`. The owner's own response is added as a title prefix. The attendee list is cleared, and the mailbox owner becomes the organizer.

Initial, Incremental, and BadSyncTokens

Scenario Selection has already chosen the scenario before these rules run.

Initial is a full snapshot. A linked pair is aligned to Primary even when neither side is marked as changed. An event that exists only on Secondary is left in place, including a Secondary event that still points at Primary. Counterpart deletion is not applied in Initial.

Incremental looks at which side actually changed. A copy the service has just written is not treated as a new edit.

Situation	Result
Neither side changed	The pair is skipped.
Only Secondary changed	The Secondary edit is rolled back. Primary is written to Secondary again.
Primary changed, or both sides changed	The current contents of Primary are written to Secondary. Primary wins.
Primary was deleted	The copy on Secondary is deleted.
Secondary was deleted	The copy is created again on Secondary from Primary.
A new event appears only on Primary	It is created on Secondary.
A new event appears only on Secondary	It stays on Secondary.

BadSyncTokens is a full snapshot after a bad or incomplete sync token. Linked pairs are aligned to Primary the same way as in Initial. A Secondary event that refers to a Primary event which is no longer in the snapshot is deleted. If Primary remains and Secondary is missing, the copy is created again. If only Secondary remains, that copy is deleted.