Role & Sistem Permission

Gambaran Umum

Ketika sebuah bisnis berkembang, pemilik usaha tentu tidak lagi bekerja sendirian. Mereka mulai merekrut staf operasional, manajer gerai, hingga tenaga kasir lapangan. Pada titik ini, memberikan akses terbuka ke seluruh sistem kepada semua orang adalah mimpi buruk dari segi keamanan dan privasi data. Modul Role & Sistem Permission di Temuya hadir sebagai fondasi krusial untuk mengatur lalu lintas hak akses pengguna.

Dengan mengadopsi konsep Role-Based Access Control (RBAC), sistem mendelegasikan wewenang berdasarkan peran yang diemban seseorang di dalam bisnis. Pendekatan ini memastikan bahwa kasir tidak bisa mengintip laba bersih bulan ini, sementara manajer bisa menyetujui pembatalan transaksi, namun tidak dapat menghapus akun toko secara keseluruhan. Pengelolaan akses ini diterapkan secara disiplin baik pada lapisan visual (apa yang dilihat pengguna) maupun pada lapisan keamanan data (apa yang diizinkan server).

Skenario Bisnis: Manajemen Tim Gerai

Mari kembali membayangkan perjalanan Budi, sang pemilik Kopi Senja. Setelah usahanya sukses, Budi merekrut Rina sebagai manajer toko dan Andi sebagai kasir harian. Budi ingin agar Andi hanya bisa mengakses layar POS dan melakukan transaksi sehari-hari. Jika ada pelanggan yang mengembalikan barang dan meminta uang kembali, Andi tidak boleh langsung memprosesnya, melainkan harus meminta persetujuan (PIN) dari Rina sang manajer.

Sementara itu, Budi sebagai pemilik mutlak ingin bisa memantau semua laporan dari rumah, mengatur harga, dan jika perlu, memutasi Rina atau Andi. Sistem hierarki peran di Temuya mewujudkan kebutuhan Budi ini dengan sempurna. Andi masuk dengan akun kasir yang menu laporannya menghilang secara ajaib. Rina bisa mengelola shift namun tidak bisa melihat data langganan sistem. Budi, sebagai panglima tertinggi, menguasai segala kendali.

Alur Kerja

Struktur kekuasaan di Temuya dibagi menjadi empat tingkatan peran yang saling mengunci dalam sebuah hierarki ketat:

Owner (Pemilik)
Peran tertinggi dalam sebuah tenant (toko). Owner memiliki akses mutlak ke seluruh fitur sistem, termasuk menghapus toko, mengatur penagihan (billing plan), dan mengangkat Admin. Hanya Owner yang bisa mengakses data krusial terkait kepemilikan bisnis.
Admin (Administrator)
Tangan kanan sang Owner. Admin bisa mengelola hampir seluruh aspek operasional toko—katalog produk, pengaturan inventori, laporan lengkap—namun mereka dikunci dari area penagihan dan tidak bisa menghapus toko maupun mengelola akun Owner.
Manager (Manajer Gerai)
Pengawas keseharian toko. Manager bertugas menyetujui tindakan-tindakan khusus seperti pembatalan pesanan (void) atau pengembalian (retur). Mereka dapat mengelola shift, melihat laporan harian, namun tidak memiliki wewenang mengubah struktur besar toko.
Kasir (Cashier)
Garda terdepan operasional. Akses Kasir sangat dibatasi. Dunia mereka hanya berkisar pada halaman Point of Sale (POS), mencetak struk, dan mengelola laci kas. Laporan keuangan, pengaturan toko, dan manajemen karyawan adalah menu yang sama sekali tidak akan mereka lihat.

classDiagram
    Owner <|-- Admin : Mewariskan Hak
    Admin <|-- Manager : Mewariskan Hak
    Manager <|-- Kasir : Mewariskan Hak
    
    class Owner{
        +Hapus Toko()
        +Kelola Billing()
        +Akses Penuh()
    }
    class Admin{
        +Kelola Produk()
        +Laporan Menyeluruh()
        +Kelola Staf()
    }
    class Manager{
        +Approval Void/Retur()
        +Kelola Shift()
        +Laporan Harian()
    }
    class Kasir{
        +Proses POS()
        +Kelola Laci Kas()
        -Akses Laporan()
    }

Teknologi & Infrastruktur

Pertahanan sistem dibangun melalui dua tembok kokoh: antar muka pengguna (frontend) dan keamanan server (backend).

Di sisi peramban, sebuah komponen bernama pelindung rute peran memastikan bahwa pengguna yang nyasar ke alamat web yang salah akan segera diarahkan kembali. Fungsi-fungsi utilitas cerdas—seperti pemeriksa apakah pengguna dapat mengakses rute tertentu, dan apakah pengguna dapat mengubah data peran pengguna lain—berjalan di balik layar untuk menyembunyikan tombol-tombol yang tidak relevan dengan tingkat hak akses pengguna saat itu.

Sementara itu di sisi server, setiap titik akhir (endpoint) sensitif dijaga ketat oleh sebuah gerbang validasi (middleware). Walaupun ada pengguna pintar yang berhasil menembus tembok antar muka, gerbang server akan selalu mengecek label peran pengguna pada setiap detik pengiriman data.

flowchart TD
    A[Pengguna Navigasi ke Halaman Laporan] --> B{Pelindung Rute Frontend}
    B -->|Bukan Role Valid| C[Redirect ke Halaman Beranda]
    B -->|Role Valid| D[Tampilkan UI Laporan]
    D --> E[Klik 'Unduh Excel']
    E --> F{Middleware Backend}
    F -->|Tidak Punya Wewenang| G[Tolak: 403 Forbidden]
    F -->|Wewenang Cukup| H[Kirim File Laporan]

Tabel Wewenang Hak Akses

Berikut adalah penjabaran terstruktur mengenai apa yang boleh dan tidak boleh dilakukan oleh masing-masing tingkat peran:

Modul/Fitur	Owner	Admin	Manager	Kasir
Akses Transaksi POS	Ya	Ya	Ya	Ya
Buka/Tutup Shift	Ya	Ya	Ya	Ya
Kelola Laci Kas	Ya	Ya	Ya	Ya
Approval Void & Retur	Ya	Ya	Ya	Tidak
Lihat Laporan Penjualan	Ya	Ya	Terbatas	Tidak
Tambah/Ubah Produk	Ya	Ya	Tidak	Tidak
Atur Diskon & Promo	Ya	Ya	Tidak	Tidak
Tambah Staf Baru	Ya	Ya	Tidak	Tidak
Beli Token Billing	Ya	Tidak	Tidak	Tidak

Keterkaitan dengan Fitur Lain

Sistem hak akses ini menempel erat pada banyak sekali fitur lain:

Transaksi Void & Retur: Sistem akan memeriksa siapa yang menyetujui transaksi pembatalan, memunculkan jendela verifikasi identitas (PIN) jika yang berbuat adalah kasir biasa.
Navigasi Utama: Menu navigasi samping di aplikasi berubah bentuk dan isi secara dinamis menyesuaikan peran yang sedang masuk.

Hal Penting yang Perlu Diketahui

Hak akses dikelola dalam hierarki tegak lurus, yang berarti seseorang dengan peran tinggi bisa mengelola staf dengan peran yang lebih rendah, namun tidak pernah sebaliknya. Fungsi canManageRole() di dalam sistem memastikan bahwa seorang Admin bisa mengangkat Manager dan Kasir, tetapi ia tidak akan pernah bisa mengubah status akun sesama Admin atau menjatuhkan Owner. Selalu waspada saat merancang antarmuka persetujuan (approval) karena di sanalah sistem perlindungan ini paling krusial untuk diuji ketahanannya.