Upgrade Komponen Aset Ruangan (ALK-RGN07)

01Informasi Dokumen

02Daftar Isi

Lihat panel navigasi di samping.

03Quick Overview

Spesifikasi komponen satu aset ruangan (mis. RAM 16 GB → 32 GB) ditingkatkan lewat dua jalur dalam satu tabel (asset_trx_upgrade_ruangan), dibedakan kolom sumber_pengajuan. Pada Jalur A PIC Ruangan mengajukan (komponen yang diupgrade, alasan, urgensi) lalu Admin/HR menyetujui dengan jadwal pengambilan atau menolak; pada Jalur B Admin/HR langsung membuat transaksi beserta jadwal pengambilan. Pada jadwal, PIC menyerahkan aset (Pelepasan, tanpa checklist; aset menjadi dalam_perbaikan, pemegang tetap ruangan), Admin/HR mencatat hasil upgrade dan jadwal pengembalian, lalu PIC menerima kembali aset dengan satu ketukan Terima (tanpa checklist). Penerimaan itu langsung menyelesaikan upgrade: bila hasilnya selesai, nilai baru ditulis ke atribut, aset kembali terpakai di ruangan yang sama. Tidak ada lagi checklist pengambilan/pengembalian, review akhir admin, maupun Kirim Ulang (dihapus v1.2).

04Ringkasan Fitur

05Tujuan Fitur

• Meningkatkan spesifikasi aset ruangan tanpa mengubah kepemilikannya: aset tetap tercatat milik ruangan.
• Memberi PIC Ruangan jalur resmi untuk meminta upgrade dengan alasan dan urgensi, dan memberi Admin/HR keputusan terdokumentasi.
• Mencatat serah terima fisik dua arah (pelepasan oleh PIC dan penerimaan kembali oleh PIC) beserta waktu dan pelakunya. Kondisi fisik komponen tidak dicatat sejak v1.2.
• Memperbarui nilai atribut aset (asset_data_item) hanya bila upgrade benar-benar berhasil.
• Mencegah aset yang sama dipakai bersamaan di retur, onboarding, penambahan ruangan, atau upgrade lain.

06Aktor

07Hak Akses

08Terminologi

09Business Rules

10Business Flow

1. Jalur A. PIC memilih ruangan, aset, komponen yang diupgrade (+ detail upgrade tiap komponen), alasan, dan urgensi, lalu mengirim. Admin/HR dinotifikasi (upgrade_ruangan.diajukan).
2. Admin/HR mereview pengajuan.
   • Tolak: isi alasan, status ditolak, fase selesai, transaksi selesai; semua PIC ruangan dinotifikasi (ditolak).
   • Setujui: tetapkan jadwal pengambilan, fase menunggu_pengambilan; semua PIC dinotifikasi (disetujui).
3. Jalur B. Admin/HR memilih ruangan, aset, komponen, catatan, dan jadwal pengambilan; transaksi langsung disetujui dan semua PIC dinotifikasi (disetujui). Langkah 1-2 dilewati.
4. Jadwal dapat diubah Admin/HR selama fase menunggu_pengambilan (dijadwalkan). Tidak ada pemeriksaan/checklist oleh admin; PIC bisa langsung menyerahkan aset.
5. PIC menekan Serahkan Aset (Pelepasan, tanpa checklist) pada jadwal. Aset menjadi dalam_perbaikan, log ruangan → gudang, fase dalam_service. Admin dinotifikasi (dilepas).
6. Teknisi mengerjakan upgrade di luar sistem. Admin/HR mencatat hasil (selesai atau tidak_dapat_diupgrade, nilai baru per atribut, biaya, keterangan) dan jadwal pengembalian. Fase menunggu_pengembalian; semua PIC dinotifikasi (pengembalian). Jadwal pengembalian masih dapat diubah (dijadwalkan).
7. PIC menekan Terima Aset (tanpa checklist dan tanpa body) yang langsung menyelesaikan upgrade dalam satu transaksi:
   • bila status_hasil='selesai', nilai baru ditulis ke asset_data_item.json_value;
   • aset kembali terpakai, log gudang → ruangan, tgl_diterima diisi;
   • fase_upgrade='selesai' dan status_transaksi='selesai'; Admin dinotifikasi (diterima, berakhiran "Upgrade selesai.").
8. Selesai. Tidak ada review akhir admin, Selesaikan, ataupun Kirim Ulang (dihapus v1.2).

11Flow Berdasarkan Role

12Flow Diagram

flowchart TD
    A([Mulai]) --> J{Jalur}
    J -->|A: PIC mengajukan| P[Pengajuan: ruangan, aset, komponen, alasan, urgensi]
    J -->|B: Admin langsung| B[Pilih ruangan, aset, komponen, jadwal pengambilan]
    P --> R{Admin/HR review}
    R -->|Tolak + alasan| T([Ditolak - selesai])
    R -->|Setujui + jadwal| W[Menunggu pengambilan]
    B --> W
    W --> L[PIC: Serahkan Aset tanpa checklist - dalam_perbaikan, log ruangan ke gudang]
    L --> S[Dalam service: Admin catat hasil + jadwal pengembalian]
    S --> N[PIC: Terima Aset tanpa checklist]
    N --> H{status_hasil}
    H -->|selesai| K[Nilai baru ke asset_data_item, aset terpakai, log gudang ke ruangan]
    H -->|tidak_dapat_diupgrade| K2[Atribut tidak berubah, aset terpakai, log gudang ke ruangan]
    K --> Z([Selesai])
    K2 --> Z

Fase menunggu_review dan jalur Kirim Ulang pada diagram v1.1 sudah dihapus.

13Sequence Diagram

sequenceDiagram
    participant PIC as PIC Ruangan (Mobile)
    participant API as API Lumen
    participant DB as Database
    participant ADM as Admin/HR (Mobile)
    PIC->>API: POST karyawan/pic-ruangan/upgrade
    API->>DB: insert header (proses, pengajuan) + item atribut
    API-->>ADM: notifikasi upgrade_ruangan.diajukan
    ADM->>API: POST upgrade-ruangan/{id}/review (disetujui + jadwal)
    API-->>PIC: notifikasi upgrade_ruangan.disetujui
    PIC->>API: POST karyawan/pic-ruangan/upgrade/{id}/pelepasan
    API->>DB: asset dalam_perbaikan, asset_trx_log ruangan ke gudang
    API-->>ADM: notifikasi upgrade_ruangan.dilepas
    ADM->>API: POST upgrade-ruangan/{id}/hasil
    API-->>PIC: notifikasi upgrade_ruangan.pengembalian
    PIC->>API: POST karyawan/pic-ruangan/upgrade/{id}/terima (tanpa body)
    API->>DB: atribut diperbarui (bila selesai), asset terpakai, asset_trx_log gudang ke ruangan, fase selesai
    API-->>ADM: notifikasi upgrade_ruangan.diterima (Upgrade selesai.)

14Status Transaksi

Dua kolom enum disimpan di header: status_approval dan fase_upgrade (serta status_transaksi untuk tab Selesai). Label dan tab daftar diturunkan oleh upgradeStatusMetadata.

Filter daftar di API: tab pengajuan = status_approval='proses'; proses = disetujui dan fase bukan selesai; selesai = status_transaksi='selesai'. Tanpa parameter tab, semua transaksi dikembalikan. Status aset: lihat §22. Konstanta dan label menunggu_review dipertahankan di kode dan enum agar data lama tetap terbaca, tetapi tidak ada aksi yang bisa memprosesnya; data lama diselesaikan dengan SQL migrasi sql-upgrade-hapus-checklist-review-lama.sql (belum dijalankan).

15State Transition

stateDiagram-v2
    [*] --> pengajuan: PIC ajukan (Jalur A)
    [*] --> menunggu_pengambilan: Admin inisiasi (Jalur B)
    pengajuan --> ditolak: Admin tolak
    pengajuan --> menunggu_pengambilan: Admin setujui + jadwal
    menunggu_pengambilan --> menunggu_pengambilan: Ubah jadwal
    menunggu_pengambilan --> dalam_service: PIC Serahkan Aset (Pelepasan)
    dalam_service --> menunggu_pengembalian: Admin catat hasil + jadwal
    menunggu_pengembalian --> menunggu_pengembalian: Ubah jadwal
    menunggu_pengembalian --> selesai: PIC Terima (langsung selesai)
    ditolak --> [*]
    selesai --> [*]

Transisi menunggu_pengembalian → menunggu_review, menunggu_review → selesai, dan menunggu_review → menunggu_pengambilan (Kirim Ulang) dari v1.1 sudah dihapus.

16Struktur Database

Enum yang dipakai bersama dokumen lain di DBML: sumber_pengajuan, status_approval, status, fase_upgrade, status_hasil_upgrade.

Skema tidak berubah pada v1.2. File SQL asal sql-alk-rgn-upgrade-ruangan.sql tidak diubah (sudah dijalankan); kolom checklist_pengambilan dan checklist_pengembalian serta nilai enum menunggu_review tetap ada. Satu-satunya skrip tambahan adalah SQL migrasi data lama sql-upgrade-hapus-checklist-review-lama.sql (belum dijalankan, lihat RISK-011).

17Relasi Database

erDiagram
    asset_lokasi_m ||--o{ asset_trx_upgrade_ruangan : "id_asset_lokasi_m"
    asset_trx_upgrade_ruangan ||--o{ asset_trx_upgrade_ruangan_item : "id_asset_trx_upgrade_ruangan"
    asset_data ||--o{ asset_trx_upgrade_ruangan_item : "id_asset_data"
    asset_lokasi_m ||--o{ asset_lokasi_pic_m : "PIC ruangan"
    asset_data ||--o{ asset_data_item : "atribut diupgrade"

Foreign key di SQL: fk_atur_upgrade_id_asset_lokasi_m, fk_aturi_upgrade_header, fk_aturi_upgrade_asset_data. PIC pada header disimpan sebagai snapshot (id_karyawan_pic, nama_pic, nik_pic); hak akses dan penerima notifikasi dibaca dari asset_lokasi_pic_m saat itu juga.

18Data Dictionary

asset_trx_upgrade_ruangan

asset_trx_upgrade_ruangan_item: id_asset_trx_upgrade_ruangan_item (PK), id_asset_trx_upgrade_ruangan, id_asset_data, kelengkapan_item (JSON atribut: id_atribut, id_asset_data_item, id_komponen, nama_item, jenis, label, satuan, nilai), snapshot nama_asset, deskripsi_asset, kategori_asset, detail_upgrade, nilai_lama, nilai_baru, alasan_tidak_upgrade, id_company, tgl_input, user_input.

19Database Index

20Backend Architecture

Controller memvalidasi input, model menjalankan DB::transaction (dengan lockCompany dan lockForUpdate), lalu notifikasi dikirim setelah transaksi sukses. Aksi admin lewat mutateAssetTrx (respons sukses UPDATED), aksi PIC lewat mutateTrxSaya. Logika pendukung dipakai ulang dari KRY03 (AssetUpgradeKaryawan_m) dan Asset_m (komponenAssets, parseJadwalValue, insertAssetLog; normalizeKondisiChecklist tidak lagi dipanggil modul ini).

Perubahan pada modul lain

21Backend Business Logic

• storePic (Jalur A): kunci company; validasi karyawan aktif, ruangan milik PIC (BR-02), urgensi, alasan; insertTransaction membuat header proses/pengajuan tanpa jadwal.
• storeAdmin (Jalur B): validasi admin dan ruangan (PIC = PIC pertama ruangan menurut urutan master), parse jadwal; header disetujui/menunggu_pengambilan dengan jadwal pengambilan, user_approval dan tgl_approval terisi.
• insertTransaction: kunci aset FOR UPDATE; aset harus milik ruangan dan terpakai; cek kunci lintas modul; normalisasi item; nomor RGN07- + YYYYMM + 3 digit; simpan header dan item (nilai_lama dari atribut saat itu).
• review: header harus proses. Tolak: alasan wajib, status_approval='ditolak', fase_upgrade='selesai', status_transaksi='selesai'. Setujui: aset masih terpakai, jadwal valid, fase menunggu_pengambilan.
• updateJadwal: fase menunggu_pengambilan atau menunggu_pengembalian; menulis tanggal/jam pengambilan atau pengembalian sesuai fase.
• pelepasan (PIC): lockHeader dengan filter PIC aktif ruangan; fase menunggu_pengambilan (tanpa syarat checklist); aset terpakai atau dalam_perbaikan dan masih dipegang ruangan; aset → dalam_perbaikan; log ruangan → gudang; tgl_pelepasan, user_pelepasan; fase dalam_service.
• hasil: fase dalam_service; validasi status/keterangan/biaya/jadwal; tiap item mendapat nilai_baru (hanya bila selesai) atau alasan_tidak_upgrade (bila tidak dapat diupgrade); fase menunggu_pengembalian; tgl_diterima direset NULL.
• terima (PIC, tanpa body): lockHeader dengan filter PIC aktif ruangan; fase menunggu_pengembalian; aset dalam_perbaikan dan dipegang ruangan. Dalam satu transaksi: bila status_hasil='selesai' jalankan applyAtribut (menulis nilai_baru ke json_value.komponen[].value pada asset_data_item); aset → terpakai; log gudang → ruangan; fase_upgrade='selesai', status_transaksi='selesai', tgl_diterima diisi.
• Pending (getPendingForAdmin, countPendingForAdmin): status_approval='proses' atau fase dalam_service. getPendingForPic: fase menunggu_pengambilan (aksi pelepasan) atau menunggu_pengembalian (aksi terima).
• Dihapus v1.2: checklistPengambilan, selesai (review akhir: terima/kirim_ulang), terima versi lama yang menyimpan checklist dan masuk menunggu_review.

22Dampak terhadap asset_data

Kolom log: id_pemegang/nama_pemegang terisi id dan nama ruangan pada sisi ruangan, kosong pada sisi gudang (mengikuti retur ruangan, RISK-005). kondisi_awal dan kondisi_akhir log selalu sama, memakai kondisi_awal aset (normal bila kosong), karena kondisi fisik tidak lagi dicatat sejak v1.2 (RISK-012).

Pada data lama yang berhenti di fase menunggu_review, aset tetap dalam_perbaikan dan terkunci sampai SQL migrasi dijalankan (RISK-011).

23API Documentation

Base asset/. Semua memakai JWT dan envelope ApiResponse.

Tambahan: GET karyawan/pic-ruangan (beranda PIC) kini menyertakan key upgrade_ruangan; GET summary (admin) kini menyertakan ruangan_upgrade_perlu_proses dan ruangan_upgrade_pending. Jumlah endpoint dihitung dari RouteAsset.php: grup upgrade-ruangan 7 route (API-01 sampai API-06 dan API-08) + 6 route PIC (API-10 sampai API-15) = 13 (v1.1: 15; dua rute admin dihapus). Test test_routes_are_registered_for_admin_and_pic_groups memastikan rute yang dihapus menjawab 404. Total route aplikasi pada v1.1 (552, lihat RISK-008) belum dihitung ulang.

24Detail Setiap API

API-12 · POST asset/karyawan/pic-ruangan/upgrade (Jalur A)

{ "id_asset_lokasi_m": "RGN-1", "id_asset_data": "LAP-1",
  "alasan": "Build lambat", "urgensi": "secepatnya",
  "items": [{ "id_atribut": "LAP-1-UNIT|K1", "detail_upgrade": "16 GB ke 32 GB" }] }

Respons CREATED: { "id": "COMP202610001", "no_trx": "RGN07-202610001", "status_approval": "proses", "fase_upgrade": "pengajuan", "status_label": "Menunggu Persetujuan", "tab": "pengajuan" }. urgensi ∈ normal|secepatnya|mendesak; id_atribut diambil dari assets[].atribut[] pada API-10.

API-04 · POST asset/upgrade-ruangan (Jalur B)

{ "id_asset_lokasi_m": "RGN-1", "id_asset_data": "LAP-1", "catatan": "Bawa kunci ruangan",
  "items": [{ "id_atribut": "LAP-1-UNIT|K1", "detail_upgrade": "16 GB ke 32 GB" }],
  "tgl_jadwal": "2026-10-20", "jam_jadwal": "09:00", "keterangan_jadwal": "Ruang IT" }

Respons CREATED: status_approval: "disetujui", fase_upgrade: "menunggu_pengambilan", tab: "proses". Controller menandai jadwal nullable, tetapi model menolak bila kosong (Tanggal dan jam serah terima wajib diisi.). Notifikasi yang dikirim: upgrade_ruangan.disetujui (ke semua PIC ruangan).

API-05 · POST .../{id}/review: setujui { "keputusan": "disetujui", "tgl_jadwal": "2026-10-20", "jam_jadwal": "09:00", "keterangan_jadwal": "" }; tolak { "keputusan": "ditolak", "ket_tolak": "Belum prioritas" }. Respons UPDATED dengan status/fase terbaru; event upgrade_ruangan.disetujui atau upgrade_ruangan.ditolak.

API-06 · PUT .../{id}/jadwal: { "tgl_jadwal", "jam_jadwal", "keterangan_jadwal" }. Mengubah jadwal pengambilan atau pengembalian sesuai fase; event upgrade_ruangan.dijadwalkan.

API-07 dan API-09 (dihapus v1.2): POST .../{id}/checklist-pengambilan dan POST .../{id}/selesai ({ "aksi": "terima" | "kirim_ulang" }) tidak lagi terdaftar; keduanya menjawab 404.

API-08 · POST .../{id}/hasil

{ "status_hasil": "selesai", "keterangan_hasil": "Dikerjakan vendor", "biaya_upgrade": 850000,
  "items": [{ "id_item": "COMP202610001", "nilai_baru": "32" }],
  "tgl_jadwal": "2026-10-22", "jam_jadwal": "10:00", "keterangan_jadwal": "Ambil di resepsionis" }

id_item adalah id baris item upgrade (items[].id_item pada detail); satu-satunya jenis id_item pada modul ini sejak checklist dihapus. status_hasil ∈ selesai|tidak_dapat_diupgrade; bila selesai, nilai_baru setiap item wajib. Event upgrade_ruangan.pengembalian.

API-14 · POST .../upgrade/{id}/pelepasan: tanpa body. Hanya PIC aktif ruangan; tidak ada syarat checklist. Event upgrade_ruangan.dilepas.

API-15 · POST .../upgrade/{id}/terima: tanpa body. Langsung menyelesaikan upgrade (atribut diperbarui bila hasil selesai, aset terpakai, log gudang → ruangan, fase_upgrade='selesai'). Respons UPDATED: status_label "Selesai", fase_upgrade selesai. Event upgrade_ruangan.diterima ke admin. Body lama { "items": [...] } (checklist) kini diabaikan.

API-10 / API-01 · Opsi: ruangan[] berisi id_asset_lokasi_m, nama_ruangan, cabang, divisi, pic{id_karyawan,nik,nama}, assets[] (id_asset_data, kode_asset, nama_asset, kategori_asset, merek, id_asset_lokasi_m, atribut[]). Hanya ruangan yang punya aset terpakai, bebas kunci lintas modul, dan beratribut spesifikasi yang muncul. API-10 menambah urgensi[] (value, label).

API-02 / API-11 · Daftar: filters[], records[] (id, no_trx, sumber_pengajuan, tgl_pengajuan, urgensi, status_approval, fase_upgrade, status_label, tab, jadwal, jumlah_item, asset, ruangan, pic), pagination (limit default 20 maks 50, offset, next_offset, has_more).

API-03 / API-13 · Detail: id, no_trx, sumber_pengajuan, tgl_pengajuan, alasan, urgensi, catatan, ket_tolak, status_approval, fase_upgrade, status_label, tab, jadwal (tgl_pengambilan, jam_pengambilan, tgl_pengembalian, jam_pengembalian), keterangan_jadwal, tgl_pelepasan, tgl_diterima, status_hasil, keterangan_hasil, biaya_upgrade, ruangan, pic, asset, items[] (id_item, nama_item, label, satuan, detail_upgrade, nilai_lama, nilai_baru, alasan_tidak_upgrade), komponen[] (masih dikirim, tidak dipakai layar ruangan), dan aksi{review, ubah_jadwal, pelepasan, hasil, terima}. Field checklist_pengambilan, checklist_pengembalian, checklist_pengembalian_rusak, serta flag aksi.checklist_pengambilan dan aksi.selesai dihapus v1.2 (diuji tidak ada). Flag aksi tidak mengenal peran (RISK-002): detail PIC pun memuat flag yang hanya berlaku untuk admin. Flag mengikuti fase: review saat status_approval='proses'; ubah_jadwal saat menunggu_pengambilan/menunggu_pengembalian; pelepasan saat menunggu_pengambilan; hasil saat dalam_service; terima saat menunggu_pengembalian. Pada transaksi selesai tidak ada flag true.

25Mobile Architecture

Flutter + flutter_bloc + dio. Modul Upgrade Karyawan (KRY03) dipakai ulang lewat flag agar tidak menggandakan kode.

Widget AssetKondisiChecklist (di AssetFormWidgets.dart) dipertahankan karena dipakai modul lain; hanya pemakaiannya di Upgrade yang dihapus. Kunci lokalisasi lama yang tak terpakai (mis. checklist_pengambilan, checklist_pengembalian, menunggu_checklist_admin, review_normal_info, review_rusak_info, button_simpan_checklist, button_selesaikan, button_kirim_ulang, konfirmasi_selesai) masih ada di asset.json sebagai sisa (juga teks pelepasan_info yang masih menyebut pemeriksaan admin).

Perubahan di file bersama: HalamanAssetPicRuangan.dart (entri + banner), HalamanAssetAdminRuangan.dart (item Upgrade + seksi perlu diproses), mAssetPicRuangan.dart (upgradeRuangan), mAssetSummary.dart (ruanganUpgradePerluProses, ruanganUpgradePending), NavigatorBloc.dart, router.dart.

26Mobile Screen

Rute notifikasi (assetNotifRoutes): asset_pic_ruangan_upgrade (PIC, membawa id transaksi) dan asset_admin_detail_upgrade_ruangan (Admin). Detail menampilkan header nomor transaksi, stepper fase (label tidak berubah: Pengajuan, Pengambilan, Service, Pengembalian, Selesai), kartu jadwal aktif, komponen yang diupgrade (nilai lama/baru), form hasil (admin), ringkasan hasil, dan kartu pengajuan (ruangan, PIC, alasan, urgensi, catatan). Tidak ada lagi form checklist maupun ringkasan checklist. Tombol bawah mengikuti peran dan flag aksi: PIC Serahkan Aset (aksi.pelepasan) atau Terima Aset (aksi.terima), masing-masing dengan dialog konfirmasi; Admin Tolak / Setujui & Jadwalkan (aksi.review) atau Simpan Hasil & Jadwalkan (aksi.hasil).

27Mobile → API

28API → Mobile

Model: mAssetUpgrade.dart (AssetUpgradeRecord dengan ruangan, pic, aksi; AssetUpgradeRuanganOption untuk opsi; AssetUpgradeRuanganPending untuk banner beranda PIC), mAssetPicRuangan.dart (upgradeRuangan dari key upgrade_ruangan), mAssetSummary.dart (ruanganUpgradePerluProses, ruanganUpgradePending dari ruangan_upgrade_*). Respons PIC memakai kunci nama (bukan nama_karyawan) sehingga dibaca AssetUpgradePic. Mobile menyaring tombol per peran karena aksi dari server tidak mengenal peran: admin hanya melihat review/hasil (+ubah jadwal), PIC hanya pelepasan/terima. Model AssetUpgradeAksi tidak lagi memiliki checklistPengambilan dan selesai.

29Mapping Mobile → API → Database

30Mapping Database → API → Mobile

31Validation

Mobile: tombol Setujui memerlukan jadwal lewat sheet jadwal; form hasil memvalidasi nilai baru dan keterangan sebelum menampilkan sheet jadwal pengembalian; dialog Tolak memerlukan alasan. Pelepasan dan Terima tidak punya input (hanya dialog konfirmasi), sehingga tidak ada validasi body. Validasi aksi (terima/kirim_ulang) dan checklist (kondisi, ket_rusak) dihapus v1.2. Catatan sisa: upgradeMessages() pada controller admin masih memuat pesan items.*.kondisi.in dan items.*.ket_rusak.required_if yang tidak lagi dipakai.

32Error Handling

Respons sukses: CREATED (201) untuk pembuatan, UPDATED (200) untuk aksi, SUCCESS untuk pembacaan.

33Audit Trail

• Header: user_input/tgl_input, user_update/tgl_update pada setiap perubahan; user_approval + tgl_approval (review atau Jalur B); user_pelepasan + tgl_pelepasan; tgl_diterima.
• Item: user_input/tgl_input per baris; nilai lama/baru tersimpan permanen di item.
• Kondisi komponen tidak lagi dicatat (checklist dihapus v1.2). Kolom checklist_pengambilan/checklist_pengembalian pada data lama tetap tersimpan apa adanya tetapi tidak dibaca API.
• asset_trx_log jenis upgrade_ruangan: ruangan → gudang saat pelepasan dan gudang → ruangan saat PIC menerima (upgrade selesai); kondisi_akhir selalu sama dengan kondisi_awal, nama_tabel_transaksi='asset_trx_upgrade_ruangan'.

34Notification

Event checklist_pengambilan, selesai, dan kirim_ulang dihapus v1.2 (daftar di atas = 7 event, sesuai AssetNotification.php). Pada alur normal PIC kini menerima 2 notifikasi per upgrade (disetujui dan pengembalian; v1.1: 4), ditambah dijadwalkan bila jadwal diubah dan ditolak bila ditolak.

Penerima PIC dihitung dari asset_lokasi_pic_m saat notifikasi dikirim (karyawan aktif, tanpa duplikat), bukan dari snapshot PIC di header. Placeholder {pic} pada pesan admin berasal dari snapshot nama_pic, sehingga pada ruangan ber-PIC banyak bisa menampilkan nama PIC pembuat transaksi, bukan PIC yang benar-benar bertindak. Rute tujuan: asset_pic_ruangan_upgrade (PIC, membawa id) dan asset_admin_detail_upgrade_ruangan (Admin). Notifikasi dibuat setelah transaksi database sukses; kegagalan kirim tidak membatalkan transaksi.

35Security

• JWT wajib; ctx memuat id_company dan id_karyawan. Seluruh query dibatasi id_company (diuji: company lain tidak dapat melihat atau mengubah).
• Endpoint admin memeriksa asset_admin; sisi PIC dibatasi wherePic (PIC ruangan saat ini), termasuk pada pelepasan dan terima lewat lockHeader: hanya PIC aktif ruangan yang sah dapat menyerahkan atau menerima aset. Karena Terima kini langsung menyelesaikan upgrade tanpa pemeriksaan admin, hak akses PIC ini satu-satunya kontrol atas penyelesaian (lihat RISK-012).
• Aset dikunci FOR UPDATE, company dikunci per transaksi untuk mencegah nomor ganda; pemeriksaan fase di dalam transaksi mencegah submit ganda.
• Input divalidasi di controller dan model; tidak ada query mentah dari input pengguna.
• Foto/berkas: tidak dipakai di alur ini.

36Manual Book User/Admin

PIC Ruangan: mengajukan upgrade

1. Buka Asset → PIC Ruangan, ketuk Upgrade Komponen, lalu ikon +.
2. Pilih Ruangan (otomatis bila hanya satu), pilih Aset, pilih komponen yang diupgrade dan isi detail upgrade tiap komponen.
3. Isi Alasan dan Urgensi, ketuk Ajukan Upgrade.
4. Pantau status di daftar (tab Pengajuan/Proses/Selesai). Bila ditolak, alasan terlihat di detail.

PIC Ruangan: menyerahkan aset

1. Setelah Admin/HR menyetujui dan menetapkan jadwal, banner di beranda PIC Ruangan meminta aset diserahkan. Tidak ada pemeriksaan/checklist oleh admin.
2. Pada jadwal, serahkan aset kepada petugas lalu ketuk Serahkan Aset dan konfirmasi.

PIC Ruangan: menerima aset hasil upgrade

1. Setelah hasil dicatat, banner meminta aset diterima. Periksa fisik aset secara mandiri (aplikasi tidak lagi mencatat kondisi komponen).
2. Ketuk Terima Aset lalu konfirmasi. Upgrade langsung selesai: atribut aset diperbarui (bila hasil Selesai) dan aset kembali aktif di ruangan. Tindakan ini tidak dapat dibatalkan dari aplikasi.

Admin/HR: memproses pengajuan

1. Buka Asset → Ruangan → Upgrade, tab Pengajuan, pilih transaksi.
2. Tinjau ruangan, PIC, alasan, urgensi, komponen. Pilih Tolak (isi alasan) atau Setujui & Jadwalkan (pilih tanggal dan jam pengambilan).

Admin/HR: inisiasi langsung (Jalur B)

1. Di daftar Upgrade, ketuk + (Buat Upgrade).
2. Pilih ruangan (PIC tampil otomatis), aset, komponen, isi catatan, tetapkan jadwal pengambilan, simpan.

Admin/HR: jadwal dan hasil

1. Tab Proses, buka transaksi. Selama menunggu pengambilan atau pengembalian, Ubah Jadwal tersedia.
2. Setelah PIC menyerahkan aset (status Dalam Service), pilih status hasil (Selesai atau Tidak Dapat Diupgrade), isi nilai baru tiap komponen (bila selesai), biaya, keterangan, ketuk Simpan Hasil & Jadwalkan dan tetapkan jadwal pengembalian.
3. Selesai bagi admin. Penyelesaian dilakukan PIC saat menekan Terima Aset; tidak ada tombol Selesaikan atau Kirim Ulang lagi.

37Kondisi Button

Karena aksi dari server tidak mengenal peran, tombol di mobile ditentukan oleh peran dan flag sekaligus (_admin dan aksi.*); PIC tidak pernah melihat tombol admin dan sebaliknya (diuji di mobile). Admin pada fase menunggu_pengambilan hanya melihat Ubah Jadwal (tidak ada tombol checklist).

38Testing Scenario

Dijalankan ulang saat v1.2 disusun (30 Oktober 2026): vendor/bin/phpunit tests/Asset/AssetUpgradeRuanganTest.php 15 test, 186 assertion lolos; seluruh vendor/bin/phpunit tests/Asset 499 test, 5111 assertion lolos; mobile flutter test --no-pub test/asset/asset_upgrade_ruangan_test.dart 15 test lolos (Flutter 3.35.6). Jumlah v1.1 (16 test API dan 16 test mobile) turun karena skenario checklist, Selesaikan, dan Kirim Ulang dihapus.

39Temuan Ketidaksesuaian

Dokumen bisnis RGN07 tidak tersedia saat dokumen ini disusun (⚠️ Belum ditemukan). Perbandingan dilakukan terhadap KRY03 dan keputusan sesi.

40Edge Case

41Potential Bug / Technical Risk

42Dependency

• Data master: asset_lokasi_m (tipe ruangan, status_aktif), asset_lokasi_pic_m, asset_kategori_m, data_karyawan, asset_admin, asset_data, asset_data_item.
• Modul lain: Upgrade Karyawan KRY03 (helper bersama), Retur Ruangan RGN06, Onboarding Ruangan RGN01, Penambahan Ruangan RGN04 (saling mengunci aset), asset_trx_log, notifikasi (notif_data, FCM).
• Urutan SQL: PML04 (disposal) → RGN06 (retur ruangan) → upgrade ruangan, karena enum jenis_log dibangun berurutan dan diakhiri retur_ruangan sebelum upgrade_ruangan ditambahkan.
• SQL migrasi data lama (ketergantungan rilis v1.2): Claude outputs/sql-upgrade-hapus-checklist-review-lama.sql, belum dijalankan; mencakup upgrade karyawan dan ruangan. Skema tidak berubah sehingga tidak ada SQL DDL baru.
• Berbagi komponen mobile: HalamanAssetUpgrade, HalamanTambahAssetUpgrade, HalamanDetailAssetUpgrade, AssetUpgradeBloc, AssetUpgradeApi, showAssetPickerSheet.

43Source Code Reference

44Developer Notes

• Skema mengikuti KRY03 ditambah konvensi tabel ruangan: jadwal NULL (bukan 0000-00-00), snapshot ruangan dan PIC di header, no_trx unik per company.
• Dua kolom status disimpan (status_approval, fase_upgrade); bila menambah fase, ubah enum di DBML/SQL, upgradeStatusMetadata (dipakai bersama KRY03), dan stepper mobile.
• Sejak v1.2 hanya ada satu jenis id_item: id baris item upgrade (items[]) pada hasil. Id komponen aset pada checklist sudah tidak dipakai.
• Pembaruan atribut hanya terjadi saat PIC menekan Terima (terima) dan hanya bila status_hasil='selesai'; komponen dicocokkan lewat id_asset_data_item + id_komponen dalam kelengkapan_item.
• Mobile memakai satu bloc dan satu set halaman untuk dua modul; selalu teruskan untukRuangan/ruangan: true pada rute baru agar basis URL benar.

Catatan verifikasi

Dijalankan ulang saat v1.2 disusun (30 Oktober 2026):

• vendor/bin/phpunit tests/Asset/AssetUpgradeRuanganTest.php: 15 test, 186 assertion, lolos.
• vendor/bin/phpunit tests/Asset: 499 test, 5111 assertion, lolos.
• Jumlah route diambil dari routes/modules/asset/RouteAsset.php: grup upgrade-ruangan 7 route + grup PIC upgrade 6 route = 13. php artisan routes:list dan total route aplikasi tidak dijalankan ulang pada v1.2.
• Mobile flutter test --no-pub test/asset/asset_upgrade_ruangan_test.dart: 15 test lolos (Flutter 3.35.6).

Tidak dijalankan ulang di sini: suite mobile test/asset penuh dan suite API penuh di luar tests/Asset (kegagalan lama pada v1.1 terkait fixture jumlah route dan JwtAuthTest, tidak terkait modul ini).

Tidak dapat diverifikasi dari kode: (1) SQL skema asal telah dijalankan di database dan struktur enum/FK MariaDB benar (pernyataan pengguna; komentar header SQL sudah berbunyi "SUDAH DIJALANKAN"); (2) alur nyata di server/emulator dan push notifikasi; (3) dokumen bisnis RGN07 (tidak ada); (4) SQL migrasi data lama belum dijalankan dan sintaksnya belum diuji di DB.

45End-to-End Traceability

45.4 Walkthrough Lengkap dengan Contoh Data

Bagian ini mengikuti satu upgrade (Jalur A) dari pengajuan PIC sampai atribut diperbarui: PIC Ruangan mengajukan upgrade RAM, Admin/HR menyetujui, PIC menyerahkan aset, Admin mencatat hasil upgrade, lalu PIC menerima aset kembali dan upgrade langsung selesai (alur v1.2, tanpa checklist dan tanpa review akhir). Variasi (tolak, Jalur B, hasil tidak_dapat_diupgrade, ubah jadwal) dijelaskan sesudahnya. Setiap langkah menjelaskan apa yang dilakukan di mobile, apa yang dikirim, apa yang diproses API, apa yang tersimpan di database, dan apa yang diterima mobile. Data bersifat sintetis, tetapi nama kolom, urutan proses, dan pesan diambil dari kode (AssetUpgradeRuangan_m, AssetKaryawanUpgradeRuangan_c, AssetAdminUpgradeRuangan_c, AssetNotification). Penomoran langkah v1.2 lebih pendek dari v1.1 (langkah checklist pengambilan, checklist penerimaan, dan Selesaikan Upgrade dihapus).

Data awal

Company CMP001. Pengajuan 22 Oktober 2026, periode ID 202610. Belum ada upgrade, log, atau notifikasi pada periode ini.

data_karyawan

asset_lokasi_m: LOK0007 "Ruang Meeting Lt.2" (tipe = ruangan, status_aktif = 1, cabang "Jakarta", departemen "Operasional"); asset_lokasi_pic_m menunjuk KRY0030.

asset_data: AST0601 "PC Meeting Dell" (kategori "Komputer"), status_asset = terpakai, pemegang_asset = ruangan, id_pemegang_asset = LOK0007, id_asset_lokasi_m = LOK0007, kondisi_awal = normal.

asset_data_item milik AST0601 (hanya flag_spesifikasi 1 atau 2 yang bisa dipilih)

Setiap field komponen (kecuali bertipe file) menjadi satu atribut dengan id_atribut = id_asset_data_item|id_komponen, misalnya CMP001ITEM0201|ram.

Penomoran: header dan item id_company + YYYYMM + 3 digit, no_trx = RGN07-YYYYMMNNN; asset_trx_log dan notifikasi 5 digit. Selama proses, pemegang_asset tetap ruangan; hanya status_asset yang berubah (dalam_perbaikan), sehingga aset tetap tercatat milik ruangan. Penerima notifikasi sisi ruangan adalah semua PIC aktif ruangan (pada skenario hanya Dewi).

Langkah 0 — PIC membuka form

Mobile: halaman PIC Ruangan → Upgrade → + → form Ajukan Upgrade Asset Ruangan → API opsi.

Dikirim

GET /asset/karyawan/pic-ruangan/upgrade/options
Authorization: Bearer <access_token_dewi>

Diproses API (AssetUpgradeRuangan_m::getOptions): ruangan aktif milik PIC login, beserta aset terpakai milik ruangan itu yang tidak terkunci flow lain (retur, onboarding, penambahan, upgrade aktif) dan punya atribut spesifikasi; ditambah daftar urgensi. Database: hanya SELECT.

Diterima mobile (ringkas)

{ "code": "SUCCESS", "message": "Opsi upgrade asset ruangan berhasil ditemukan.",
  "data": {
    "ruangan": [ { "id_asset_lokasi_m": "LOK0007", "nama_ruangan": "Ruang Meeting Lt.2",
      "cabang": "Jakarta", "divisi": "Operasional",
      "pic": { "id_karyawan": "KRY0030", "nik": "EMP-030", "nama": "Dewi PIC" },
      "assets": [ { "id_asset_data": "AST0601", "kode_asset": "PC-0601", "nama_asset": "PC Meeting Dell",
        "kategori_asset": "Komputer", "merek": "Dell", "id_asset_lokasi_m": "LOK0007",
        "atribut": [
          { "id_atribut": "CMP001ITEM0201|ram", "id_asset_data_item": "CMP001ITEM0201", "id_komponen": "ram",
            "nama_item": "PC Meeting Dell", "jenis": "aset_utama", "label": "RAM", "satuan": "GB", "nilai": "8" },
          { "id_atribut": "CMP001ITEM0202|panel", "id_asset_data_item": "CMP001ITEM0202", "id_komponen": "panel",
            "nama_item": "Monitor 24 inch", "jenis": "kelengkapan", "label": "Panel", "satuan": "", "nilai": "IPS" } ] } ] } ],
    "urgensi": [ { "value": "normal", "label": "Normal" }, { "value": "secepatnya", "label": "Secepatnya" },
                 { "value": "mendesak", "label": "Mendesak" } ] } }

Hanya ruangan yang punya aset layak yang muncul. Pesan dan label urgensi mengikuti header locale (Indonesia atau Inggris). Bila satu ruangan punya lebih dari satu PIC, daftar opsi memakai PIC pertama; pada pengajuan PIC, ruangan yang tampil hanya yang dipegang PIC login.

Langkah 1 — PIC mengajukan upgrade

Mobile: Dewi memilih ruangan dan PC Meeting, mencentang atribut RAM, mengisi detail "8 GB menjadi 16 GB", alasan, dan urgensi Secepatnya, lalu Ajukan Upgrade.

Dikirim

POST /asset/karyawan/pic-ruangan/upgrade

{ "id_asset_lokasi_m": "LOK0007", "id_asset_data": "AST0601",
  "alasan": "Aplikasi presentasi sering lambat", "urgensi": "secepatnya",
  "items": [ { "id_atribut": "CMP001ITEM0201|ram", "detail_upgrade": "8 GB menjadi 16 GB" } ] }

Diproses API (storeUpgradeRuangan → storePic → insertTransaction, satu DB::transaction(…, 3))

1. Validasi controller: id_asset_lokasi_m ("Ruangan wajib dipilih."), id_asset_data, alasan ("Alasan upgrade wajib diisi.", maksimal 1000), urgensi ∈ normal/secepatnya/mendesak ("Urgensi wajib dipilih."), items minimal satu ("Minimal satu komponen wajib dipilih."), id_atribut tidak kembar, detail_upgrade wajib ("Detail upgrade setiap komponen wajib diisi.", maksimal 255).
2. lockCompany; activeKaryawan ("Karyawan tidak ditemukan atau tidak aktif."); findRuangan dengan filter PIC (ruangan harus aktif dan milik Dewi); urgensi dan alasan diperiksa lagi di model ("Urgensi upgrade tidak valid." / "Alasan upgrade wajib diisi.").
3. Aset diambil FOR UPDATE dengan syarat pemegang_asset = ruangan dan lokasi = ruangan ini ("Asset bukan milik ruangan atau tidak ditemukan."); status harus terpakai ("Hanya asset berstatus terpakai yang dapat diupgrade.").
4. assetBlockMessage: tidak boleh ada upgrade lain ("Asset sedang diproses pada upgrade lain."), retur ("…pada retur."), onboarding ruangan ("…pada onboarding ruangan.") atau penambahan ruangan ("…pada penambahan asset ruangan.") yang aktif.
5. normalizeItems: atribut harus ada pada aset ("Komponen upgrade tidak ditemukan pada asset."), tidak boleh kembar ("Komponen yang sama tidak boleh dipilih lebih dari sekali."), detail wajib.
6. Nomor: CMP001202610001, RGN07-202610001. INSERT header (sumber_pengajuan = karyawan, status_approval = proses, fase_upgrade = pengajuan, jadwal belum terisi) dan satu item per atribut (snapshot JSON dan nilai_lama).
7. asset_data tidak berubah. Controller mengirim upgrade_ruangan.diajukan ke semua admin asset.

Hasil database

asset_trx_upgrade_ruangan

asset_trx_upgrade_ruangan_item

notif_data (2 baris, satu per admin asset)

Diterima mobile (HTTP 201)

{ "code": "CREATED", "message": "Pengajuan upgrade asset ruangan berhasil dikirim.",
  "data": { "id": "CMP001202610001", "no_trx": "RGN07-202610001", "status_approval": "proses",
            "fase_upgrade": "pengajuan", "status_label": "Menunggu Persetujuan", "tab": "pengajuan" } }

Langkah 2 — Admin menyetujui dan menjadwalkan pengambilan

Mobile: notifikasi membuka detail admin (tombol review aktif). Siti memilih Setujui, mengisi 23 Okt 2026 pukul 10:00 dan catatan.

Dikirim

POST /asset/upgrade-ruangan/CMP001202610001/review

{ "keputusan": "disetujui", "ket_tolak": "", "tgl_jadwal": "2026-10-23", "jam_jadwal": "10:00",
  "keterangan_jadwal": "Bawa ke ruang IT" }

Diproses API (reviewUpgradeRuangan → review)

1. Validasi: keputusan ∈ disetujui/ditolak; ket_tolak wajib bila ditolak.
2. lockCompany; aktor harus admin asset ("Pengguna tidak terdaftar sebagai admin asset."); lockHeader ("Upgrade asset tidak ditemukan.").
3. Header harus status_approval = proses ("Pengajuan upgrade sudah direview.").
4. Setuju: aset masih terpakai dan dipegang ruangan ini (lockHeldAsset: "Status asset sudah berubah atau tidak lagi dipegang ruangan."); jadwal wajib Y-m-d + H:i dan tidak sebelum tgl_pengajuan ("Tanggal serah terima tidak boleh sebelum tanggal pengajuan.").
5. UPDATE header; controller mengirim upgrade_ruangan.disetujui ke semua PIC ruangan.

Hasil database

Diterima mobile (HTTP 200): status_approval = disetujui, fase_upgrade = menunggu_pengambilan, status_label = "Menunggu Pengambilan", tab = "proses", message "Review upgrade asset ruangan berhasil disimpan.". Selama fase ini Admin dapat Ubah Jadwal (PUT …/jadwal): hanya kolom jadwal pengambilan yang berubah, dengan notifikasi upgrade_ruangan.dijadwalkan ("Jadwal Upgrade Diperbarui").

Langkah 3 — PIC menyerahkan aset

Mobile: setelah disetujui, PIC langsung melihat tombol. Pada jadwal, banner di halaman PIC Ruangan → Serahkan Aset → konfirmasi. Tidak ada pemeriksaan/checklist oleh admin.

Dikirim

POST /asset/karyawan/pic-ruangan/upgrade/CMP001202610001/pelepasan

Tanpa body.

Diproses API (pelepasan)

1. Karyawan aktif; header dicari dengan syarat PIC login adalah PIC aktif ruangan itu (lockHeader + wherePic; selain itu "Upgrade asset tidak ditemukan.").
2. Fase harus menunggu_pengambilan ("Aset belum siap diserahkan untuk upgrade."). Tidak ada syarat checklist.
3. lockHeldAsset (status terpakai atau dalam_perbaikan, masih dipegang ruangan).
4. UPDATE asset_data → dalam_perbaikan; INSERT asset_trx_log (ruangan → gudang, kondisi_akhir = kondisi_awal); UPDATE header.
5. Controller mengirim upgrade_ruangan.dilepas ke semua admin.

Hasil database

Diterima mobile (HTTP 200): message "Aset berhasil diserahkan untuk upgrade.", fase_upgrade = dalam_service.

Langkah 4 — Admin mencatat hasil upgrade

Mobile: setelah upgrade dikerjakan teknisi, Siti membuka Hasil Upgrade, memilih status Selesai, mengisi nilai baru, biaya, keterangan, dan jadwal pengembalian 26 Okt 2026 pukul 09:00.

Dikirim

POST /asset/upgrade-ruangan/CMP001202610001/hasil

{ "status_hasil": "selesai", "keterangan_hasil": "RAM diganti 16 GB", "biaya_upgrade": 450000,
  "tgl_jadwal": "2026-10-26", "jam_jadwal": "09:00", "keterangan_jadwal": "Ambil di ruang IT",
  "items": [ { "id_item": "CMP001202610001", "nilai_baru": "16" } ] }

(id_item adalah id item upgrade; satu-satunya jenis id_item sejak checklist dihapus.)

Diproses API (hasilUpgradeRuangan → hasil)

1. Validasi: status_hasil ∈ selesai/tidak_dapat_diupgrade, keterangan_hasil wajib (maksimal 1000), biaya_upgrade bilangan bulat ≥ 0.
2. Fase harus dalam_service ("Aset belum berada dalam proses upgrade."); status hasil, keterangan, dan biaya diperiksa ulang di model ("Status hasil upgrade tidak valid." / "Keterangan hasil upgrade wajib diisi." / "Biaya upgrade tidak boleh negatif."); jadwal pengembalian wajib dan tidak sebelum tgl_pengajuan.
3. Bila selesai, setiap item wajib punya nilai_baru ("Nilai baru setiap atribut wajib diisi."); bila tidak_dapat_diupgrade, nilai_baru dikosongkan dan alasan_tidak_upgrade diisi keterangan.
4. UPDATE item dan header (tgl_diterima direset NULL); belum ada perubahan data komponen aset. Controller mengirim upgrade_ruangan.pengembalian ke semua PIC ruangan.

Hasil database

Diterima mobile (HTTP 200): message "Hasil upgrade berhasil disimpan.", fase_upgrade = menunggu_pengembalian.

Langkah 5 — PIC menerima aset kembali (langsung selesai)

Mobile: pada 26 Okt Dewi memeriksa PC di ruangan secara mandiri, lalu Terima Aset → konfirmasi. Tidak ada form checklist.

Dikirim

POST /asset/karyawan/pic-ruangan/upgrade/CMP001202610001/terima

Tanpa body (body apa pun diabaikan).

Diproses API (terimaUpgradeRuangan → terima, satu DB::transaction(…, 3))

1. PIC aktif dan PIC aktif ruangan itu (lockHeader + wherePic); fase harus menunggu_pengembalian ("Aset belum dijadwalkan untuk dikembalikan."); aset harus masih dalam_perbaikan dan dipegang ruangan ("Status asset sudah berubah atau tidak lagi dipegang ruangan.").
2. status_hasil = selesai → applyAtribut: nilai komponen[].value pada asset_data_item.json_value diganti dengan nilai_baru.
3. UPDATE asset_data → terpakai; INSERT asset_trx_log (gudang → ruangan); UPDATE header → selesai.
4. Controller mengirim upgrade_ruangan.diterima ke semua admin (pesan berakhiran "Upgrade selesai.").

Hasil database

Diterima mobile (HTTP 200): message "Aset hasil upgrade berhasil diterima.", status_label = "Selesai", fase_upgrade = selesai, tab selesai. Tidak ada tindakan lanjutan dari admin.

Kondisi akhir

Variasi

• Penolakan. Pada langkah 2 Admin memilih ditolak dengan ket_tolak: header status_approval = ditolak, status_transaksi = selesai, fase_upgrade = selesai, ket_tolak terisi, user_approval/tgl_approval terisi. Tidak ada perubahan asset_data. Notifikasi upgrade_ruangan.ditolak ("Pengajuan upgrade RGN07-… untuk Ruang … ditolak admin.") ke semua PIC ruangan. Tanpa alasan: "Alasan penolakan wajib diisi.".
• Jalur B (Admin langsung). Admin memanggil POST /asset/upgrade-ruangan dengan id_asset_lokasi_m, id_asset_data, catatan, items[] (id_atribut, detail_upgrade), tgl_jadwal, jam_jadwal. storeAdmin memakai PIC dari master ruangan, membuat header langsung status_approval = disetujui dan fase_upgrade = menunggu_pengambilan dengan jadwal pengambilan, sumber_pengajuan = admin, alasan/urgensi kosong, dan user_approval diisi admin. Notifikasi upgrade_ruangan.disetujui. Langkah 3 dan seterusnya sama. Respons CREATED, "Upgrade asset ruangan berhasil dibuat.".
• Hasil tidak_dapat_diupgrade. Pada langkah 4 Admin memilih status Tidak Dapat Diupgrade (tanpa nilai baru) dan mengisi keterangan, misalnya "Slot RAM penuh". Database: item nilai_baru = '' dan alasan_tidak_upgrade = keterangan hasil (maksimal 255 karakter); header status_hasil = tidak_dapat_diupgrade, fase menunggu_pengembalian; asset_data tetap dalam_perbaikan. Pada langkah 5 PIC tetap menekan Terima: applyAtribut dilewati sehingga asset_data_item tidak berubah (RAM tetap 8 GB), aset kembali terpakai, log gudang → ruangan tetap ditulis, header selesai dengan tgl_diterima terisi, dan notifikasi diterima ke admin. Hasil ini diuji (test_admin_created_failed_upgrade_keeps_attribute).
• Ubah jadwal. PUT …/jadwal hanya pada fase menunggu_pengambilan (mengubah jadwal pengambilan) atau menunggu_pengembalian (mengubah jadwal pengembalian); fase lain ditolak dengan "Jadwal hanya dapat diubah sebelum serah terima dilakukan.". Notifikasi upgrade_ruangan.dijadwalkan ke semua PIC ruangan.

Kasus gagal

Pesan mengikuti header locale (Indonesia atau Inggris); tabel memuat versi Indonesia. Semua kesalahan aturan bisnis dilempar sebagai InvalidArgumentException di dalam transaksi, sehingga seluruh perubahan di-rollback dan controller membalas BUSINESS_RULE_VIOLATION.

Ringkasan siapa mengerjakan apa

46Ringkasan Database Impact

47Checklist Implementasi

• DBML diperbarui ([NEW ALK-RGN Upgrade])
• SQL manual dibuat (sql-alk-rgn-upgrade-ruangan.sql)
• SQL manual dijalankan pengguna dan diuji via model (pernyataan pengguna; urutan PML04 → RGN06 → upgrade ruangan)
• Komentar header SQL diperbarui ("SUDAH DIJALANKAN", diverifikasi di file)
• Model, controller, route, notifikasi API (13 endpoint, 7 event; v1.2)
• Checklist pengambilan/pengembalian dan review akhir (Selesaikan/Kirim Ulang) dihapus dari API dan mobile (v1.2)
• Perubahan modul lain: retur ruangan, helper KRY03, summary admin, beranda PIC
• Test API (15, 186 assertion) dan seluruh tests/Asset (499) lolos
• Model, API client, halaman, route, teks mobile
• Test mobile (15) lolos
• Jalankan SQL migrasi data lama sql-upgrade-hapus-checklist-review-lama.sql (guard 0.a, salinan/staging dulu) sebelum atau bersamaan dengan rilis v1.2 (RISK-011)
• Bersihkan kunci lokalisasi mobile dan pesan validasi controller yang tak terpakai (sisa v1.2, INC-10)
• Uji end-to-end di server/emulator, termasuk push notifikasi
• Keputusan RISK-012 (kondisi komponen tidak tercatat)
• Aksi batal oleh Admin (belum ada, RISK-001)
• Perbarui fixture jumlah route (RISK-008, di luar scope)

48Changelog