- Shipped
- August 26, 2026 at 7:25 PM UTC
- Author
- Kamo
- Commit
- 07db639
The folder every logo, colour, favicon and background is written to was the organization's hostname with the dots turned into dashes. A domain is optional now, so that could not name a folder for an organization that had not brought one — and the failure was silent in both directions. Uploading a logo was refused with "No domain configured for this organization"; reading one fell through to the platform's folder, so the customer saw Kamo's branding over a workspace whose own was provisioned and unreferenced. The folder is the organization's ALIAS, which is mandatory, unique, and already shaped like a path segment. See OrgThemeAssets in kamo-shared-library. What this changes here: - provisionFull/provisionUpdate take the organization and derive the folder from it, so a caller can no longer direct one organization's branding into a folder named after something else. provision-theme's `domain` field is ignored. - upload-logo, commit-backgrounds and provision-theme stop refusing an organization that has no domain. - The workspace picker's per-row logo drops two correlated string_agg subqueries per organization — they existed only to work out which folder each one's branding had been provisioned into, and the alias is on the row already. - The sign-in redirect NAMES the organization (&org=<alias>). internal.<apex> serves every organization without a host of its own, so a tab arriving with only a one-time key resolved the host, got the platform, and painted Kamo's logo over the workspace the member had just signed in to. enter-as had been fixed to say so; the ordinary sign-in had not. It is a reference, not a credential, and an alias that cannot be read never blocks the sign-in. - Members' virtual backgrounds stop deriving their folder from the request host, which answered "kamocrm-com" for every subdomain tenant — so a child organization's backgrounds were written into, listed from and DELETED out of the platform's folder. - The storage sweep attributes both prefixes, so a migrated organization's branding usage does not appear to halve overnight. ThemeFolderMigrationService copies each organization's assets into its alias folder at boot. Copies, never deletes: there is no safe moment to remove the old keys — a tab open across the deploy, a cached email, a quote PDF already sent all still reference them — and the cost of getting it wrong is every white-label customer's branding vanishing at once. Idempotent, and a MinIO blip must not stop the service starting. Already run against production: 14 organizations, 298 objects, all serving. OrgAliasPolicy is the third piece, and the one that matters most now the alias is a path segment. The shape rule was only ever applied by the availability endpoint the wizard calls as the field is typed — the create endpoint checked duplicates and all-digits and nothing else, so any caller that skipped the wizard could store an alias holding a space, a dot or a slash. It also reserves the labels the platform serves, because an organization aliased "theme" would answer at the host every tenant reads its assets from; and the bucket prefixes that belong to no organization, of which "default" is the dangerous one: the base theme every organization is seeded from, which such an organization's saves would rewrite. Verified against a clean checkout of main plus only these files: 1418 tests, 0 failures. No existing organization holds a reserved or malformed alias.