Ownership

What ownership means

Every strip has controller state that every client renders:

• owner: who currently controls the strip.
• next_controllers: controllers who are expected to take over next (handoff order).
• previous_controllers: controllers who have already held the strip.

In addition to those controller lists, the UI also renders pending handoffs from the backend coordination state:

• Normal transfers and tag requests appear as pending coordination until the server broadcasts completion (assume) or removal (reject/free).
• The frontend tracks this pending coordination in stripTransfers and clears it when it receives the relevant websocket broadcasts.

How ownership is shown in the UI

The SI indicator visualizes how your position relates to the strip:

• White: you are the current owner (assumed).
• Purple: you are in next_controllers but not the owner (concerned / next-up).
• Orange: your position is in previous_controllers (transferred away).
• Grey: you are neither owner, next, nor previous (unconcerned).

When a coordination is pending, the SIBox switch to split gradients to show:

• Sending: owner side of a pending transfer
• Receiving: target side of a pending transfer

Your station perspective

SAS1234

A320
OY-KAU

B19

TSAT CTOT

22R

Other station perspective

SAS1234

A320
OY-KAU

B19

TSAT CTOT

22R

Initiate a manual transfer

To initiate a transfer, use the TRF button in the command bar.

The, TRF button is only enabled when you are the current strip owner.

Owner side: sending / recall

While a transfer is pending and you are the sending owner:

• Your SIBox shows a white+orange sending-away split.
• Clicking the SIBox cancels the transfer.

When the strip clears the coordination (reject/free/assume), the SIBox returns to the normal assumed/concerned/unconcerned coloring.

Target side: receiving / assume

When a transfer is pending and your position matches the target:

• Your SIBox becomes clickable and clicking it calls completes the transfer.

Assuming without a pending transfer

Direct assume when unowned

If a strip is unowned (owner is empty) and your position appears in next_controllers, you can assume directly:

• Your SIBox shows the concerned (purple) state.
• Clicking it calls assume without creating a pending coordination first.

Tag requests (REQ)

A tag request uses the same pending coordination UI.

• The REQ button is only enabled when the selected strip is in Bay.Cleared, the strip is not unowned, you are not the current owner, and there is no active coordination.
• Pressing REQ sends coordination_tag_request.

While pending:

• The current owner side becomes clickable and clicking the SIBox calls acceptTagRequest.
• After acceptance, the pending tag request coordination is cleared by the normal lifecycle.

Force assume

FORCE ASSUME is the escape hatch when things get out of sync.

In the current frontend:

• FORCE ASSUME is a strip context-menu action
• when a validation is active, the same action is exposed in the Validation Status window because the blinking callsign no longer opens the context menu
• it is disabled when you already own the strip, or when there is an active pending coordination.

When allowed, the frontend calls forceAssumeStrip, bypassing the normal “next owner” constraint.