Bangun antrean verifikasi admin yang hanya memproses donasi pending berbukti. Approve menjadi verified, reject menjadi rejected, dan trigger status tetap menjadi pagar terakhir.
Bukti transfer sudah masuk. Sekarang ada pekerjaan manusia: memutuskan apakah bukti itu valid.
Di aplikasi donasi, keputusan admin harus hati-hati. Tombol “Approve” bukan tombol kosmetik. Ia mengubah makna uang di sistem:
textpending → verifiedTombol “Reject” juga bukan sekadar label:
textpending → rejectedKeduanya harus mengikuti aturan transisi status yang sudah ada di database.
Migration awal membuat trigger check_donation_status_transition:
sqlif not (
(old.status = 'pending' and new.status in ('verified','rejected','cancelled')) or
(old.status = 'verified' and new.status = 'refunded')
) then
raise exception 'Transisi status donasi tidak diizinkan: % -> %', old.status, new.status;
end if;Untuk halaman verifikasi manual, kita hanya membuka dua aksi:
pending → verified;pending → rejected.cancelled dan refunded memang ada di sistem, tapi bukan bagian dari queue verifikasi bukti. Jangan tampilkan semua status hanya karena enum menyediakan banyak pilihan.
Donasi yang muncul di queue harus memenuhi dua syarat:
textstatus = pending
proof_path is not nullKalau donasi belum punya bukti, admin belum punya bahan untuk memutuskan. Kalau donasi sudah verified atau rejected, ia tidak perlu muncul lagi di queue.
Urutkan dari yang paling lama agar admin memproses antrean secara adil:
textorder by proof_uploaded_at asc nulls last, created_at ascBayangkan dua admin membuka queue yang sama. Keduanya klik Approve untuk donasi yang sama.
Kalau action hanya menulis:
sqlupdate donations set status = 'verified' where donation_number = ...;request kedua bisa ikut merasa sukses, walaupun donasi sudah diputus.
Gunakan conditional update:
textwhere donation_number = ...
and status = 'pending'
and proof_path is not nullKalau update mengembalikan 0 row, artinya donasi sudah tidak memenuhi syarat: mungkin sudah diproses admin lain, bukti hilang, atau nomor salah. UI harus meminta refresh, bukan pura-pura sukses.
Halaman admin yang disembunyikan di URL tidak cukup. Aksi approve/reject harus mengecek admin di server.
Pola dari Module 03 tetap dipakai:
Jangan hanya menyembunyikan tombol. Orang bisa memanggil action secara langsung jika server action tidak punya guard.
textMulai dari AGENTS.md, DESIGN.md, dan docs/README.md.
Tugas: buat queue verifikasi donasi untuk admin.
Baca:
- docs/project-rules.md
- docs/data-contract.md
- supabase/migrations/20260829_vertical_slice.sql
- migration upload bukti transfer
- pola admin guard dari Module 03 jika sudah ada
Business rule:
1. Queue hanya menampilkan donations dengan status='pending' dan proof_path tidak null.
2. Approve hanya boleh mengubah pending -> verified dan mengisi verified_at = now().
3. Reject hanya boleh mengubah pending -> rejected. Jika ada reject reason, simpan sebagai metadata/catatan yang aman.
4. Trigger check_donation_status_transition tetap aktif dan tidak boleh diubah.
5. Update harus conditional: donation_number cocok, status masih pending, proof_path tidak null.
6. Non-admin tidak boleh melihat queue dan tidak boleh menjalankan action.
7. Setelah action, data diambil ulang dari server; jangan hanya ubah label di client.
Implementasi:
- halaman /admin/verifications untuk daftar donasi pending berbukti.
- server action approveDonation dan rejectDonation.
- tampilkan donation_number, nominal, metode, nama snapshot secukupnya untuk admin, waktu upload bukti, dan tombol approve/reject.
- UI harus jelas, tidak manipulatif, dan tidak memakai elemen yang melanggar batas syar'i.
Acceptance criteria:
- Admin melihat queue pending berbukti.
- Approve mengubah status ke verified dan mengisi verified_at.
- Reject mengubah status ke rejected.
- Donasi tanpa proof_path tidak muncul dan tidak bisa di-approve.
- Non-admin ditolak.
- Transisi ilegal seperti pending -> refunded tetap ditolak trigger.
- npm run lint dan npm run build berhasil.
Laporkan file yang diubah dan cara verifikasinya.Prompt ini mulai dari business rule. Implementasi mengikuti aturan, bukan sebaliknya.
Cek action:
bashgrep -RIn "approveDonation\|rejectDonation\|verified_at\|status.*pending\|proof_path" src/app src/libCek trigger masih ada:
bashgrep -n "check_donation_status_transition\|pending.*verified\|verified.*refunded" supabase/migrations/*.sqlCek via SQL setelah approve:
sqlselect donation_number, status, proof_path, verified_at
from public.donations
order by created_at desc
limit 10;Yang diharapkan:
verified, verified_at terisi;rejected;Uji transisi ilegal:
sqlupdate public.donations
set status = 'refunded'
where status = 'pending';Expected: ditolak oleh trigger. Kalau berhasil, pagar status rusak.
Uji race sederhana:
Admin perlu melihat bukti transfer. Tapi bukti tetap berada di bucket privat. Untuk tampilan admin, gunakan signed URL atau route server yang mengecek admin sebelum membaca object.
Jangan mengubah bucket menjadi public hanya agar <img src> gampang dipakai.
Kalau agent mengusulkan itu, tolak.
Verifikasi pembayaran adalah perubahan status yang punya konsekuensi. Karena itu:
pending dengan proof_path.verified dan verified_at.rejected.Sekarang sistem mulai punya proses operasional: bukti masuk, admin menilai, status berubah lewat jalur yang sah. Bagian berikutnya adalah mengubah status verified menjadi angka transparansi yang bisa dilihat publik tanpa membocorkan data donatur.
Kuis ini wajib untuk sertifikat. Kamu tetap bisa lanjut ke pelajaran berikutnya dan mengerjakannya nanti.
Ajukan pertanyaan, beri solusi, atau diskusikan materi pelajaran ini.
Belum ada komentar untuk pelajaran ini.
Jadilah yang pertama memulai diskusi atau mengajukan pertanyaan!