Topologi Roles & Approval

Peninjauan menyeluruh model RBAC, hierarki multi-tenant, dan alur persetujuan berlapis pada platform Koperasi Merah Putih — diturunkan langsung dari kode backend yang sudah berjalan.

8Roles
15Permissions
3Domain
6Tingkat Tenant
2Level Approval
5Metode Auth

1 Hierarki Multi-Tenant

Setiap record transaksi wajib membawa konteks tenant + wilayah + actor + device. Token JWT membawa wpath (mis. nasional/jawa-barat/bandung/kop-xyz) yang menentukan isolasi data Row-Level Security di Postgres.

RLS root
Tingkat 1 — Nasional
Kementerian Koperasi
Pengawasan & kontrol pusat · nasional
Tingkat 2 — Provinsi
Wilayah Provinsi
Agregasi regional · provinsi
Tingkat 3 — Kabupaten/Kota
Wilayah Kab/Kota
Drill-down kabupaten · kab_kota
tenant operasional
Tingkat 4 — Koperasi
Koperasi (Tenant)
Entitas legal, simpan-pinjam, anggota · koperasi
Tingkat 5 — Outlet
Outlet / Toko
Lokasi POS fisik · outlet
Tingkat 6 — Perangkat
Device
Tablet POS / HP petugas / browser web
No-bypass: query tanpa konteks tenant = error. Middleware TenantResolver mem-parse JWT → SET LOCAL app.current_tenant_id dijalankan dalam transaction sebelum query apa pun.

2 Peta Roles per Domain

8 role tersebar di 3 domain operasional. Penamaan mengikuti pola <domain>.<role>. Satu pengguna dapat memegang beberapa role sekaligus (mis. kop.bendahara + kop.admin).

Permission operasional Approval / pencairan Administrasi Audit
🔑
Aturan spesifik spec: approval pinjaman L1 = Bendahara, L2 = Ketua. Ketua tidak bisa meng-approve L1 — pemisahan tegas agar satu orang tidak menutup dua level sekaligus.

3 Matriks RBAC — Role × Permission

Sumber kebenaran tunggal evaluasi RBAC: shared/rbac/permission.goRolePermissions. Arahkan kursor ke baris untuk menyorot.

📋
pusat.kementerian memegang seluruh 15 permission (super-admin nasional). pusat.auditor bersifat read-only — hanya audit & laporan, tanpa satu pun permission mutasi.

4 Alur Approval Pinjaman Berlapis

State machine Temporal LoanOriginationWorkflow. Persetujuan dua level dengan timeout otomatis — jika approver tidak merespons, aplikasi ditolak otomatis oleh sistem.

statesubmitted
activityValidasianggota aktif
activityScoringrisk score
statescored
approval L1Bendaharatimeout 7 hari
stateapproved_l1
approval L2Ketuatimeout 3 hari
stateapproved_l2
activityPencairanloan:disburse
state finaldisbursed
JALUR PENOLAKAN — di tiap level approval
L1 / L2Tolak
atauTimeoutL1=7h · L2=3h
state finalrejected+ alasan & aktor

Level 1 — Bendahara

Permission loan:approve:level1. Sinyal Temporal approval_l1. Menilai kelayakan awal & scoring.

Level 2 — Ketua

Permission loan:approve:level2. Sinyal approval_l2. Keputusan final sebelum pencairan.

Pencairan

Permission loan:disburse dipegang Bendahara & Ketua. Memicu event loan.disbursed.

Anti-skip

Sistem menolak transisi mundur / lompat state. Urutan L1 → L2 dipaksa workflow engine, bukan konvensi.

5 Alur Settlement Transaksi POS

POSTransactionSettlementWorkflow — menegakkan aturan offline kritikal PDF §15.3: transaksi tunai boleh final offline, QRIS wajib diverifikasi server sebelum ditandai lunas.

activityValidasi Txndevice · outlet · shift
activityCek Idempotensidevice + client id
CABANG A — Pembayaran QRIS (digital, tidak boleh final offline)
activityVerifikasi QRIS60s · retry 3×
belum konfirmTunggu callbacksinyal · maks 5 menit
konfirmasiPost Ledger
finalpaid
callback timeout 5mMark Failed
finalfailed
CABANG B — Tunai / Kartu / Transfer (boleh final offline)
activityPost Ledgerlangsung
finalpaid

State POS-spesifik

pending_payment
paid
failed
synced
sync_exception
cancelled
refunded
Enforcement server-side: sync-svc menolak batch offline yang melanggar aturan — QRIS > 5 menit (OFFLINE_PAYMENT_EXPIRED), approval pinjaman dari device (LOAN_APPROVAL_OFFLINE), posting settlement dari device (SETTLEMENT_OFFLINE).

6 Segregation of Duties & Maker-Checker

Kontrol pemisahan tugas memastikan tidak ada satu aktor pun yang dapat menjalankan proses kritikal dari awal sampai akhir tanpa pihak kedua.

Maker ≠ Checker Pinjaman

Pengajuan (member:create) terpisah dari approval. L1 & L2 dipegang role berbeda — Bendahara lalu Ketua.

L1 ≠ L2

Tidak ada role tunggal yang punya loan:approve:level1 dan level2 sekaligus — kecuali super-admin pusat.kementerian.

Kasir vs Supervisor

Kasir hanya pos:sale + sync:intake. Pelaporan (report:read) butuh role Supervisor.

Verifikasi Anggota

Pembuatan anggota (member:create) terpisah dari verifikasi (member:verify) — verify hanya di kop.admin.

Auditor Read-Only

pusat.auditor tidak punya permission mutasi apa pun — pengawasan tidak boleh mengubah data yang diawasi.

Audit Log Immutable

Setiap mutasi memancarkan event audit (aktor, before/after, justifikasi) ke schema audit yang INSERT-only.

7 Peta Proteksi Endpoint

Tiap grup route dijaga middleware RequirePermission. Bila tercantum dua permission, berlaku logika OR — salah satu cukup.

ServiceGrup EndpointPermission DiperlukanRole Pemegang Tipikal

8 Autentikasi, Device & Channel

JWT RS256 membawa tid, wpath, roles, did (device-bound), dan ameth (metode auth).

Metode Autentikasi

PIN

pin — Petugas Lapangan & Kasir login NoHP + PIN 4–6 digit.

MFA TOTP

mfa_totp — operator web koperasi & pusat.

MFA WebAuthn

mfa_webauthn — admin & role pusat sensitif.

Biometrik

biometric — unlock perangkat mobile.

Service

service — token service-to-service antar microservice.

Tipe Device & Channel

Tipe Device

pos_tablet · petugas_phone · web_browser

Channel

pos · app · web · api · service

Status User

active · suspended · locked · deleted