- Verschifft
- 7. August 2026 um 05:08 UTC
- Autor
- Kamo
- Ausschuss
- e6cb8fd
erstellenCustomer speicherte das Konto, bevor er seine Adressen schrieb, und war nicht transaktionale - also, wenn die Adresseinfassung fehlgeschlagen ist, das halb gebaute Konto blieb engagiert und jeder Retry ließ ein anderes Waisenkind zurück. Es ist jetzt @Transactional, und weil der Handler fängt seine eigenen Ausnahmen zu formen response (die den automatischen Rollback von Spring unterdrückt) markiert es die Transaktion Rollback-only explizit. Auch auf der Kundenoberfläche: - primäre MemberId wurde mit einem nackten FundById gesucht, so dass ein Anrufer eine Hand Mitglied von ANOTHER org Eigentum an und Abrechnungsrechte über, ein Konto in dieser. Es ist jetzt org-scoped, passende updateCustomerMitglieder, die bereits hat dies getan. - getAddresses und buildAccountSupary erstellt Antworten mit Map.of, die wirft auf einen Nullwert. Ein Konto ohne primäre Adresse ist die normale Fall, so GET /customers/{uid'/addresses war eine garantierte 500. - Ein unerkannter Währungscode bestand NULL anstelle der org-Standard. - Hinweis Autorschaft kam von der Antragsstelle, so war es fälschlich kommt von der Sitzung. - Die gesamte/Customer Oberfläche erforderte nichts anderes als eine gültige Sitzung. Irgendwie Mitglied könnte die Konten ihrer org erstellen, bearbeiten und löschen und umschreiben Kontokürzungen, einschließlich Rollen, die VIEW_ACCOUNTS nicht gewährt werden. Die **************** Rechte haben die ganze Zeit bestanden und sind es jetzt durchgesetzt, die MERGE_ACCOUNTS-Prüfung bereits in dieser Datei gespiegelt. POST/DELETE /leads/{id'/account hatte auch keine richtige Prüfung: eine Anruferhaltung nur VIEW_LEADS könnte das Konto auf einer Leine, die sie nicht öffnen, neu verlinken oder entkoppeln. und bekam einen unmaskierten LeadDTO zurück. Sie tragen jetzt die gleichen Tore wie updateLead und maskieren die Antwort durch LeadFieldMask. Ein fehlendes KontoId nicht mehr NPEs in einen 400 tragenden internen Text.