Očista hardcoded identity přesměrovala podpisové SMS OTP na obecnou firemní linku

import { Aside } from ‘@astrojs/starlight/components’;

Při nahrazování hardcoded hodnot konfigurací mapuj každou hodnotu na sémanticky správný klíč — „mobil podepisující osoby" není „telefon firmy"; pro SMS OTP vždy dedikované pole s validací mobilního čísla.

Symptom

Elektronický podpis smlouvy (SMS OTP přes e-signature službu) přestal fungovat pro podepisujícího za zhotovitele: ověřovací SMS chodila na špatné číslo. Klientská strana podpisu fungovala dál — bug se projevil jen u druhého podepisujícího, takže si ho nikdo nevšiml hned po deployi, ale až při dalším reálném podpisu.

Root cause

Při transformaci single-tenant aplikace na multi-tenant SaaS proběhla „očista identity” — všechny natvrdo zapsané firemní údaje (e-maily, telefony, název) se nahradily hodnotami z konfigurace tenanta:

// Před (single-tenant, hardcoded):
signers.push({ role: "owner", mobile: "+420XXXXXXXXX" }); // osobní mobil jednatele

// Po refactoringu (multi-tenant):
signers.push({ role: "owner", mobile: company.phone }); // ← obecný telefon firmy!

company.phone je ale veřejný kontaktní telefon firmy (tiskne se na nabídky a faktury) — nikoli mobil osoby, která smlouvy podepisuje. V konfiguraci navíc zůstal placeholder z výchozích hodnot. Refactoring byl typově i funkčně „správně” (kód prošel testy, obálky se vytvářely), jen SMS chodila jinam.

Fix

Dedikovaný konfigurační klíč pro mobil podepisující osoby s fallbackem:

// CompanyInfo rozšířeno:
executivePhone: map.company_executive_phone || map.company_phone || "";

// Routy vytvářející podpisovou obálku:
ownerPhone: co.executivePhone, // dřív co.phone

Plus pole v administraci (Nastavení → Fakturační údaje) s vysvětlivkou, k čemu číslo slouží, a naplnění správné hodnoty do DB všech dotčených tenantů.

Poučení

• Hardcoded hodnota nese implicitní sémantiku (čí číslo, k čemu slouží), která se při mechanickém nahrazení konfigurací ztratí. Před náhradou si u každé hodnoty odpověz: co přesně tahle konstanta reprezentuje?
• SMS OTP kanály jsou tichý failure mode — API vytvoření obálky uspěje, chyba se projeví až u příjemce SMS. Do E2E testů patří i assert na payload příjemců (číslo, e-mail), ne jen na úspěch vytvoření.
• Konfigurační pole pojmenovávej podle role („mobil jednatele pro SMS ověření”), ne podle typu („telefon 2”).