Hamkor login berish/uzish (`supplier.manage_credentials`)

team-lead-pm yangiladi

Yangilandi: estimate_hours

team-lead-pm yangiladi

Yangilandi: estimate_hours

team-lead-pm yangiladi

Yangilandi: estimate_hours

finalize-ep-03 yangiladi

Yangilandi: pr_url

qa-ep-03-t05-s01 statusni o'zgartirdi Review → Bajarildi

qa-ep-03-t05-s01 izoh qoldirdi

QA (qa-EP-03-T05-S01) — mustaqil tekshiruv, commit 517281a. Testlar (o'zim yurgizdim, tor doirada, qulf ostida): SupplierCredentialsControllerTest — 15/15 yashil (Tests run: 15, Failures: 0, Errors: 0). MUTATSIYA TEKSHIRUVI (ikkalasi ham testni YIQITDI = testlar yolg'onni ushlaydi): (a) SupplierCredentialsController.java:41,51 dagi @RequirePermission("supplier.manage_credentials") olib tashlandi -> grantWithoutManageCredentialsPermissionReturns403 va revokeWithoutManageCredentialsPermissionReturns403 ikkalasi ham yiqildi (expected: 403 FORBIDDEN, but was: 201/204). Ya'ni test annotatsiya borligini emas, haqiqiy HTTP javobini tekshiradi. (b) 409 himoyasi bosqichma-bosqich olib tashlandi: b1 — SupplierCredentialsService.java:153 dagi existsByUserId pre-check o'chirildi -> test BARIBIR YASHIL qoldi, chunki DB uq_suppliers_user_id + saveAndFlush try/catch (service:182-188) 409 USER_ALREADY_LINKED ni qaytardi. Bu defekt emas, ikki qatlamli himoya (defense-in-depth) ishlayotganining isboti. b2 — pre-check + DB-daraja catch IKKALASI ham o'chirilgandan keyin grantWithUserAlreadyLinkedToAnotherSupplierReturns409 yiqildi (expected: 409 CONFLICT, but was: 500). Mutatsiya o'ldirildi. Har ikki mutatsiyadan keyin fayllar `git checkout -- <fayl>` bilan tiklandi; ishchi daraxtda mutatsiya qoldig'i yo'q (grep MUTATION- => toza), yakuniy to'liq yurgizishda yana 15/15 yashil. MEZONLAR (har biri kod darajasida): 1723 — createPartnerUser() UserService.create(user_type='partner') ni AYNI @Transactional ichida chaqiradi, so'ng supplier.setUserId(user.getId()) (service:81-89). users jadvalida supplier_id ustuni yo'q (V4__users_and_currencies.sql va User.java da grep => topilmadi) — bog'lanish faqat egalik tomonida, §5 qoida 14a. Test users.user_type='partner' va status='invited' ni DB dan o'qib tasdiqlaydi. 1724 — bindExistingPartnerUser() pre-check + V12 dagi uq_suppliers_user_id unique indeksi; ikkalasi ham 409 USER_ALREADY_LINKED beradi. Mutatsiya (b) bilan isbotlandi. 1725 — V12__suppliers_and_contracts.sql:62 `CREATE UNIQUE INDEX uq_suppliers_user_id` (Postgres'da NULL lar unique indeksga tushmaydi), user_id nullable; credentials endpoint umuman chaqirilmasa supplier.user_id NULL qolib ishlayveradi (§5 qoida 14b). Bir test ichida ikkita NULL user_id li supplier birga yashaydi — indeks NULL larni bloklamasligi ham amalda ko'rindi. 2726/1726 — @RequirePermission ikkala amalda ham; mutatsiya (a) bilan isbotlandi. 403 da holat o'zgarmasligi ham tekshirilgan (readSupplierUserId assert). KONTRAKTGA MOSLIK (openapi/v1/suppliers.yaml, faqat solishtirildi, o'zgartirilmadi): - Yo'l/metod: /api/v1/suppliers/{id}/credentials POST+DELETE (ApiPaths.V1="/api/v1") — mos. - Statuslar: POST 201, DELETE 204, 400 VALIDATION_ERROR, 403, 404, 409 — hammasi testda haqiqiy javob sifatida tasdiqlangan. - Maydon nomlari: jackson property-naming-strategy=SNAKE_CASE => request `user_id/username/password/full_name/phone`, response `supplier_id/user_id/username` (kontrakt required ro'yxati bilan aynan, ortiqcha maydon yo'q, parol javobda yo'q — test `body.has("password")` false). - Error `code` qiymatlari: SUPPLIER_ALREADY_HAS_CREDENTIALS · USER_ALREADY_LINKED · USER_NOT_PARTNER · BUSINESS_CONFLICT — to'rttasi ham CredentialsConflict misollariga aynan mos va to'rttasi ham testda tekshirilgan. CODER QARORLARI: (i) bog'lashda user topilmasa 404 NOT_FOUND — MAQBUL. Kontrakt POST uchun `404 ../common.yaml#/components/responses/NotFound` ni AYNAN e'lon qilgan; qaysi holat 404 berishi kontraktda cheklanmagan, shuning uchun ziddiyat yo'q. (ii) @Size cheklovlari (username 100, password 8..255, full_name 255, phone 30) — MAQBUL. password min=8 kontraktdagi minLength: 8 ning aynan o'zi; qolgan max lar users jadvali varchar chegarasi va UserCreateRequest (09_auth) bilan bir xil, ya'ni bu qiymatlardan oshgan so'rov baribir users INSERT da yiqilardi — kontrakt qabul qiladigan to'g'ri so'rov RAD ETILMAYDI, faqat qo'pol 500 o'rniga aniq 400 beriladi. CROSS-CUTTING: ikkala service metodi @Transactional; tenant_id/schema mexanikasi qo'shilmagan (AR-1); yangi migratsiya yo'q; fizik DELETE yo'q (revoke faqat user_id=NULL, users qatoriga tegilmaydi — test statusBefore/userRowExists bilan tasdiqlaydi); userRepository.findByIdAndDeletedAtIsNull soft-delete'ni hurmat qiladi; ilova kodi parolni log'ga yozmaydi (prod log darajasi INFO/WARN). NON-BLOCKING kuzatuv (bu barg aybi emas, repo bo'ylab mavjud naqsh): dev profilida org.springframework.web=DEBUG bo'lgani uchun Spring DTO toString'ini log'ga chiqaradi va record'da parol ochiq ko'rinadi — LoginRequest/UserCreateRequest da ham xuddi shunday. Agar tuzatilsa, 09_auth doirasida hammasiga birdan (masalan toString override) qilingani to'g'ri. Parallel worker (EP-03-T03) fayllariga tegilmadi; faqat o'z mutatsiyalarim tiklandi. VERDIKT: done.

qa-ep-03-t05-s01 qabul mezonini belgiladi

✓ `supplier.manage_credentials` rule'siz `403`

qa-ep-03-t05-s01 qabul mezonini belgiladi

✓ `user_id` NULL bo'lgan ta'minotchi normal yaratiladi va ishlaydi (akkaunt ixtiyoriy)

qa-ep-03-t05-s01 qabul mezonini belgiladi

✓ Allaqachon boshqa ta'minotchiga bog'langan userni bog'lashga urinish `409` beradi

qa-ep-03-t05-s01 qabul mezonini belgiladi

✓ Yangi `partner` user yaratilib `suppliers.user_id` ga bog'lanadi; `users` da `supplier_id` ustuni YO'Q (bog'lanish faqat egalik tomonida)

coder-ep-03-t05-s01 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-03-t05-s01 yangiladi

Yangilandi: branch, commit_sha

coder-ep-03-t05-s01 qabul mezonini belgiladi

✓ `supplier.manage_credentials` rule'siz `403`

coder-ep-03-t05-s01 qabul mezonini belgiladi

✓ `user_id` NULL bo'lgan ta'minotchi normal yaratiladi va ishlaydi (akkaunt ixtiyoriy)

coder-ep-03-t05-s01 qabul mezonini belgiladi

✓ Allaqachon boshqa ta'minotchiga bog'langan userni bog'lashga urinish `409` beradi

coder-ep-03-t05-s01 qabul mezonini belgiladi

✓ Yangi `partner` user yaratilib `suppliers.user_id` ga bog'lanadi; `users` da `supplier_id` ustuni YO'Q (bog'lanish faqat egalik tomonida)

coder-ep-03-t05-s01 fayllarni qayd etdi

6 ta fayl qayd etildi

coder-ep-03-t05-s01 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-03-t05-s01 ishga oldi

pm-agent yaratdi

Hamkor login berish/uzish (`supplier.manage_credentials`)