Manajemen Pengguna & Otorisasi Menu

Sistem FSCM menggunakan JWT (JSON Web Token) untuk autentikasi dan Role-Based Access Control (RBAC) untuk otorisasi menu secara dinamis melalui database.

1. Analisis Database (Tabel SSO)

Aplikasi ini mengadopsi model Single Sign-On (SSO) sederhana menggunakan beberapa tabel utama:

  • sso_msuser: Menyimpan data pengguna (kredensial sandi). Tabel ini menggunakan Composite Primary Key yaitu (usr_id, rol_id, app_id). Artinya, satu entitas fisik (Karyawan/Supplier) bisa memiliki beberapa peran (Role) yang berbeda di dalam beberapa aplikasi.
  • sso_msrole: Menyimpan referensi Role (seperti Admin, Approver, Supplier, dsb) melalui rol_id. Beberapa contoh role krusial:
    • ROL02 (SUPPLIER): Role untuk pihak eksternal/Vendor.
    • ROL01 (Admin): Pengelola sistem keseluruhan.
    • ROL03 (MEMBER PPIC FILTER): Pengelola inventaris dan jadwal produksi.
    • ROL27 (SECURITY): Satpam/Keamanan yang mengurus Check-in/Check-out truk vendor di gerbang.
    • QA / QC / PROCUREMENT: Divisi terkait yang mengontrol kualitas barang dan order pembelian.
  • sso_msmenu: Tabel krusial yang mendefinisikan menu. Menu didefinisikan secara eksplisit untuk setiap peran dan aplikasi (app_id dan rol_id).

2. Asal-Usul Pengguna (Cara Pendaftaran)

Proses pembuatan user (akun login) TIDAK BISA sembarangan. Prosesnya harus diawali dari adanya data master.

  1. Master Data Dulu: Sistem tidak mengizinkan pembuatan akun jika NPK (Nomor Pokok Karyawan) atau Kode Supplier belum terdaftar di tabel ms_karyawan atau ms_supplier. Data karyawan dan supplier ini merupakan data pusat, yang biasanya tersinkronisasi atau ditarik dari Infor/HR (Master Data Pusat).
  2. Self-Registration (Mandiri): Ketika user (baik itu Karyawan atau Vendor) ingin memiliki akses ke dashboard aplikasi, mereka melakukan pendaftaran mandiri (Registrasi) melalui halaman Login.
  3. Validasi (sp_RegisterUserRequest): Backend akan mengecek apakah ID yang dimasukkan (misalnya usr_id = NPK12345) terdaftar di tabel Karyawan/Supplier. Jika tidak ada, pendaftaran ditolak seketika.
  4. Masuk Antrean (Pending): Jika ID valid, akun akan dibuat namun statusnya NONAKTIF dengan Role awal berstatus PEND (Pending).
  5. Approval Admin: Akun yang baru daftar tidak bisa langsung digunakan. Seorang Admin harus login, masuk ke menu “Persetujuan User” (memanggil /api/Auth/GetPendingUsers), lalu menentukan bahwa karyawan A ini mendapatkan peran/role apa (Misalnya: Admin mengubah role “PEND” menjadi “ROL03” / PPIC). Hal ini dieksekusi di Stored Procedure sp_ApproveUser. Setelah disetujui, barulah pengguna bisa login.

3. Alur Autentikasi (Login)

  1. Frontend: Pengguna (Karyawan/Vendor) melakukan login.
  2. Backend: Memanggil Stored Procedure sp_loginUser. Prosedur ini memvalidasi password dan mengambil identitas asli pengguna dari sso_msuser.
  3. Backend JWT: Backend membuat Token JWT yang menyematkan Claims berupa app_id, role_id, dan user_type.
  4. Frontend: Menyimpan JWT ini ke dalam Cookies.

4. Alur Otorisasi (Render Menu Dinamis)

  1. Setelah login berhasil, App.jsx (Frontend) memicu fungsi CreateMenu().
  2. CreateMenu() akan melempar HTTP GET ke btb_backend pada rute /api/Menu sembari membawa token JWT.
  3. Di Backend (MenuController.cs), sistem akan membongkar JWT, mengambil role_id dan app_id, lalu meneruskannya ke MenuRepository.
  4. MenuRepository memanggil Stored Procedure sp_getMenuByRole. SP ini melakukan query langsung ke tabel sso_msmenu (dengan filter men_status = 'AKTIF' dan cocok dengan app_id + rol_id dari JWT).
  5. Kumpulan data dikembalikan ke Frontend untuk dirender menjadi visual Sidebar secara presisi (sehingga Satpam tidak akan melihat menu PPIC, dsb).