- Ya
- 24 Agosti 2026, 23:35 UTC
- Mwandishi
- kamo
- Ahadi ya
- b76247a
getThemePath() derived the theme base from window.location.hostname. That answered the right question while every organization had a hostname of its own — and for a custom-domain tenant it still does. On the shared host it does not: every organization without a domain is served from internal.kamocrm.com, so all of them were painted in the platform's branding, reading logo, colours and config.json out of the platform's MinIO folder. The org context now records its domain per tab (sessionStorage, like the session id — two orgs can be open in two tabs and each paints its own), and getThemePath() prefers it, falling back to the hostname when none is known: first paint, or a page with no org context. That fallback is what every call did unconditionally before. Nothing that already worked moves. The platform org resolves to **************** and a custom-domain tenant to theme.acme.com/public/acme-com — byte-identical to today, and pinned by tests. The only answer that changes is the one that was wrong. A recorded domain is used AS GIVEN, not run through the alias-stripping the hostname path uses. It is already an org FQDN: stripping its first label would turn crm.kamocrm.com into kamocrm.com and gnosia.demo.kamocrm.com into the parent apex, so each org would read its branding out of another org's folder. Blank values and bare alias labels are ignored rather than recorded, since either would build a URL that resolves nowhere. Recorded during render, not in an effect: components call getThemePath() while painting on first commit, so an effect would land after them and the branding would visibly change. The folders exist by construction — OrgThemeProvisionService already names a domainless org's theme folder from resolvePrimaryDomain's {alias}.kamocrm.com fallback, which is the same value this records. 2921 tests pass. The production build is deferred to CI; other sessions hold the Next build lock continuously (6 concurrent builds).