[deployer] Move a member between existing organizations, with a clear preview of what changes #301

New issue

Open

opened 2026-06-17 14:51:01 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-06-17 14:51:01 +00:00

Owner

What to add:

A "Move to organization" action on any organization card, not just Unassigned, that lets you pick the selected members and choose a target from a list of existing organizations (plus a "new organization" option), reusing the existing assign call.
Replace the free text target box with that picker everywhere the move is offered, so choosing an existing organization is a pick, not a retype.

Why it needs care (what a move actually changes):

A move by itself is non destructive. It only changes which organization a member belongs to and does not touch the running instance, so nothing breaks at move time. But an organization is the source of truth for a member's installed apps, release channel, provider keys, and email, resolved at the next install or update. So the first time the operator runs "Update all instances" on the new organization (or the member is reinstalled), the member adopts the new organization's stack and settings. That can add or remove installed services, switch the member's release channel, or leave a provider without a key if the new organization does not supply one.

Decisions to settle when we build it:

Show a clear note when moving: the member keeps running as is and adopts the new organization's stack and settings on its next update.
Decide whether the move stays purely deferred (the new config follows on the next "Update all instances") or also offers to update the moved members into their new organization right away.
When moving, also re-tag the member's stored stack and release channel to the new organization's values, the same way renaming an organization already re-tags its members, so the stored tags do not go stale.
Optionally warn before confirming if the new organization would leave a previously working provider without a key, or would drop a currently installed app.

The non destructive default means we can ship this in steps: the move action plus the picker plus the consequence note first, then the optional immediate update and the key and app warnings.

Priority: tracked for after the current Launcher roadmap (the Overview landing page, the admin console link, co user invite, per network wallets, then the hero_os and hero_office service integrations). Track now, build later.

Part of the Launcher work in lhumina_code/home#291.

Today an operator can move members into an organization only from the Unassigned view, and the target is a free text name rather than a pick from the existing organizations. Now that every new deployment lands in a real organization, the more common need is moving a member from one existing organization to another. The move engine already exists (the assign-members-to-organization call moves a member, retags their instances, and creates the target organization if it does not exist), so this is mostly a UI addition plus making the consequences explicit. What to add: - A "Move to organization" action on any organization card, not just Unassigned, that lets you pick the selected members and choose a target from a list of existing organizations (plus a "new organization" option), reusing the existing assign call. - Replace the free text target box with that picker everywhere the move is offered, so choosing an existing organization is a pick, not a retype. Why it needs care (what a move actually changes): A move by itself is non destructive. It only changes which organization a member belongs to and does not touch the running instance, so nothing breaks at move time. But an organization is the source of truth for a member's installed apps, release channel, provider keys, and email, resolved at the next install or update. So the first time the operator runs "Update all instances" on the new organization (or the member is reinstalled), the member adopts the new organization's stack and settings. That can add or remove installed services, switch the member's release channel, or leave a provider without a key if the new organization does not supply one. Decisions to settle when we build it: - Show a clear note when moving: the member keeps running as is and adopts the new organization's stack and settings on its next update. - Decide whether the move stays purely deferred (the new config follows on the next "Update all instances") or also offers to update the moved members into their new organization right away. - When moving, also re-tag the member's stored stack and release channel to the new organization's values, the same way renaming an organization already re-tags its members, so the stored tags do not go stale. - Optionally warn before confirming if the new organization would leave a previously working provider without a key, or would drop a currently installed app. The non destructive default means we can ship this in steps: the move action plus the picker plus the consequence note first, then the optional immediate update and the key and app warnings. Priority: tracked for after the current Launcher roadmap (the Overview landing page, the admin console link, co user invite, per network wallets, then the hero_os and hero_office service integrations). Track now, build later. Part of the Launcher work in https://forge.ourworld.tf/lhumina_code/home/issues/291.