[deployer] Edit a saved organization in place (setup, name, roster) #295
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/home#295
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Right now a saved organization can be created and have its settings and members changed (add a member, move members between organizations, edit its own keys and email sender), but the organization composition itself cannot be edited in place. Save only creates a new organization (it refuses to overwrite an existing one so it never clobbers the roster), there is no way to change which setup an organization uses, and there is no rename. We should add a first class edit for a saved organization so an operator can, for example, switch its setup or rename it without recreating it. This came up alongside the node group edit work just shipped (a node group can now be edited after creation, and its definition grows as an organization takes on more members); see #291 .
Expanding the scope: editing an organization in place should centre on its setup (the stack of apps plus its channel and keys), not only its name and roster. The flow we want: open an organization's settings, pick or change its stack template (Core, Default, Full, or a saved setup) and tweak the individual apps (for example add a newly available service to the bundle), save, then Update all instances reinstalls every member of that organization with the new app set so the new service lands everywhere. Today an organization records a setup label but Update all instances only re-pulls the latest build on the same channel and preserves the already installed apps, so changing the app set does not propagate. The main design choice is whether an organization owns its own effective stack (seeded from a template, then edited per organization) or just references a shared saved setup; the per-organization-owned model matches the example above (edit this organization's bundle, update this organization) without touching others. This needs server work (store and resolve the per-organization app set, and have the per-organization Update all instances pass it to install), so it is a proper next step rather than a UI tweak.
Refining the model from the discussion. The Setups page becomes two clear actions: create a new setup, or pick an existing setup to view and edit its parameters (apps, release channel, assistant keys, welcome email). The per row "Use in a deployment" button is removed (deploying happens from Organizations), clicking a setup row opens it for view and edit, and a setup can be duplicated and renamed so you can fork a variant. An organization references a saved setup by name (shared, not copied): you choose the setup when deploying, and the organization's settings show which setup it is based on with a quick link to edit that setup. To give one organization a variant without affecting another that shares the same setup, you clone the setup, rename it, adjust it, and point that organization at the clone. Update all instances of an organization then reinstalls its members with that setup's current apps, so adding a service to the setup and updating the organization installs the new service on every member. Resolved design: organizations reference shared setups and you clone to diverge, rather than each organization owning a private copy.
Resolved model (locked with the operator), superseding the shared-reference note above. Vocabulary: a stack is the list of services; configs are the operational settings (release channel, welcome email, which assistant providers, email sender, API keys); a setup is a stack plus its configs. General Settings on the deployer holds the default configs and an organization overrides them. Secrets vs selections: a setup stores only the non-secret selections (release channel, welcome-email on or off, which assistant providers are enabled), while the secret values (the actual API keys, the Resend key, the email sender address) live in General Settings as the default and are overridden per organization. So a setup is safely cloneable and reusable because it never carries a secret; the real keys come from General or the organization override (this is how the seed-providers model already works: a setup ticks providers, and only providers with a configured key are applied). Ownership: each organization owns its own setup. Creating an organization auto-creates a setup named after it (Acme creates the acme setup), seeded from a chosen template or preset; the organization owns and edits that setup independently, so editing it affects only that organization. To make a second organization that is like the first plus a service or a different selection, you clone the first organization's setup, rename it, and adjust it. Propagation is operator-triggered: editing a setup changes its organization's members only on the next Update all instances, never in the background. Deleting a setup that an organization still uses is blocked until it is reassigned or cloned. Build order: Setups page (create new, click a row to view and edit, duplicate and rename, remove the per-row use-in-deployment button); then organization owns a setup (auto-created and named at create); then the organization Settings shows the setup it is based on with an edit and switch shortcut; then Update all instances reinstalls members with the organization setup's current stack so added services land everywhere.