Users (Pengguna)

1. Overview

Pengguna adalah akun yang bisa login ke tenant-dashboard. Setiap pengguna punya nama, email login, status aktif, dan satu atau lebih peran. Peran menentukan hak akses pengguna di seluruh aplikasi. Pengguna terhubung ke sebuah entitas, sehingga bila entitas yang sama juga seorang karyawan, pengguna itu bertindak sebagai karyawan tersebut, misalnya sebagai PIC Pesanan Pembelian.

Saat pengguna dibuat atau emailnya diubah, sistem mengirim email verifikasi. Pengguna harus memverifikasi email untuk mengaktifkan akun dan mendapatkan akses.

Hasil yang diharapkan: hanya orang yang berhak yang bisa masuk, dan setiap pengguna hanya bisa melakukan apa yang diizinkan perannya.

2. Problem

• Satu akun bersama untuk banyak orang membuat aktivitas tidak bisa ditelusuri.
• Tidak semua staf boleh mengakses semua modul, misalnya kasir tidak boleh mengubah pengaturan.
• Email yang salah ketik membuat pengguna tidak bisa masuk; email harus diverifikasi.

3. Goals & Non-goals

Goals

• Admin bisa membuat akun per orang dengan peran yang tepat. Indikator: setiap pengguna punya minimal satu peran.
• Email login terverifikasi. Indikator: pengguna baru dan perubahan email melalui verifikasi email.
• Akses bisa dicabut cepat. Indikator: pengguna bisa dinonaktifkan tanpa dihapus.

Non-goals

• Admin mengatur password pengguna
• SSO / login pihak ketiga, 2FA
• Hak akses per pengguna di luar peran

4. User Scenarios

5. User Flow

0. Pilih sumber — Dialog muncul saat membuka Tambah Pengguna:
   • Buat dari Awal: formulir kosong.
   • Buat dari Entitas: tabel entitas yang belum punya akun pengguna. Nama pengguna dan email diisi otomatis dari entitas terpilih.
1. Profil — Nama pengguna, email, dan status (Aktif / Tidak Aktif); semuanya wajib.
2. Peran — Kartu peran dengan checkbox; setiap kartu menampilkan jumlah hak akses dan bisa diperluas untuk melihat serta mencari daftar hak aksesnya.
3. Tinjauan — Ringkasan beserta error BE bila ada.
4. Simpan — Dikirim bersama verify_url (<origin>/auth/verify-email?token=). Bila sumbernya entitas, dikirim ke endpoint by-party dengan party_id.
5. Tersimpan — Toast sukses, kembali ke daftar pengguna. BE mengirim email verifikasi.
6. Verifikasi — Pengguna membuka tautan di email; halaman /auth/verify-email memverifikasi token lalu mengarahkan ke login.
7. Login — Email tampil dengan ikon terverifikasi di daftar pengguna.

Alternative paths

• Ubah email — Di mode ubah, tab Email menerima email baru. Setelah disimpan, sistem mengirim email verifikasi ke alamat baru.
• Tinggalkan wizard tanpa simpan — muncul konfirmasi perubahan belum disimpan.
• Hapus pengguna — hanya dari daftar (satuan atau massal), setelah konfirmasi.

6. User Stories

Prioritas: P0 wajib untuk rilis, P1 penting, P2 kalau sempat.

US-01 — Membuat pengguna dari awal (P0)

Sebagai owner, saya ingin membuat akun untuk staf, agar mereka bisa login dengan hak akses yang sesuai.

US-02 — Membuat pengguna dari entitas (P1)

Sebagai admin, saya ingin membuat akun dari entitas yang sudah ada (misalnya karyawan), agar tidak terjadi duplikasi identitas.

US-03 — Mengubah profil pengguna (P0)

Sebagai admin, saya ingin mengubah nama dan status pengguna, agar akses bisa diaktifkan atau dicabut.

US-04 — Mengubah email pengguna (P0)

Sebagai admin, saya ingin mengganti email login pengguna, agar pengguna yang salah email tetap bisa masuk.

US-05 — Mengubah peran pengguna (P0)

Sebagai owner, saya ingin menambah atau mencabut peran pengguna, agar hak aksesnya sesuai tugas.

US-06 — Daftar dan filter pengguna (P0)

Sebagai owner, saya ingin melihat dan menyaring pengguna, agar mudah memeriksa siapa punya akses apa.

US-07 — Menghapus pengguna (P1)

Sebagai owner, saya ingin menghapus akun yang tidak diperlukan.

US-08 — Riwayat aktivitas (P2)

Sebagai auditor, saya ingin melihat log aktivitas pengguna.

7. Document Structure

Header (Profil)

Lines (Peran)

8. Status Lifecycle

Pengguna punya dua status yang berdiri sendiri:

9. Permissions & Actions

Permissions

FE menyembunyikan aksi yang tidak diizinkan; BE tetap menolaknya.

10. Business Rules

Aturan bisnis adalah ketentuan yang berlaku di semua layar dan semua aksi, siapa pun yang melakukannya. FE memakainya sebagai validasi di form, BE memakainya sebagai sumber kebenaran; jika keduanya berbeda, perilaku BE yang dianggap benar dan FE menyesuaikan.

• BR-01 Email pengguna adalah identitas login dan harus unik (validasi BE).
• BR-02 Pengguna wajib memiliki minimal satu peran; hak akses efektif adalah gabungan hak akses semua perannya.
• BR-03 Pengguna baru dan perubahan email wajib melalui verifikasi email; tautan verifikasi dibentuk dari url / verify_url yang dikirim FE ditambah token dari BE.
• BR-04 Satu entitas maksimal punya satu akun pengguna; membuat dari entitas hanya bisa memakai entitas yang belum punya akun.
• BR-05 Pengguna tidak aktif tidak boleh mengakses sistem (ditegakkan BE saat login/refresh).
• BR-06 Admin tidak mengatur password pengguna di halaman ini; cara pengguna baru mendapatkan password pertama ditentukan alur auth/BE.
• BR-07 Setiap perubahan dicatat di log aktivitas.

11. Edge Cases

Edge case adalah kondisi yang jarang terjadi tetapi pasti muncul di operasional nyata. Perilaku yang diharapkan ditetapkan di sini agar tidak diputuskan sendiri-sendiri saat implementasi.

12. API Contract

13. Dependencies

PRD terkait

• Roles & Permissions — peran dan hak akses pengguna.
• Entities — identitas pengguna dan sinkronisasi dengan karyawan/pemasok.
• Employees — pengguna yang terhubung ke karyawan bertindak sebagai karyawan di transaksi.
• Auth (login, verifikasi email, lupa/reset password) — di luar Settings.
• Activity Logs — sumber log aktivitas.

Efek ke modul lain

• Hak akses pengguna menentukan menu sidebar yang tampil dan aksi yang tersedia di semua modul.
• Pengguna adalah pelaku (actor) yang tercatat di semua log aktivitas.