# Perbedaan Metode Hak Akses Saat Ini vs SAP-Style

Dokumen ini menjelaskan:
- metode hak akses aplikasi saat ini,
- perbedaannya dengan model SAP-style,
- rencana transisi bertahap yang aman untuk sistem ERP legacy (PHP 5.6, CI3, MariaDB 10),
- kontrol risiko agar tidak merusak stok, accounting, approval, laporan, dan audit.

## 1. Ringkasan Eksekutif

Metode saat ini adalah **hybrid**:
- `RBAC` berbasis `membership` user pada session,
- ditambah `ACL` custom per-user (`set_menu`),
- ditambah filter konteks organisasi (`cabang_id`, `gudang_id`),
- ditambah akses level kolom (`set_access_kolom`).

Metode ini sudah berjalan operasional, tetapi **belum terpusat** dan **belum seragam lintas modul**.

Target SAP-style adalah:
- akses berbasis **Authorization Object + Action + Context**,
- role sebagai bundel lintas modul,
- enforcement terpusat dan konsisten di backend,
- audit trail otorisasi yang lengkap.

## 2. Metode Hak Akses Aplikasi Saat Ini

## 2.1 Komponen Inti

- `Role/Membership` pada session login.
  - User membawa array `membership` di `$_SESSION['login']`.
- `Custom Access per User` di tabel `set_menu`.
  - Override hak akses transaksi per `menu_category + step`.
- `Rule transaksi-step` dari config `heTransaksi_ui`.
  - Fungsi utama:
    - `placeCanMakeTrans(...)`
    - `placeCanFollowupTrans(...)`
- `Data scope` berbasis `cabang_id/gudang_id`.
  - Banyak diterapkan via filter model/controller.
- `Column-level access` via `set_access_kolom`.
  - Fungsi `has_access_kolom(...)`.

## 2.2 Kelebihan Metode Saat Ini

- Cocok untuk codebase legacy dan operasional harian.
- Sudah mendukung kombinasi role + pengecualian per user.
- Sudah mempertimbangkan context cabang/gudang.
- Sudah ada jejak historis perubahan akses di tabel history akses.

## 2.3 Keterbatasan Metode Saat Ini

- Enforcement akses tersebar di banyak helper/controller (tidak satu policy engine).
- Definisi permission masih dekat ke menu/step, belum object bisnis generik lintas modul.
- Konsistensi antar modul bergantung disiplin implementasi tiap endpoint.
- Sulit audit lintas modul karena sumber keputusan akses tidak tunggal.

## 3. Metode SAP-Style (Target)

## 3.1 Prinsip

User tidak di-assign permission satu-satu.
User di-assign **Role**, dan role berisi:
- `Authorization Object` (fungsi bisnis),
- `Action` (READ, CREATE, POST, APPROVE, REVERSE, dll),
- `Context` (company/cabang/gudang/divisi/periode/dokumen).

## 3.2 Bentuk Keputusan Otorisasi

Keputusan akses dibuat dari kombinasi:
- siapa usernya,
- role apa yang aktif,
- object apa yang diakses,
- action apa yang diminta,
- context data apa yang sedang diproses.

## 3.3 Karakteristik Penting

- Lintas modul: object sama bisa dipakai di modul berbeda.
- Row-level authorization: bukan hanya boleh fitur, tapi boleh data yang mana.
- Centralized enforcement: keputusan akses di backend policy service, bukan UI.
- Audit-ready: keputusan allow/deny bisa direkam dengan alasan dan context.

## 4. Perbedaan Utama (Current vs SAP-Style)

| Aspek | Metode Saat Ini | SAP-Style Target | Gap |
|---|---|---|---|
| Unit kontrol | Membership + menu/step | Authorization Object + Action + Context | Besar |
| Sumber keputusan | Tersebar di helper/controller | Terpusat (policy engine/service) | Besar |
| Scope data | Cabang/gudang (manual per query) | Context-aware formal (org field) | Sedang-Besar |
| Lintas modul | Ada, tapi tidak uniform | Native lintas modul | Besar |
| Audit otorisasi | Ada history perubahan akses | Ada history + trace keputusan runtime | Sedang-Besar |
| Kemudahan review compliance | Sulit (banyak titik check) | Lebih mudah (single source of truth) | Besar |
| Backward compatibility | Tinggi untuk kondisi sekarang | Perlu adapter transisi | Terkelola |

## 5. Dampak Bisnis Jika Berubah ke SAP-Style

Perubahan model otorisasi mempengaruhi area kritikal:

- **Stok**
  - Risiko: user salah otorisasi bisa posting movement yang tidak seharusnya.
  - Kontrol: enforce object/action/context untuk proses stok (create/followup/reverse).

- **Accounting/Jurnal**
  - Risiko: approval/posting jurnal oleh role yang tidak valid.
  - Kontrol: object khusus posting/approval/reversal dengan context unit/periode.

- **Approval Workflow**
  - Risiko: lompatan step approval.
  - Kontrol: action per step (APPROVE/REJECT/UNDO) di object workflow.

- **Laporan**
  - Risiko: data leakage lintas cabang/divisi.
  - Kontrol: context filter wajib di layer backend, bukan hanya menu.

- **Audit**
  - Risiko: sulit menjawab "siapa boleh apa pada data mana dan kenapa".
  - Kontrol: central policy trace dan log deny/allow.

## 6. Rekomendasi Arsitektur Target (Tanpa Big-Bang)

## 6.1 Komponen Baru yang Disarankan

- `auth_roles`
- `auth_user_roles`
- `auth_objects`
- `auth_actions`
- `auth_role_permissions` (role + object + action)
- `auth_role_contexts` (role + field context + value)
- `auth_policy_trace` (opsional, untuk audit runtime)

Catatan:
- Tabel existing `set_menu`, `set_menu_manufactur`, `set_access_kolom` **tetap dipertahankan** selama masa transisi.
- Jangan hapus mekanisme lama sebelum coverage policy baru tervalidasi.

## 6.2 Adapter Layer (Kunci Migrasi Aman)

Buat adapter agar kode lama tetap jalan:
- fungsi lama (`placeCanMakeTrans`, `placeCanFollowupTrans`, `has_access_kolom`) memanggil policy service baru secara bertahap,
- fallback ke mekanisme lama jika policy baru belum tersedia untuk object tertentu.

Dengan adapter:
- kompatibilitas legacy terjaga,
- rollout bisa bertahap per modul,
- rollback lebih aman.

## 7. Strategi Transisi Bertahap

## Fase 0 - Baseline dan Mapping

- Inventaris semua check akses di endpoint kritikal.
- Mapping `jenisTr + step` ke `authorization object + action`.
- Definisikan field context minimum:
  - `cabang_id`
  - `gudang_id`
  - `div_id`
  - `jenis_tr`
  - `step`

Output:
- matrix permission lintas modul,
- daftar gap per modul.

## Fase 1 - Build Fondasi (Non-Blocking)

- Buat tabel auth baru.
- Isi role/object/action/context dari konfigurasi existing.
- Tambahkan policy service read-only (belum jadi gate utama).

Output:
- policy baru bisa dievaluasi paralel tanpa mengubah perilaku produksi.

## Fase 2 - Dual Check (Monitor Mode)

- Endpoint kritikal menjalankan:
  - keputusan lama (tetap dipakai),
  - keputusan baru (hanya dicatat/log).
- Bandingkan mismatch decision.

Output:
- daftar mismatch nyata di lapangan.

## Fase 3 - Enforce Bertahap per Domain

Prioritas domain:
1. master data non-transaksional,
2. transaksi low-risk,
3. transaksi stok/accounting/approval.

Setiap domain:
- UAT role matrix,
- validasi data scope,
- sign-off bisnis + audit internal.

## Fase 4 - Cutover dan Hardening

- Policy baru jadi sumber utama.
- Mekanisme lama tetap tersedia sebagai fallback terbatas.
- Setelah stabil dan audit lolos, baru deprecate bertahap.

## 8. Contoh Mapping Awal (Praktis)

Contoh dari pola existing `jenisTr + step`:

- `Object`: `TRX_PURCHASE_ORDER`
  - `Action`: `CREATE`, `READ`, `APPROVE_STEP_2`, `REJECT_STEP_2`, `UNDO_STEP_2`
  - `Context`: `cabang_id`, `gudang_id`

- `Object`: `TRX_GRN`
  - `Action`: `CREATE`, `APPROVE`, `REVERSE`
  - `Context`: `cabang_id`, `gudang_id`, `periode`

- `Object`: `PRICE_COLUMN`
  - `Action`: `READ`
  - `Context`: `kolom_key=jual/beli`, `cabang_id`

## 9. Risiko Implementasi dan Mitigasi

| Risiko | Dampak | Mitigasi |
|---|---|---|
| Mismatch rule lama vs baru | user terkunci / user kebablasan | dual-check monitor mode + log mismatch |
| Cutover terlalu cepat | gangguan transaksi operasional | phased rollout per modul/domain |
| Context tidak lengkap | kebocoran data lintas unit | wajib definisi context minimum per object |
| Endpoint lama terlewat | bypass policy baru | endpoint inventory + regression test checklist |
| Audit trail terputus | sulit investigasi | simpan trace keputusan allow/deny di runtime |

## 10. Kriteria Sukses Migrasi

- Tidak ada regresi akses pada proses transaksi kritikal.
- Tidak ada data leakage lintas cabang/gudang/divisi.
- Keputusan otorisasi dapat dijelaskan dan diaudit.
- Role onboarding/offboarding lebih cepat dan konsisten.
- Endpoint tidak bisa bypass lewat direct URL/API.

## 11. Keputusan yang Disarankan Saat Ini

1. Setujui model target: `Authorization Object + Action + Context`.
2. Setujui transisi bertahap (bukan big-bang).
3. Mulai Fase 0 dengan modul prioritas:
   - pembelian
   - penjualan
   - followup/approval
   - laporan sensitif
4. Tetapkan owner lintas fungsi:
   - IT aplikasi
   - user bisnis proses
   - internal audit

---

Dokumen ini adalah baseline perubahan metode hak akses menuju SAP-style dengan tetap menjaga stabilitas ERP legacy dan kompatibilitas operasional.