- Shipped
- 25 agosto 2026 alle ore 00:56 UTC
- Author
- Kamo
- Commit
- e3daede
La creazione ha controllato l'alias solo all'interno di un fornitore di sicurezza, e PUT /org/{id} non ha controllato nulla — ha applicato tutto ciò che è stato dato. Entrambi erano ragionevoli mentre un alias è stato risolto solo come (security provider id, alias) dietro un host <alias>. ?org= l'ha cambiato. Un'organizzazione può essere nominata direttamente dal suo alias con nessun fornitore per la ricerca, quindi una ripetizione fa ambiguo il riferimento piattaforma-wide: OrgResolutionService lo rifiuta piuttosto che sceglierne uno, che lascia le organizzazioni BOTH irraggiungibile da alias. Un rinomina attraverso PUT potrebbe farlo silenziosamente a un org che in precedenza andava bene. Inoltre rifiuta un alias all-digit su entrambi i percorsi. Un riferimento a cifre si risolve come un'organizzazione id e non cade mai attraverso alla ricerca alias, quindi un tale alias non potrebbe mai nominare la propria organizzazione — meglio rifiutarla che rifiutarla creare qualcosa di irraggiungibile. Le ripetizioni esistenti sono lasciate da sole: quattro org condividono "acme-corp" e due Condividi "kia-kaha", tutti seme lo stesso giorno. Un alias è una chiave inquilino — esso nomi cartelle a tema e <alias>. host <domain> — in modo da rinominare quelli dal vivo è non qualcosa da fare unilateralmente. Il risolutore rifiuta già il quelli ambigui, quindi niente si risolve male nel frattempo. Verificato su un clone pulito: 951 test passa. L'albero di lavoro attualmente fallisce 63 test non correlati dal lavoro PHI di un'altra sessione (a PhiTenantResolver che non è ancora cablato nei loro test).