- शिप
- 7 अगस्त 2026 को 5:08 am बजे UTC
- लेखक
- Kamo
- Commit
- e6cb8fd
ग्राहक ने अपने पते लिखने से पहले खाते को बचाया और नहीं था लेन-देन - इसलिए जब पता डालने विफल हो गया, तो आधे-निर्मित खाता प्रतिबद्ध रहें और हर प्रत्यावर्तन ने दूसरे अनाथ को पीछे छोड़ दिया। अब @transactional, और क्योंकि हैंडलर अपने खुद के अपवादों को एक आकार देने के लिए पकड़ता है जवाब (जो स्प्रिंग के स्वचालित रोलबैक को दबाता है) यह निशाना बनाता है लेन-देन रोलबैक केवल स्पष्ट रूप से। इसके अलावा ग्राहक की सतह पर: - प्राथमिकMemberId को एक नंगे findbyId के साथ देखा गया था, इसलिए एक कॉलर एक हाथ दे सकता था ANOTHER org स्वामित्व का सदस्य, और बिलिंग अधिकार ओवर, एक खाता यह यह अब org-scoped है, जो पहले से ही अद्यतन CustomerMembers से मेल खाता है। ऐसा किया। - getAddresses और buildAccountSummary निर्मित प्रतिक्रियाओं के साथ Map.of, जो एक शून्य मान पर फेंकता है। कोई प्राथमिक पते वाला खाता सामान्य है ऐसा मामला, इसलिए GET / ग्राहक /{uid}/addresses एक गारंटी 500 था। - एक मान्यता प्राप्त मुद्रा कोड ऑर्ग डिफ़ॉल्ट के बजाय NULL जारी रहा। - नोट प्राधिकरण अनुरोध निकाय से आया था, इसलिए यह दुर्गम था; अब यह सत्र से आता है। - पूरे / ग्राहकों की सतह को वैध सत्र पर कुछ भी नहीं होना चाहिए। कोई सदस्य अपने ऑर्ग के खातों को बना सकते हैं, संपादित कर सकते हैं और हटा सकते हैं लेखाकार छूट, जिसमें भूमिकाओं को VIEW ACCOUNTS नहीं दिया गया है। The ************* सभी अधिकार मौजूद हैं और अब हैं इस फ़ाइल में पहले से ही MERGE ACCOUNTS की जांच को लागू किया गया। POST/DELETE/leads/{id}/account के पास कोई सही जांच नहीं थी। केवल VIEW LEADS खाते को एक लीड पर रीलिंक कर सकता है या नहीं खोल सकता है। और एक unmasked leaddto वापस मिल गया। अब वे अद्यतन लीड के समान गेट्स ले जाते हैं और LeadFieldMask के माध्यम से प्रतिक्रिया मुखौटा। लापता accountId अब नहीं NPE एक 400 आंतरिक पाठ ले जाने के लिए।.