users CRUD + §4.2 holat mashinasi + R36/R38 himoyalari

team-lead-ep-09 yangiladi

Yangilandi: pr_url

team-lead-ep-09 izoh qoldirdi

Faza D drift qayta tekshiruvi (2-urinish): oasdiff bu bargga tegishli enum maydonlarini (status, user_type) kontraktdagi nomlangan $ref emas, springdoc generatsiyasida oddiy string sifatida ko-rsatdi. Qiymat to-plamini qo-lda solishtirdim: kod @Pattern regex-lari kontrakt enum qiymatlari bilan mos (UserStatusUpdateRequest invited-ni ataylab qamramaydi -- holat mashinasi qoidasi, kamchilik emas). Bu funksional drift emas, springdoc-ning @Pattern String-ni named enum sxemaga aylantirmasligi (repo-dagi hujjatlangan konvensiya). Kod o-zgarishsiz done.

team-lead-ep-09 statusni o'zgartirdi Ishlanyapti → Bajarildi

team-lead-ep-09 statusni o'zgartirdi Bloklangan → Ishlanyapti

finalize-ep-09 statusni o'zgartirdi Ishlanyapti → Bloklangan

Faza D drift (finalize, ikkinchi urinish): UserResponse/UserCreateRequest/UserUpdateRequest/UserStatusUpdateRequest'da user_type/status maydonlari kontraktning UserType/UserStatus ($ref enum) o'rniga String + @Pattern bilan yozilgan (Java enum emas). Generatsiya qilingan hujjatda bu 2 sxema umuman yo'q (oasdiff: enumDeleted=true, komponent o'chirilgan). Xuddi shu konvensiya boshqa DTO'larda ham takrorlanadi — tizimli qaror, birlashtirib ko'rib chiqilsin.

finalize-ep-09 statusni o'zgartirdi Bajarildi → Ishlanyapti

Faza D drift tekshiruvi: qayta ochilmoqda — kontrakt bilan solishtirish uchun

finalize-ep-09 statusni o'zgartirdi Ishlanyapti → Bajarildi

vaqtincha tiklash — T05-S04 blok qilingach yana blocked qilinadi

finalize-ep-09 statusni o'zgartirdi Bloklangan → Ishlanyapti

vaqtincha tiklash — T05-S04 blok tartibi uchun

finalize-ep-09 statusni o'zgartirdi Ishlanyapti → Bloklangan

Faza D drift (finalize, ikkinchi urinish): UserResponse/UserCreateRequest/UserUpdateRequest/UserStatusUpdateRequest'da user_type/status maydonlari kontraktning UserType/UserStatus ($ref enum) o'rniga 'String' + @Pattern bilan yozilgan (Java enum emas). Generatsiya qilingan hujjatda bu 2 sxema umuman yo'q (oasdiff: enumDeleted=true, komponent o'chirilgan). Xuddi shu konvensiya boshqa DTO'larda ham takrorlanadi — tizimli qaror, birlashtirib ko'rib chiqilsin.

finalize-ep-09 statusni o'zgartirdi Bajarildi → Ishlanyapti

Faza D drift tekshiruvi: qayta ochilmoqda — kontrakt bilan solishtirish uchun

team-lead-ep-09 yangiladi

Yangilandi: estimate_hours

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

qa-ep-09-t05-s01 izoh qoldirdi

QA tekshiruvi (qa-EP-09-T05-S01): 09_auth #4.2 + R36/R38/R49 kod bilan solishtirildi (UserService.java, UserRepository.java, UserPermissionGroupRepository.java, UserController.java, DTOlar). Natija: 18/18 test yashil (UserCrudIntegrationTest, real Postgres/Testcontainers). Tekshirilgan: - §4.2 holat mashinasi ALLOWED_TRANSITIONS xaritasi spec bilan aynan mos (invited->active, active<->suspended, active/suspended->blocked, blocked->active); boshqa o'tish 409 BUSINESS_CONFLICT (AC743). - R36: findActiveTenantOwnerIdsForUpdate() FOR UPDATE OF u bilan uchala shartni (status=active, deleted_at IS NULL, owner@scope_type=tenant) alohida qamraydi; AC745 uchun 3 ta alohida test (invited, soft-deleted, org_node scope) bor. - Bug-fix tekshirildi va MUTATSIYA bilan isbotlandi: requireRemainingOwnerAfterRemoval() dagi erta-return guardni ataylab olib tashladim, deletingSoleInvitedOwnerIsAllowedSinceNotYetCountedAsActiveOwner testi 409ga tushib yiqildi (204 kutilgan edi), keyin kodni git checkout bilan tikladim va 18/18 qayta yashil bo'ldi. Demak test guard yo'qligini haqiqatan ushlaydi, tautologik emas (AC746). - R36->R38 tartibi: delete()/updateStatus() da requireRemainingOwnerAfterRemoval() requireNotSelf()dan OLDIN chaqiriladi, yagona owner o'zini o'chirsa LAST_OWNER_REQUIRED (SELF_MODIFICATION_FORBIDDEN emas) - selfDeleteAsSoleOwnerReturnsLastOwnerRequiredNotSelfModification testi buni tasdiqlaydi (AC747). - R49: requireNotSystemUser() update/delete/updateStatus barchasida chaqiriladi; UserRepository.search() username<>system filtri bilan ro'yxatdan chiqaradi (AC748); UserCreateRequest orqali system yaratilsa UNIQUE(username) tabiiy 409 beradi (AC749). - AC750: concurrentDeleteOfTheLastTwoOwnersLeavesExactlyOneSuccess ikki parallel DELETE yuboradi, aynan 1 success + 1 409 + DBda 1 owner qolganini tekshiradi. - Kontrakt (openapi/v1/auth.yaml): UserResponse/UserCreateRequest/UserUpdateRequest/UserStatusUpdateRequest maydon nomi/tipi/required Java DTOlarga aynan mos; global SNAKE_CASE Jackson strategiyasi tasdiqlangan; SystemUserImmutable/LastOwnerRequiredExample kabi $ref lar joyida. - Cross-cutting: barcha yozuv metodlari @Transactional, o'qish @Transactional(readOnly=true); soft-delete (deleted_at), fizik DELETE yo'q; parol/token audit log details ga yozilmaydi (AuditService AC18 himoyasi mavjud); bu bargda migratsiya o'zgarmagan (tenant/FK/precision tekshiruvi shu barg doirasida N/A). - R27 (session revocation) ataylab yo'q - bu EP-09-T05-S02 (blocked_by shu ish) ishi, board tavsifida ham shunday ajratilgan; kod javadocida ochiq izohlangan. Eslatma (bloklovchi emas): openapi/v1/auth.yaml hali git da untracked (T00 contract-freeze taski commit_sha=null holda done qilingan) - bu EP-09-T05-S01 doirasidan tashqari, lekin team-lead diqqatiga.

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

✓ Ikki parallel so'rov oxirgi owner'ni bir vaqtda o'chira olmaydi (`FOR UPDATE` testi)

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

✓ Yangi user `username='system'` bilan yaratilmaydi

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

✓ `system` useriga tegishli har amal `409 SYSTEM_USER_IMMUTABLE` beradi; u `GET /users` ro'yxatida ko'rinmaydi — AC46

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

✓ O'z akkauntini bloklash `409 SELF_MODIFICATION_FORBIDDEN` beradi — AC22/E14

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

✓ ⚠️ Agar 'korxonada YAGONA owner `invited` holatida' amal semantikasi noaniq chiqsa (o'zgarishdan oldin ham faol owner 0 ta) — ish `blocked` qilinadi va §5 savol sikliga qaytariladi; taxmin qilinmaydi (§17.5)

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

✓ R36 'faol owner' ta'rifining uchala sharti testda alohida tekshiriladi: `status='active'` (🔴 `invited` SANALMAYDI) · `deleted_at IS NULL` · `owner`@`scope_type='tenant'` (filial darajasidagi owner sanalmaydi)

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

✓ Oxirgi faol owner'ni o'chirish/bloklash `409 LAST_OWNER_REQUIRED` beradi; ikkinchi owner tayinlangandan keyin ruxsat etiladi — AC22/E12

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

✓ Ruxsat etilmagan status o'tishi rad etiladi (mas. `blocked → suspended`)

coder-ep-09-t05-s01 yangiladi

Yangilandi: branch, commit_sha

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

coder-ep-09-t05-s01 izoh qoldirdi

Muhim qarorlar: (1) R36 R38 dan OLDIN tekshiriladi (09_auth §8 UC8 4/5-qadam bilan bir xil tartib) — yagona faol owner o'zini o'chirsa/bloklasa javob LAST_OWNER_REQUIRED, SELF_MODIFICATION_FORBIDDEN emas (test: selfDeleteAsSoleOwnerReturnsLastOwnerRequiredNotSelfModification). (2) R36 tekshiruvi FAQAT target hozircha "faol owner" bo'lganda ishga tushadi — aks holda korxonada faol owner umuman 0 ta bo'lgan har qanday holatda (mas. yagona owner hali invited, R36(i) bootstrap istisnosi) har qanday user'ni o'chirish/bloklash noto'g'ri ravishda bloklanib qolardi. AC746 shu tufayli blocked qilinmadi — R36 ta'rifi o'z-o'zidan aniq (target aynan hozir faol owner ekanligiga bog'liq savol, korxona darajasidagi mustaqil savol emas). (3) POST /users/{id}/reset-password bu bargda YO'Q — R27 ulanishi bilan birga EP-09-T05-S02 ishi; xuddi shu sabab bilan suspended/blocked/delete amallarida ham SessionRevocationService bu bargda ATAYLAB chaqirilmagan (R27 wiring S02 da qo'shiladi, board tavsifiga mos).

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

✓ Ikki parallel so'rov oxirgi owner'ni bir vaqtda o'chira olmaydi (`FOR UPDATE` testi)

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

✓ Yangi user `username='system'` bilan yaratilmaydi

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

✓ `system` useriga tegishli har amal `409 SYSTEM_USER_IMMUTABLE` beradi; u `GET /users` ro'yxatida ko'rinmaydi — AC46

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

✓ O'z akkauntini bloklash `409 SELF_MODIFICATION_FORBIDDEN` beradi — AC22/E14

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

✓ ⚠️ Agar 'korxonada YAGONA owner `invited` holatida' amal semantikasi noaniq chiqsa (o'zgarishdan oldin ham faol owner 0 ta) — ish `blocked` qilinadi va §5 savol sikliga qaytariladi; taxmin qilinmaydi (§17.5)

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

✓ R36 'faol owner' ta'rifining uchala sharti testda alohida tekshiriladi: `status='active'` (🔴 `invited` SANALMAYDI) · `deleted_at IS NULL` · `owner`@`scope_type='tenant'` (filial darajasidagi owner sanalmaydi)

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

✓ Oxirgi faol owner'ni o'chirish/bloklash `409 LAST_OWNER_REQUIRED` beradi; ikkinchi owner tayinlangandan keyin ruxsat etiladi — AC22/E12

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

✓ Ruxsat etilmagan status o'tishi rad etiladi (mas. `blocked → suspended`)

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

10 ta fayl qayd etildi

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

Agent ishni boshladi

coder-ep-09-t05-s01 ishga oldi

pm-agent yaratdi

users CRUD + §4.2 holat mashinasi + R36/R38 himoyalari