Radit_Arahman_Putra23/ProjectKP
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Menghapus folder docs dan laporankerjapraktek dari repository

Browse Source
This commit is contained in:
raditarahman5-cloud
2026-06-28 15:21:45 +07:00
parent ac6c3473d4
commit 21d260e47f
3 changed files with 0 additions and 1641 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/codebase_analysis.md
-491
View File
@@ -1,491 +0,0 @@
# Analisis Mendalam Codebase: KP-ASOY + Laravel_KP
> Dibuat: 2026-05-19 | Tujuan: Mempersiapkan integrasi penuh Frontend (KP-ASOY) ↔ Backend (Laravel_KP)
---
## 1. Gambaran Umum Arsitektur
Sistem ini terdiri dari **dua proyek Laravel terpisah** yang dirancang untuk berkomunikasi via HTTP API:
| Aspek | KP-ASOY (Frontend) | Laravel_KP (Backend) |
|---|---|---|
| **Peran** | UI / Presentasi Layer | API / Business Logic / Database |
| **Port** | `8001` | `8000` |
| **Laravel** | ^13.0 (PHP ^8.3) | ^12.0 (PHP ^8.2) |
| **Auth** | Session-based (dari API token) | Laravel Sanctum Token |
| **Database** | `database_monitoring` (sama) | `database_monitoring` |
| **Env: Backend URL** | `BACKEND_API_URL=http://127.0.0.1:8000/api` | — |
> **Catatan Kritis**: Kedua proyek masih mengarah ke **database yang sama**. Ini membuat banyak controller di KP-ASOY masih query langsung ke DB, padahal seharusnya semua data diambil via API dari Laravel_KP.
---
## 2. Struktur Direktori Lengkap
### 2.1 Laravel_KP (Backend API)
```
Laravel_KP/
├── app/
│ ├── Exports/
│ │ └── PenugasanExport.php # Export Excel (Maatwebsite)
│ ├── Http/
│ │ ├── Controllers/
│ │ │ ├── AuthController.php # Login, Logout, Register, Me, UpdateProfile
│ │ │ ├── PegawaiController.php # CRUD Pegawai (TIDAK ada route-nya di api.php!)
│ │ │ ├── UnitKerjaController.php # Index Unit Kerja
│ │ │ └── Api/
│ │ │ └── PenugasanController.php # Dashboard, CRUD Penugasan, Export
│ │ └── Middleware/
│ │ └── CheckRole.php # Role check via Auth::user() untuk Sanctum
│ └── Models/
│ ├── User.php # HasApiTokens, relasi ke Pegawai & Penugasan
│ ├── Pegawai.php # NIP, Nama, Jabatan, user_id → belonsgToMany Penugasan
│ ├── Penugasan.php # SoftDeletes, pivot ke Pegawai via penugasan_pegawai
│ └── UnitKerja.php
├── database/
│ └── migrations/
│ ├── 000...create_users_table.php # users, password_reset_tokens, sessions
│ ├── 000...create_cache_table.php # cache
│ ├── 000...create_jobs_table.php # jobs queue
│ ├── 2026_04_21_create_pegawai_table.php # pegawai + softDeletes
│ ├── 2026_04_21_create_penugasan_table.php # penugasan + penugasan_pegawai pivot
│ ├── 2026_04_21_create_unit_kerjas_table.php
│ └── 2026_04_28_create_personal_access_tokens_table.php # Sanctum
├── routes/
│ ├── api.php # Semua endpoint REST API
│ └── web.php # Hanya redirect ke login (minimal)
└── .env
# APP_URL=http://127.0.0.1:8000
# DB_DATABASE=database_monitoring
# CORS_ALLOWED_ORIGINS=http://localhost:8001,http://127.0.0.1:8001
```
### 2.2 KP-ASOY (Frontend)
```
KP-ASOY/
├── app/
│ ├── Http/
│ │ ├── Controllers/
│ │ │ ├── UserLoginController.php # Login/Logout/Settings/User CRUD via API
│ │ │ ├── ActivityController.php # CRUD Activity — MASIH query DB lokal!
│ │ │ └── Admin/
│ │ │ ├── ActivityController.php # Monitor kegiatan Admin — MASIH DB lokal!
│ │ │ └── SuperAdminController.php # Dashboard SuperAdmin — MASIH DB lokal!
│ │ └── Middleware/
│ │ └── RoleMiddleware.php # Cek role dari session('user')
│ └── Models/
│ ├── User.php # Tanpa HasApiTokens, relasi hasMany Activity
│ └── Activity.php # SoftDeletes; fillable: nama_kegiatan, keterangan, status, user_id
├── resources/views/
│ ├── login-user.blade.php
│ ├── welcome.blade.php
│ ├── user/
│ │ ├── dashboard.blade.php
│ │ ├── activity-list.blade.php
│ │ ├── activity-detail.blade.php
│ │ ├── activity-edit.blade.php
│ │ ├── input-activity.blade.php
│ │ └── settings.blade.php
│ ├── admin/
│ │ ├── dashboard.blade.php
│ │ ├── users.blade.php
│ │ ├── create-user.blade.php
│ │ └── kegiatan/
│ └── superadmin/
│ ├── dashboard.blade.php
│ └── user/
├── routes/
│ └── web.php # Routing web dengan middleware role
└── .env
# APP_URL=http://127.0.0.1:8001
# DB_DATABASE=database_monitoring
# BACKEND_API_URL=http://127.0.0.1:8000/api
```
---
## 3. Alur Autentikasi (Sudah Terintegrasi)
```
[Browser] → POST /login-user (KP-ASOY:8001)
→ UserLoginController::login()
→ Http::post('http://127.0.0.1:8000/api/login', [username, password])
→ Laravel_KP: AuthController::login()
- Cek username/email di tabel users
- Hash::check password
- Hapus token lama
- createToken('kp-asoy-token') → Sanctum
→ Response JSON: { token, user:{id,name,username,email,role,jabatan} }
→ KP-ASOY: session(['api_token', 'user', 'role', 'user_id', 'user_name', 'username'])
→ Redirect by role:
- 'admin' → /admin/dashboard
- 'superadmin' → /superadmin/dashboard
- 'user' → /user/dashboard
```
---
## 4. Semua Endpoint API Backend (Laravel_KP)
### Public (tanpa token)
| Method | Endpoint | Controller | Fungsi |
|--------|----------|------------|--------|
| POST | `/api/login` | AuthController@login | Login, return Sanctum token |
### Protected — auth:sanctum
| Method | Endpoint | Controller | Fungsi |
|--------|----------|------------|--------|
| POST | `/api/logout` | AuthController@logout | Hapus token aktif |
| GET | `/api/me` | AuthController@me | Data user yang login |
| PUT | `/api/profile/update` | AuthController@updateProfile | Update email/password |
| POST | `/api/register` | AuthController@register | Buat user baru |
| GET | `/api/users` | Closure inline | List semua user (semua role) |
| GET | `/api/pegawai` | Closure inline | List user dengan role='user' |
| GET | `/api/dashboard` | PenugasanController@dashboard | Stats + 5 aktivitas terbaru |
| GET | `/api/penugasan` | PenugasanController@index | List semua penugasan |
| POST | `/api/penugasan` | PenugasanController@store | Buat penugasan baru |
| GET | `/api/penugasan/{id}` | PenugasanController@show | **METHOD TIDAK ADA** |
| PUT | `/api/penugasan/{id}` | PenugasanController@update | **METHOD TIDAK ADA** |
| POST | `/api/penugasan/{id}/update-status` | PenugasanController@updateStatus | Ubah status penugasan |
| POST | `/api/penugasan/{id}/delete` | PenugasanController@destroy | Batalkan penugasan |
| GET | `/api/notifications` | PenugasanController@notifications | **METHOD TIDAK ADA** |
| GET | `/api/unit-kerja` | UnitKerjaController@index | List unit kerja |
| GET | `/api/export-penugasan` | PenugasanController@export | Download Excel |
---
## 5. Skema Database Lengkap
### Tabel `users`
| Kolom | Tipe | Keterangan |
|-------|------|------------|
| id | bigint PK | |
| name | string | Nama lengkap |
| username | string UNIQUE | Login identifier |
| email | string UNIQUE | |
| password | string | bcrypt hashed |
| role | enum | **Migration: `superadmin,admin,pegawai`** tapi kode pakai `user` |
| jabatan | string nullable | |
| created_at / updated_at | timestamp | |
### Tabel `pegawai`
| Kolom | Tipe | Keterangan |
|-------|------|------------|
| id | bigint PK | |
| nip | string UNIQUE | |
| nama | string | |
| jabatan | string | |
| user_id | FK → users | |
| deleted_at | timestamp | SoftDeletes |
### Tabel `penugasan`
| Kolom | Tipe | Keterangan |
|-------|------|------------|
| id | bigint PK | |
| nomor_surat | string nullable UNIQUE | |
| kegiatan | string | Nama kegiatan |
| tanggal_mulai | date | |
| tanggal_selesai | date nullable | |
| status | enum | `proses`, `selesai`, `telah_ditinjau` |
| created_by | FK → users | Admin yang membuat |
| approved_by | FK → users nullable | SuperAdmin penyetuju |
| approved_at | timestamp nullable | |
| alasan_hapus | text nullable | Alasan pembatalan |
| deleted_at | timestamp | SoftDeletes |
### Tabel `penugasan_pegawai` (Pivot)
| Kolom | Tipe | Keterangan |
|-------|------|------------|
| id | bigint PK | |
| penugasan_id | FK → penugasan | |
| pegawai_id | FK → pegawai | |
### Tabel `activities` (KP-ASOY Lokal — TIDAK ADA di Backend)
| Kolom | Tipe | Keterangan |
|-------|------|------------|
| id | bigint PK | |
| user_id | FK → users | |
| nama_kegiatan | string | |
| keterangan | text nullable | |
| status | string | `on_progres`, `selesai` |
| deleted_at | timestamp | SoftDeletes |
---
## 6. Relasi Antar Model
### Laravel_KP (Backend)
```
User ─── hasOne ──────────── Pegawai
User ─── hasMany ─────────── Penugasan (as created_by)
User ─── hasMany ─────────── Penugasan (as approved_by)
Pegawai ─ belongsToMany ──── Penugasan (via penugasan_pegawai)
Penugasan ─ belongsToMany ── Pegawai (via penugasan_pegawai)
Penugasan ─ belongsTo ────── User (pembuat)
Penugasan ─ belongsTo ────── User (penyetuju)
```
### KP-ASOY (Frontend)
```
User ─── hasMany ─────────── Activity
Activity ─ belongsTo ──────── User
```
---
## 7. Analisis Controller per Controller
### 7.1 `UserLoginController` (KP-ASOY) — SUDAH TERINTEGRASI ✅
Semua method sudah menggunakan `Http::withToken(session('api_token'))`:
- `login()` → POST `/api/login`
- `logout()` → POST `/api/logout`
- `updateSettings()` → PUT `/api/profile/update`
- `userList()` → GET `/api/users`
- `storeUser()` → POST `/api/register`
- `destroyUser()` → DELETE `/api/users/{id}` *(endpoint backend belum ada!)*
**Kekurangan**: `editUser()` dan `updateUser()` hanya return view tanpa data dari API.
### 7.2 `ActivityController` (KP-ASOY) — BELUM TERINTEGRASI ❌
Semua method masih pakai `Auth::id()` dan model `Activity::` langsung:
- `index()` → query `Activity::where('user_id', Auth::id())`
- `store()` → `Activity::create([...])`
- `list()`, `show()`, `edit()`, `update()`, `selesai()`
> **Target**: Semua operasi ini harus diganti dengan HTTP call ke backend menggunakan `session('api_token')` dan memetakan `Activity` ke entitas `Penugasan` di backend.
### 7.3 `Admin/ActivityController` (KP-ASOY) — BELUM TERINTEGRASI ❌
- `dashboard()` → query `Activity::`, `User::` langsung ke DB
- `index()` → query dengan filter search/status/bulan langsung ke DB
- `show()`, `edit()`, `update()`, `destroy()` → langsung ke DB
### 7.4 `Admin/SuperAdminController` (KP-ASOY) — BELUM TERINTEGRASI ❌
- `index()` → query `Activity::`, `User::withCount('activities')` langsung ke DB
- `approve()` → `Activity::findOrFail($id)->update(['status' => 'selesai'])` langsung ke DB
- `destroy()` → SoftDelete langsung ke DB
- `userIndex()`, `editUser()`, `updateUser()`, `destroyUser()` → langsung ke DB
### 7.5 `AuthController` (Laravel_KP) — BAIK ✅
Full implementasi login, register, me, logout, updateProfile. Semua return JSON.
### 7.6 `PenugasanController` (Laravel_KP) — PARTIAL ⚠️
- ✅ `dashboard()` → return JSON stats
- ✅ `index()` → return JSON list
- ❌ `store()` → **return redirect(), bukan JSON** (fatal untuk API)
- ❌ `show()` → **method tidak ada**
- ❌ `update()` → **method tidak ada**
- ✅ `updateStatus()` → return JSON
- ✅ `destroy()` → return JSON (tapi method hapus = batalkan, bukan delete)
- ✅ `export()` → return Excel download
- ❌ `notifications()` → **method tidak ada**
### 7.7 `PegawaiController` (Laravel_KP) — TIDAK DI-ROUTE ❌
Full CRUD tersedia (index, store, show, update, destroy, trash, restore) tapi **tidak ada satupun route** di `api.php` yang mengarah ke controller ini.
---
## 8. Middleware & Keamanan
### Backend: `CheckRole` Middleware
```php
// Membaca dari Auth::user() (Sanctum)
if (!$request->user() || !in_array($request->user()->role, $roles)) {
return response()->json(['status' => false, 'message' => 'Akses ditolak'], 403);
}
```
> **Catatan**: Middleware ini terdaftar tapi tidak digunakan di route manapun di `api.php`.
### Frontend: `RoleMiddleware`
```php
// Membaca dari session('user') yang tersimpan saat login
$user = session('user');
if (!in_array($user['role'], $roles)) { abort(403); }
```
> Ini sudah tepat untuk frontend yang menggunakan session.
---
## 9. GAP INTEGRASI — Daftar Lengkap
### GAP-01: Dua Entitas Data Yang Berbeda (KRITIS)
- Backend punya `Penugasan` = penugasan dari admin ke pegawai (top-down)
- Frontend punya `Activity` = kegiatan yang diinput sendiri user (bottom-up)
- **Keputusan diperlukan**: Apakah `Activity` frontend = `Penugasan` backend? Atau keduanya berbeda?
- Jika disamakan: field tidak cocok (Activity: `nama_kegiatan, tanggal, lokasi, deskripsi` vs Penugasan: `nomor_surat, kegiatan, tanggal_mulai, tanggal_selesai`)
### GAP-02: Inkonsistensi Nilai Role (KRITIS)
- Migration users: enum `['superadmin', 'admin', 'pegawai']`
- Kode backend (AuthController, api.php): menggunakan string `'user'`
- Kode frontend (web.php, RoleMiddleware): menggunakan `'user'`, `'admin'`, `'superadmin'`
- **Harus dipilih satu**: gunakan `user` atau `pegawai` secara konsisten
### GAP-03: Method Hilang di PenugasanController
- `show($id)` → terdaftar di route, method tidak ada
- `update(Request, $id)` → terdaftar di route, method tidak ada
- `notifications()` → terdaftar di route, method tidak ada
### GAP-04: `store()` Return Redirect Bukan JSON
```php
// SALAH (ini web controller, bukan API):
return redirect()->back()->with('success', '...');
// BENAR (untuk API):
return response()->json(['success' => true, 'data' => $penugasan], 201);
```
### GAP-05: PegawaiController Tidak Di-Route
- Full CRUD tersedia namun tidak ada satupun endpoint di `api.php`
- Frontend tidak bisa mengakses data pegawai terpisah dari users
### GAP-06: DELETE `/api/users/{id}` Tidak Ada di Backend
- `UserLoginController::destroyUser()` di frontend memanggil `DELETE /api/users/{id}`
- Route ini tidak terdaftar di backend → HTTP 404
### GAP-07: ActivityController Masih Pakai DB Lokal
- Semua CRUD Activity di frontend (user, admin, superadmin) query langsung ke database
- Padahal database = database yang sama dengan backend, yang idealnya hanya diakses backend
### GAP-08: Activity Model Fillable Tidak Lengkap
```php
// Saat ini:
protected $fillable = ['nama_kegiatan', 'keterangan', 'status', 'user_id'];
// Tapi controller menyimpan:
Activity::create([..., 'tanggal' => ..., 'lokasi' => ...]);
// Field 'tanggal' dan 'lokasi' tidak ada di fillable → Mass Assignment Error!
```
### GAP-09: CORS Belum Dipastikan Terkonfigurasi
- Backend `.env` sudah ada `CORS_ALLOWED_ORIGINS=http://localhost:8001,http://127.0.0.1:8001`
- Perlu verifikasi `config/cors.php` membaca env ini dengan benar
### GAP-10: Session vs Token Auth Tidak Sinkron untuk SuperAdmin
- SuperAdmin di KP-ASOY masih menggunakan `Auth::user()` dan Eloquent langsung
- Harus diubah menggunakan `session('api_token')` untuk semua request ke backend
---
## 10. Peta Alur Integrasi Target
```
KP-ASOY (FE :8001) Laravel_KP (BE :8000)
─────────────────────────────────────────────────────────────────────
[LOGIN]
POST /login-user ──────────────────────────► POST /api/login
◄────────────────────────── {token, user}
[USER — Input Kegiatan]
POST /activities/store ────────────────────► POST /api/penugasan
Http::withToken($token)->post(...) PenugasanController@store
◄────────────────────────── {success, data}
[USER — List Kegiatan]
GET /activity-list ────────────────────────► GET /api/penugasan?user_id={id}
◄────────────────────────── {success, data:[...]}
[USER — Update Kegiatan]
POST /activity/{id}/update ────────────────► PUT /api/penugasan/{id}
◄────────────────────────── {success, data}
[ADMIN — Dashboard]
GET /admin/dashboard ──────────────────────► GET /api/dashboard
◄────────────────────────── {stats, recent_activities}
[ADMIN — Tinjau Kegiatan]
POST /admin/kegiatan/{id}/update ──────────► POST /api/penugasan/{id}/update-status
{status: 'telah_ditinjau'} PenugasanController@updateStatus
[SUPERADMIN — Approve]
POST /superadmin/kegiatan/{id}/approve ───► POST /api/penugasan/{id}/update-status
{status: 'selesai'} PenugasanController@updateStatus
[SUPERADMIN — Export]
GET /superadmin/export ────────────────────► GET /api/export-penugasan
◄────────────────────────── file: Laporan_Kegiatan.xlsx
[ADMIN — Tambah User]
POST /admin/users/store ───────────────────► POST /api/register
◄────────────────────────── {message, user}
[ADMIN — Hapus User]
DELETE /admin/users/{id} ──────────────────► DELETE /api/users/{id} [BELUM ADA!]
```
---
## 11. Status Integrasi Per Fitur
| # | Fitur | FE Controller | BE Endpoint | Status |
|---|-------|--------------|-------------|--------|
| 1 | Login | UserLoginController@login | POST /api/login | ✅ Terintegrasi |
| 2 | Logout | UserLoginController@logout | POST /api/logout | ✅ Terintegrasi |
| 3 | Update Profil | UserLoginController@updateSettings | PUT /api/profile/update | ✅ Terintegrasi |
| 4 | Tambah User (Admin) | UserLoginController@storeUser | POST /api/register | ✅ Terintegrasi |
| 5 | List User (Admin) | UserLoginController@userList | GET /api/users | ✅ Terintegrasi |
| 6 | Hapus User (Admin) | UserLoginController@destroyUser | ❌ Route belum ada | ❌ Belum |
| 7 | Input Kegiatan (User) | ActivityController@store | POST /api/penugasan | ❌ FE masih DB lokal |
| 8 | List Kegiatan (User) | ActivityController@list | GET /api/penugasan | ❌ FE masih DB lokal |
| 9 | Detail Kegiatan (User) | ActivityController@show | ❌ Method belum ada | ❌ Belum |
| 10 | Edit Kegiatan (User) | ActivityController@update | ❌ Method belum ada | ❌ Belum |
| 11 | Selesaikan Kegiatan | ActivityController@selesai | POST /api/penugasan/{id}/update-status | ❌ FE masih DB lokal |
| 12 | Dashboard Admin | Admin/ActivityController@dashboard | GET /api/dashboard | ❌ FE masih DB lokal |
| 13 | Monitor Kegiatan (Admin) | Admin/ActivityController@index | GET /api/penugasan | ❌ FE masih DB lokal |
| 14 | Tinjau Kegiatan (Admin) | Admin/ActivityController@update | POST /api/penugasan/{id}/update-status | ❌ FE masih DB lokal |
| 15 | Dashboard SuperAdmin | SuperAdminController@index | GET /api/dashboard | ❌ FE masih DB lokal |
| 16 | Approve Kegiatan (SA) | SuperAdminController@approve | POST /api/penugasan/{id}/update-status | ❌ FE masih DB lokal |
| 17 | Hapus Kegiatan (SA) | SuperAdminController@destroy | POST /api/penugasan/{id}/delete | ❌ FE masih DB lokal |
| 18 | Manajemen User (SA) | SuperAdminController@userIndex | GET /api/users | ❌ FE masih DB lokal |
| 19 | Export Laporan | SuperAdminController@export | GET /api/export-penugasan | ❌ FE hanya redirect error |
| 20 | Notifikasi User | ActivityController (statis) | ❌ Method belum ada | ❌ Belum |
| 21 | CRUD Pegawai | ❌ Tidak ada di FE | ❌ Tidak di-route | ❌ Belum |
**Ringkasan**: 5 dari 21 fitur (24%) sudah terintegrasi. 16 fitur (76%) belum terintegrasi.
---
## 12. Prioritas Perbaikan
### 🔴 Prioritas 1 — Perbaiki Backend (Harus Selesai Dulu)
1. **Seragamkan role value** → ubah migration/kode dari `pegawai` ke `user` secara konsisten
2. **Implementasi method hilang** di `PenugasanController`:
- `show($id)` → return JSON detail penugasan + petugas
- `update(Request, $id)` → update data penugasan, return JSON
- `notifications()` → return list penugasan yang sudah `telah_ditinjau` untuk user tertentu
3. **Perbaiki `store()`** → ganti `redirect()->back()` dengan `response()->json(201)`
4. **Tambah route di api.php**:
- `DELETE /api/users/{id}` → untuk hapus user
- Route lengkap `PegawaiController` (index, store, show, update, destroy, trash, restore)
5. **Tambah filter by user** di `GET /api/penugasan` → user hanya boleh lihat tugasnya sendiri
### 🟡 Prioritas 2 — Refactor Frontend Controllers
6. **Refactor `ActivityController`** → ganti semua `Activity::` dan `Auth::id()` dengan `Http::withToken(session('api_token'))->...`
7. **Refactor `Admin/ActivityController`** → semua operasi via API backend
8. **Refactor `SuperAdminController`** → gunakan endpoint API, bukan query DB langsung
9. **Perbaiki `Activity` model fillable** → tambahkan `tanggal`, `lokasi`, `deskripsi`
### 🟢 Prioritas 3 — Penyempurnaan
10. **Verifikasi konfigurasi CORS** di `config/cors.php` backend
11. **Hapus koneksi DB dari KP-ASOY** (kecuali sessions/cache)
12. **Implementasi notifikasi real** berdasarkan status perubahan penugasan
13. **Tambah endpoint edit/delete user** untuk SuperAdmin di backend
14. **Implementasi `editUser()` dan `updateUser()`** di `UserLoginController` KP-ASOY
---
## 13. Kesimpulan
Secara arsitektur, rancangan pemisahan frontend (KP-ASOY) dan backend (Laravel_KP) **sudah benar dan tepat**. Fondasi integrasi sudah ada: autentikasi via Sanctum sudah berjalan, `BACKEND_API_URL` sudah dikonfigurasi, dan pattern `Http::withToken()` sudah digunakan di `UserLoginController`.
**Masalah utama** adalah sebagian besar fitur di KP-ASOY (terutama semua yang berhubungan dengan Activity/Kegiatan dan Dashboard) masih bypass API dan langsung mengakses database. Ini terjadi kemungkinan karena pengembangan dilakukan secara bertahap: login terintegrasi lebih dulu, sementara fitur-fitur lainnya masih dalam proses refactoring.
**Langkah terpenting** sebelum integrasi penuh:
1. Putuskan apakah `Activity` (KP-ASOY) = `Penugasan` (Laravel_KP) atau dua entitas berbeda
2. Perbaiki method-method yang hilang di backend
3. Seragamkan nilai role di seluruh codebase
4. Refactor semua controller frontend untuk menggunakan API
docs/diagrams_mermaid.md
-274
View File
@@ -1,274 +0,0 @@
# Codingan Diagram (Mermaid) Lengkap - Sistem Monitoring Penugasan
Anda dapat menyalin (copy) kode-kode di bawah ini ke dalam **Mermaid Live Editor** (https://mermaid.live/) atau **Draw.io** (Insert > Advanced > Mermaid) untuk menjadikannya gambar.
---
## 1. Usecase Diagram Lengkap (Termasuk CRUD)
Menggambarkan interaksi menyeluruh dari autentikasi, CRUD data, hingga ekspor.
```mermaid
usecaseDiagram
actor Pegawai
actor Admin
actor "Super Admin" as SA
rectangle "Sistem Monitoring Penugasan" {
%% Autentikasi
usecase "Melakukan Login & Logout" as Auth
usecase "Mengelola Profil Diri" as Profil
%% CRUD Kegiatan
usecase "Melihat Daftar Kegiatan (Read)" as CRUD_R
usecase "Menambah Laporan Baru (Create)" as CRUD_C
usecase "Mengubah Laporan (Update)" as CRUD_U
usecase "Menghapus/Membatalkan Laporan (Delete)" as CRUD_D
%% Tindakan Lanjutan
usecase "Meninjau Kegiatan (Ubah ke Ditinjau)" as Review
usecase "Menyetujui Kegiatan (Ubah ke Selesai)" as Approve
usecase "Melihat Statistik Dashboard" as Dash
%% CRUD Pengguna
usecase "Manajemen Akun User & Pegawai (CRUD)" as KelolaUser
usecase "Mengekspor Laporan Excel" as Export
}
Pegawai --> Auth
Pegawai --> Profil
Pegawai --> CRUD_R
Pegawai --> CRUD_C
Pegawai --> CRUD_U
Admin --> Auth
Admin --> Profil
Admin --> Dash
Admin --> CRUD_R
Admin --> Review
Admin --> KelolaUser
SA --> Auth
SA --> Profil
SA --> Dash
SA --> CRUD_R
SA --> Approve
SA --> CRUD_D
SA --> KelolaUser
SA --> Export
```
---
## 2. Flowchart Sistem (Menyesuaikan dengan Gambar Referensi)
Flowchart ini disusun persis seperti gambar alur sistem yang Anda lampirkan, disesuaikan dengan arsitektur backend Monitoring Penugasan Pegawai di Dinas Tenaga Kerja dan Transmigrasi.
```mermaid
flowchart TD
%% Tampilan (Styling) Node agar rapi
classDef startEnd fill:#fff,stroke:#333,stroke-width:2px;
classDef process fill:#fff,stroke:#333,stroke-width:1px;
classDef decision fill:#fff,stroke:#333,stroke-width:1px;
classDef io fill:#fff,stroke:#333,stroke-width:1px;
Start([Mulai]):::startEnd --> B[Membuka Aplikasi]:::process
B --> C[Login]:::process
C --> D[/Input Username dan Password/]:::io
D --> E{Validasi?}:::decision
E -- Tidak --> D
E -- Ya --> F[Sistem Mengecek Role]:::process
F --> R_USER[Dashboard Pegawai]:::process
F --> R_ADMIN[Dashboard Admin]:::process
F --> R_SA[Dashboard Super Admin]:::process
%% ================= ALUR PEGAWAI =================
R_USER --> U_M{Menu User}:::decision
U_M --> U_M1[Tambah Laporan]:::process
U_M1 --> U_M1A[/Input Data & Upload Berkas/]:::io
U_M1A --> U_M1B[Simpan Data ke Database]:::process
U_M1B --> J1(( ))
U_M --> U_M2[Riwayat Laporan]:::process
U_M2 --> U_M2A[/Lihat Seluruh Laporan/]:::io
U_M2A --> U_M2B{Status Laporan?}:::decision
U_M2B -- Ditolak / Pending --> U_M2B1[/Input Data & Upload Berkas Ulang/]:::io
U_M2B1 --> J1
U_M2B -- Diterima / Selesai --> J1
%% ================= ALUR ADMIN =================
R_ADMIN --> A_M{Menu Admin}:::decision
A_M --> A_M1[Kelola Laporan]:::process
A_M1 --> A_M1A[/Lihat Laporan Masuk/]:::io
A_M1A --> A_M1B{Status Laporan?}:::decision
A_M1B -- Valid --> A_M1B1[Update Status 'Telah Ditinjau']:::process
A_M1B1 --> A_M1B1A[Update Data di DB]:::process
A_M1B1A --> J2(( ))
A_M1B -- Tidak Valid --> A_M1B2[Revisi Laporan / Tolak]:::process
A_M1B2 --> A_M1B2A[Update Data di DB]:::process
A_M1B2A --> J2
A_M1B -- Dipending --> A_M1B3[/Lihat Detail Laporan/]:::io
A_M1B3 --> J2
A_M --> A_M2[Riwayat Laporan]:::process
A_M2 --> A_M2A[/Lihat Seluruh Laporan/]:::io
A_M2A --> A_M2B[/Unduh Laporan/]:::io
A_M2B --> J2
A_M --> A_M3[Kelola Data Akun & Berkas]:::process
A_M3 --> A_M3A[/Input Data Pegawai Baru/]:::io
A_M3A --> A_M3B[Simpan Data di Database]:::process
A_M3B --> J2
%% ================= ALUR SUPER ADMIN =================
R_SA --> SA_M{Menu Super Admin}:::decision
SA_M --> SA_M1[Lihat Laporan]:::process
SA_M1 --> SA_M1B{Status Laporan?}:::decision
SA_M1B -- Diterima (Approve) --> SA_M1B1[/Update Status 'Selesai'/]:::io
SA_M1B -- Ditolak / Dipending --> SA_M1B2[/Lihat Detail Laporan/]:::io
SA_M1B1 --> J3(( ))
SA_M1B2 --> J3
%% ================= PENYELESAIAN =================
J1 --> N[/Notifikasi/]:::io
J2 --> N
J3 --> N
N --> K[Menu Profil]:::process
K --> L[Logout]:::process
L --> End([Selesai]):::startEnd
```
---
## 2.B Flowchart Logika Backend Murni (Alur Proses API & Database)
Flowchart ini adalah flowchart yang **sangat disarankan** untuk digunakan dalam Laporan Anda karena berfokus pada apa yang terjadi di "belakang layar" (Backend), mulai dari penerimaan Request HTTP, middleware, validasi, hingga interaksi dengan Database MySQL.
```mermaid
flowchart TD
classDef startEnd fill:#fff,stroke:#333,stroke-width:2px;
classDef process fill:#fff,stroke:#333,stroke-width:1px;
classDef decision fill:#fff,stroke:#333,stroke-width:1px;
classDef io fill:#fff,stroke:#333,stroke-width:1px;
Start([Mulai (Request dari Frontend)]):::startEnd --> REQ[/Menerima HTTP Request\n(POST/GET/PUT/DELETE)/]:::io
%% Middleware Auth & Role
REQ --> MID_AUTH{Cek Token Sanctum?}:::decision
MID_AUTH -- Tidak Valid / Kosong --> ERR401[/Return JSON: 401 Unauthorized/]:::io
MID_AUTH -- Valid --> MID_ROLE{Cek Role Akses?}:::decision
MID_ROLE -- Ditolak --> ERR403[/Return JSON: 403 Forbidden/]:::io
%% Validasi Controller
MID_ROLE -- Diizinkan --> CTRL[Controller Menerima Request]:::process
CTRL --> VAL{Validasi Payload Data\n(Input Kosong/Salah)?}:::decision
VAL -- Gagal --> ERR422[/Return JSON: 422 Unprocessable Entity/]:::io
%% Proses Database
VAL -- Sukses --> DB_OP[Eksekusi Logika Bisnis & Query Database]:::process
DB_OP --> DB_ACT{Jenis Operasi?}:::decision
DB_ACT -- Create/Insert --> DB1[Simpan Data Baru ke Tabel]:::process
DB_ACT -- Read/Select --> DB2[Ambil Data dari Tabel]:::process
DB_ACT -- Update --> DB3[Perbarui Data di Tabel]:::process
DB_ACT -- Delete --> DB4[Soft Delete Data (Ubah deleted_at)]:::process
DB1 --> RES[/Return JSON: 201 Created/]:::io
DB2 --> RES2[/Return JSON: 200 OK + Data/]:::io
DB3 --> RES2
DB4 --> RES2
%% End
ERR401 --> End([Selesai (Response Terkirim)]):::startEnd
ERR403 --> End
ERR422 --> End
RES --> End
RES2 --> End
```
---
## 3. Data Flow Diagram (DFD) Level 0 (Konteks)
Menggambarkan aliran input/output makro sistem.
```mermaid
flowchart LR
P[Pegawai] -- "Data Kredensial\nData Laporan Kegiatan\nData Edit Kegiatan" --> S((Sistem Monitoring\nPenugasan Pegawai))
S -- "Status Laporan\nDaftar Kegiatanku\nKonfirmasi Login" --> P
A[Admin] -- "Data Manajemen User (CRUD)\nInstruksi Review Laporan\nData Kredensial" --> S
S -- "Rekap Seluruh Laporan (Proses)\nData Tabel Pegawai\nDashboard Stats" --> A
SA[Super Admin] -- "Instruksi Approval (Selesai)\nInstruksi Pembatalan (Delete)\nPerintah Export Excel" --> S
S -- "Rekap Seluruh Laporan (Ditinjau)\nFile Export (XLSX)\nDashboard Stats" --> SA
```
---
## 4. Entity Relationship Diagram (ERD) Komprehensif
Menggambarkan seluruh struktur database berbasis Laravel Backend, termasuk token otentikasi Sanctum dan soft deletes (Fitur Hapus).
```mermaid
erDiagram
USERS ||--o| PEGAWAI : "Satu profil per user"
USERS ||--o{ PENUGASAN : "Dibuat oleh (created_by)"
USERS ||--o{ PENUGASAN : "Disetujui oleh (approved_by)"
PEGAWAI }|--|{ PENUGASAN_PEGAWAI : "Ditugaskan pada"
PENUGASAN }|--|{ PENUGASAN_PEGAWAI : "Melibatkan pegawai"
USERS ||--o{ PERSONAL_ACCESS_TOKENS : "Memiliki token (Login)"
USERS {
bigint id PK
string name
string username "UNIQUE"
string email "UNIQUE"
string password
enum role "superadmin, admin, user"
string jabatan "nullable"
timestamp created_at
timestamp updated_at
}
PEGAWAI {
bigint id PK
string nip "UNIQUE"
string nama
string jabatan
bigint user_id FK
timestamp deleted_at "Soft Deletes"
}
PENUGASAN {
bigint id PK
string nomor_surat "UNIQUE"
string kegiatan
string lokasi
text keterangan
date tanggal_mulai
date tanggal_selesai
enum status "proses, selesai, telah_ditinjau"
bigint created_by FK
bigint approved_by FK
timestamp approved_at
text alasan_hapus
timestamp deleted_at "Soft Deletes"
}
PENUGASAN_PEGAWAI {
bigint id PK
bigint penugasan_id FK
bigint pegawai_id FK
}
PERSONAL_ACCESS_TOKENS {
bigint id PK
string tokenable_type
bigint tokenable_id FK
string name
string token "UNIQUE"
text abilities
timestamp last_used_at
timestamp expires_at
}
```
laporankerjapraktek/draflaporansejauhini.md
-876
View File
@@ -1,876 +0,0 @@
KERJA PRAKTEK
Pengembangan Backend Monitoring Penugasan Pegawai StudiKasus : Dinas Tenaga Kerja dan Transmigrasi
OLEH:
RADIT ARAHMAN PUTRA
D1041231007
Jumlah SKS Tempuh : 106
PROGRAM STUDI INFORMATIKA FAKULTAS TEKNIK UNIVERSITAS TANJUNGPURA
2026
LAPORAN KERJA PRAKTEK
Pengembangan Backend Monitoring Penugasan Pegawai StudiKasus : Dinas Tenaga Kerja dan Transmigrasi
Laporan Kerja Praktek yang berjudul “Pengembangan Backend Monitoring Penugasan Pegawai StudiKasus : Dinas Tenaga Kerja dan Transmigrasi”
ini disesuaikan dengan judul Kerja Praktek yang telah dilakukan. Laporan Kerja Praktek yang ditujukan kepada Jurusan Informatika Fakultas Teknik Universitas Tanjungpura ini disusun oleh:
Nama : Radit Arahman Putra
NIM : D1041231007
Periode Kerja Praktek : 6 Maret – 8 Mei 2026
Pontianak,
SURAT PERNYATAAN BEBAS PLAGIAT
Yang bertanda tangan di bawah ini, saya:
Nama : Radit Arahman Putra
NIM : D1041231007
Jurusan : Informatika Tahun Akademik : 2025/2026
Menyatakan bahwa laporan Kerja Praktek saya yang berjudul:
Pengembangan Backend Monitoring Penugasan Pegawai StudiKasus : Dinas Tenaga Kerja dan Transmigrasi
Merupakan karya sendiri dan bukan merupakan karya orang lain. Apabila suatu saat nanti terbukti saya melakukan plagiat maka saya akan menerima sanksi yang telah ditetapkan.
Demikian surat pernyataan ini saya buat dengan sebenar-benarnya.
Pontianak, 13 Mei 2026
Radit Arahman Putra
KATA PENGANTAR
Puji syukur penulis panjatkan kepada Allah SWT. atas segala rahmat, karunia, dan petunjuk-Nya sehingga penulis dapat menyelesaikan laporan kerja praktek dengan judul " Pengembangan Backend Monitoring Penugasan Pegawai StudiKasus : Dinas Tenaga Kerja dan Transmigrasi ". Laporan ini dibuat untuk memenuhi syarat dalam menyelesaikan kegiatan Kerja Praktek. Penulis menyadari bahwa laporan kerja praktek ini tidak dapat diselesaikan tanpa dukungan dan bimbingan dari berbagai pihak. Oleh karena itu, penulis mengucapkan terima kasih yang sebesar-besarnya kepada:
1. Bapak, Dr. Yus Sholva, S.T.,M.T., selaku Kepala Jurusan Informatika Fakultas Teknik Universitas Tanjungpura Pontianak.
2. Bapak Enda Esyudha Pratama, S.T., M.T.. selaku Dosen Pembimbing Akdemik sekaligus Dosen Pembimbing Kerja Praktek yang telah memberikan arahan dan motivasi kepada saya selama menyelesaikan kegiatan Kerja Praktek.
3. Bapak Arif Ramadhayansyah Yusmita S.Kom. selaku selaku Pembimbing Lapangan Kerja Praktek yang telah memberikan arahan dan bimbingan selama pelaksanaan Kerja Praktek.
4. Teman dan sahabat, yang tidak dapat disebutkan satu persatu. Serta pihak-pihak lain yang secara langsung atau tidak langsung turut membantu dalam Menyusun laporan ini.
Dalam penulisan laporan ini, penulis menyadari masih terdapat kekurangan. Oleh karena itu, dengan rendah hati penulis mengharapkan kritikan, saran, dan masukan dari semua pihak yang membaca laporan ini, demi kesempurnaan penulisan berikutnya. Semoga laporan ini dapat memberikan manfaat dan kontribusi nyata bagi pengembangan ilmu pengetahuan, khususnya dibidang pengembangan aplikasi berbasis website
Pontianak,
DAFTAR ISI
DAFTAR GAMBAR
DAFTAR TABEL
ABSTRAK
Monitoring penugasan pegawai merupakan pilar penting dalam menjaga produktivitas dan transparansi kinerja pada instansi pemerintahan. Dinas Tenaga Kerja dan Transmigrasi Provinsi Kalimantan Barat memerlukan mekanisme pengawasan yang andal untuk melacak setiap penugasan yang diberikan kepada pegawai. Selama ini, proses pencatatan penugasan dan pelaporan capaian kinerja masih berjalan secara konvensional atau menggunakan media komunikasi yang tidak terpusat, sehingga memicu kendala sinkronisasi data dan keterlambatan evaluasi.
Kerja Praktek ini berfokus pada pengembangan sisi backend (sistem latar belakang) untuk Website Sistem Informasi Monitoring Penugasan Pegawai. Pengembangan ini dilakukan menggunakan bahasa pemrograman PHP dengan framework Laravel, arsitektur basis data MySQL, serta Laragon sebagai lingkungan local server. Sistem backend yang dibangun menyediakan fungsionalitas manajemen data yang kokoh, meliputi arsitektur basis data relasional (users, pegawai, penugasan, penugasan_pegawai), RESTful API/routing logika bisnis, sistem autentikasi multi-user (User, Admin, Super Admin), serta manajemen transaksi data penugasan. Hasil pengujian fungsionalitas backend melalui pengujian Black Box menunjukkan bahwa seluruh fungsi manipulasi data (CRUD), pengamanan data, dan relasi logika sistem berjalan dengan baik, stabil, dan siap diintegrasikan.
Kata kunci: Backend, Monitoring Penugasan, Laravel, MySQL, Laragon, Dinas Tenaga Kerja dan Transmigrasi.
BAB I PENDAHULUAN
1.1 Latar Belakang
Perkembangan teknologi informasi pada era digital saat ini telah membawa perubahan yang signifikan dalam berbagai sektor, termasuk dalam sektor pemerintahan. Transformasi digital menjadi salah satu upaya penting dalam meningkatkan efisiensi, transparansi, serta akuntabilitas dalam pengelolaan data dan pelayanan publik. Salah satu aspek penting dalam tata kelola pemerintahan adalah proses monitoring terhadap aktivitas dan kinerja pegawai yang dilakukan secara berkelanjutan. Sistem informasi berbasis website terbukti mampu meningkatkan efisiensi dan transparansi manajemen internal organisasi secara signifikan (Rizki & Chotijah, 2025).
Dinas Tenaga Kerja dan Transmigrasi Provinsi Kalimantan Barat merupakan instansi pemerintah yang memiliki peran strategis dalam pengawasan ketenagakerjaan. Dalam pelaksanaan tugasnya, pegawai memiliki berbagai kegiatan yang harus dicatat dan dilaporkan kepada atasan. Namun, berdasarkan hasil observasi selama pelaksanaan kerja praktik, proses pencatatan dan pelaporan kegiatan pegawai masih dilakukan secara manual, sehingga menimbulkan berbagai permasalahan seperti keterlambatan pelaporan, kesulitan dalam pengolahan data, serta kurangnya transparansi dalam pengawasan. Kendala serupa juga sering ditemukan pada organisasi atau instansi lain yang masih mengandalkan pencatatan konvensional, di mana pelacakan tugas dan progres kerja menjadi kurang terpantau secara optimal (Dyarenggasto & Setiyawati, 2024).
Selain itu, belum adanya sistem yang terintegrasi menyebabkan pimpinan mengalami kesulitan dalam melakukan pemantauan kegiatan pegawai secara real-time. Hal ini berdampak pada kurang optimalnya proses evaluasi kinerja pegawai. Menurut Putra et al. (2025), proses pencatatan aktivitas kerja harian pegawai yang dilakukan secara manual rawan terhadap kesalahan pencatatan (*human error*) dan mempersulit pengambilan keputusan manajerial yang cepat. Oleh karena itu, diperlukan suatu sistem informasi berbasis web yang mampu mengelola data kegiatan pegawai secara terstruktur dan terintegrasi.
Dalam kerja praktik ini, dikembangkan sebuah sistem backend monitoring penugasan pegawai menggunakan framework Laravel dengan basis data MySQL. Penggunaan framework Laravel dinilai efektif dalam pengembangan sistem monitoring karena memiliki fitur keamanan yang kuat, manajemen basis data yang terstruktur melalui Eloquent ORM, dan efisiensi waktu pengerjaan (Rizki & Chotijah, 2025). Sistem ini dirancang dengan pembagian hak akses berbasis role (Role-Based Access Control), yaitu user (pegawai/pengawas), admin (kepala seksi), dan super admin (kepala bidang). Sistem juga dilengkapi dengan fitur pengelolaan kegiatan, perubahan status (On Progress, Selesai, Ditinjau), notifikasi, serta export data ke dalam format Excel.
Dengan adanya sistem ini, diharapkan proses monitoring kegiatan pegawai dapat dilakukan secara lebih efektif, efisien, dan transparan sehingga dapat meningkatkan kinerja instansi secara keseluruhan.
1.2 Rumusan Maslah
a. Bagaimana merancang dan mengembangkan backend sistem monitoring penugasan pegawai berbasis Laravel?
b. Bagaimana mengimplementasikan manajemen hak akses berbasis role (user, admin, dan super admin) sesuai dengan kewenangan masing-masing pengguna?
c. Bagaimana merancang alur status kegiatan (On Progress, Selesai, Ditinjau)
d. Bagaimana mengembangkan fitur seperti notifikasi, penghapusan data dengan keterangan, serta export data ke Excel?
1.3 Batasan Masalah
Agar fokus kerja praktik tetap terarah dan tidak meluas ke luar ruang lingkup yang direncanakan, maka batasan masalah dalam kegiatan ini adalah sebagai berikut:
a. Pengembangan difokuskan penuh pada sisi backend (logika aplikasi, struktur database, routing, logika bisnis internal) menggunakan framework Laravel.
b. Data yang digunakan terbatas pada data pengguna instansi.
c. Sistem digunakan di lingkungan internal instansi.
d. Tidak membahas frontend secara mendalam.
.
1.4 Tujuan dan Manfaat
Tujuan dan manfaat dari kerja praktek ini sekaligus target yang akan dicapai adalah sebagai berikut:
a. Membantu instansi dalam meningkatkan efisiensi pengelolaan data kegiatan pegawai melalui implementasi sistem berbasis backend yang dilengkapi dengan fitur manajemen pengguna (user, admin, dan super admin), pengelolaan status kegiatan (On Progress, Selesai, dan Ditinjau), serta notifikasi hasil peninjauan.
b. Memberikan kontribusi dalam pengembangan sistem yang lebih terstruktur dan mudah dikelola, dengan menyediakan fitur tambahan seperti pengelolaan akun pengguna, perubahan data, penghapusan data dengan keterangan, serta export data ke dalam format Excel guna mendukung kebutuhan administrasi instansi.
c. Memberikan pengalaman langsung kepada mahasiswa dalam mengembangkan aplikasi berbasis web menggunakan teknologi seperti Laravel, PHP, MySQL, dan Laragon, serta meningkatkan kemampuan dalam analisis sistem, perancangan backend, dan implementasi logika bisnis sesuai kebutuhan instansi.
d. Untuk memenuhi kewajiban satuan kredit semester (SKS) yang harus ditempuh sebagai persyaratan akademis di Program Studi Informatika Fakultas Teknik Universitas Tanjungpura.
1.5 Metodologi Penelitian
Metode penelitian yang digunakan dalam pelaksanaan kerja praktik ini bersifat studi implementatif, yaitu dengan melakukan pengembangan secara langsung terhadap sistem backend monitoring penugasan pegawai berbasis web di lingkungan Dinas Tenaga Kerja dan Transmigrasi Provinsi Kalimantan Barat. Proses pengembangan dilakukan melalui tahapan yang sistematis, dimulai dari analisis sistem yang sedang berjalan, perancangan sistem, implementasi menggunakan framework Laravel, hingga tahap pengujian dan evaluasi sistem. Setiap tahapan dilakukan untuk menjawab tujuan dari kerja praktik, yaitu meningkatkan efisiensi dalam pengelolaan data kegiatan pegawai serta mendukung proses monitoring yang lebih terstruktur dan dapat diakses secara real-time.
Berikut merupakan tahapan-tahapan yang dilakukan selama melaksanakan kerja praktik :
1.5.1 Analisis Sistem Eksisting
a. Mengkaji proses monitoring kegiatan pegawai yang masih dilakukan secara manual di lingkungan instansi.
b. Mengidentifikasi kendala yang terjadi, seperti keterlambatan pelaporan, kesulitan pengelolaan data, dan kurangnya transparansi informasi.
c. Mengkaji kebutuhan sistem yang diperlukan untuk mendukung proses monitoring berbasis digital.
1.5.2 Perancangan Sistem Backend
a. Merancang arsitektur sistem berbasis backend menggunakan framework Laravel.
b. Menyusun alur proses kegiatan pegawai mulai dari input kegiatan hingga perubahan status (On Progress, Selesai, dan Ditinjau).
c. Merancang struktur basis data menggunakan MySQL untuk menyimpan data pengguna dan data kegiatan.
d. Menentukan pembagian hak akses pengguna berdasarkan role untuk memastikan keamanan dan keteraturan sistem.
1.5.3 Implementasi Sistem
a. Menginstal dan mengkonfigurasi lingkungan pengembangan menggunakan Laragon sebagai local server.
b. Membangun sistem menggunakan Laravel dan bahasa pemrograman PHP.
c. Mengembangkan fitur utama seperti pengelolaan data kegiatan, manajemen pengguna, serta pengaturan status kegiatan.
d. Mengimplementasikan fitur tambahan seperti notifikasi, penghapusan data dengan keterangan, serta export data ke dalam format Excel.
e. Mengintegrasikan sistem dengan database MySQL untuk pengolahan dan penyimpanan data.
1.5.4 Pengujian dan Evaluasi Sistem
a. Melakukan pengujian terhadap fungsi-fungsi utama sistem seperti login, input data kegiatan, perubahan status, dan pengelolaan pengguna.
b. Menggunakan metode black box testing untuk memastikan setiap fitur berjalan sesuai dengan kebutuhan.
c. Mengidentifikasi kesalahan atau kekurangan sistem yang masih perlu diperbaiki.
d. Melakukan evaluasi terhadap hasil pengujian untuk meningkatkan kualitas sistem.
1.5.5 Penyusunan Laporan
a. Menyusun seluruh temuan, proses implementasi, serta hasil pengujian ke dalam laporan kerja praktik.
b. Melakukan revisi berdasarkan masukan dari pembimbing instansi dan pembimbing akademik.
1.6 Rincian Pelaksanaan
Waktu pelaksanaan : 10 Maret – 09 Mei 2025 Tempat Pelaksanaan
- Nama Intansi : Dinas Tenaga Kerja dan Transmigarasi Provinsi
Kalimantan Barat
- Alamat Instansi : Jalan Ahmad Yani No.6, Bangka Belitung Darat, Kec.
Pontianak Tenggara, Kota Pontianak, Kalimantan Barat.
Kegiatan Februari Maret April Mei Juni
Pengajuan Proposal KP
Evaluasi Proposal
Penerbitan Surat Pengantar
Pelaksanaan KP
Laporan KP
Pengajuan Seminar KP
Pelaksanaan Seminar KP
Revisi Laporan KP
Tabel 1.1 Rincian Kegiatan Kerja Praktek
BAB II KERANGKA TEORITIS
2.1 Studi Pustaka
Penelitian dan pengembangan sistem monitoring pegawai telah banyak dilakukan sebelumnya. Beberapa penelitian yang menjadi acuan dalam penyusunan kerja praktik ini adalah sebagai berikut:
Pertama, penelitian yang dilakukan oleh Friwaldi & Widiono (2024) yang mengoptimalkan pemantauan target kinerja dan penugasan berbasis website menggunakan framework Laravel. Penelitian tersebut berfokus pada digitalisasi proses pemantauan dari metode konvensional ke platform berbasis web yang terintegrasi. Hasil pengujian menunjukkan bahwa penggunaan framework Laravel dan arsitektur RESTful API mampu meningkatkan efisiensi operasional dan pelacakan status secara signifikan dengan tingkat keandalan yang tinggi.
Kedua, penelitian oleh Dyarenggasto & Setiyawati (2024) yang mengembangkan sistem pengarsipan surat dan penugasan pegawai berbasis web menggunakan Laravel. Sistem ini membagi hak akses pengguna (RBAC) dan mengimplementasikan pelacakan status penugasan secara real-time. Kontribusi utama dari penelitian tersebut adalah kemudahan dalam pendistribusian tugas dan transparansi pelaporan status pekerjaan pegawai kepada pimpinan.
Ketiga, penelitian oleh Putra et al. (2025) yang membangun sistem monitoring pencapaian target kinerja pegawai menggunakan metode Waterfall dengan framework Laravel. Penelitian tersebut menunjukkan bahwa digitalisasi laporan aktivitas harian pegawai dapat meminimalisasi kesalahan pencatatan data (*human error*) dan mempercepat proses evaluasi kinerja oleh pihak manajemen.
Berdasarkan penelitian terdahulu tersebut, kerja praktik yang mengangkat judul "Pengembangan Backend Monitoring Penugasan Pegawai StudiKasus : Dinas Tenaga Kerja dan Transmigrasi" ini menerapkan arsitektur modern berupa pemisahan antara antarmuka pengguna (Frontend, atau sistem KP-ASOY) dan logika bisnis serta basis data (Backend, atau sistem Laravel_KP). Pengembangan ini difokuskan pada perancangan Backend API menggunakan framework Laravel yang melayani permintaan (request) data dari sistem Frontend. Implementasi ini merujuk pada praktik terbaik pengembangan perangkat lunak (Software Engineering) terkait RESTful API dan manajemen akses terpusat (Role-Based Access Control).
2.2 Landasan Teori
2.2.1 Website
Website merupakan kumpulan halaman yang saling terhubung dalam suatu domain atau URL yang dapat diakses melalui jaringan internet menggunakan web browser. Seiring perkembangan teknologi, website dinamis berkembang pesat karena mampu menyajikan konten yang dapat berubah sesuai dengan interaksi pengguna dan pengelolaan basis data. Dalam arsitektur pengembangan web modern terpisah (*decoupled architecture*), sistem backend berbasis web berfungsi untuk menangani pemrosesan logika bisnis, manajemen database, dan penyediaan antarmuka data dalam bentuk Web Service tanpa harus menangani struktur presentasi visual secara monolitik. Penggunaan arsitektur berbasis website dinamis ini terbukti meningkatkan fleksibilitas dan kecepatan pertukaran data (Friwaldi & Widiono, 2024 [Unduh PDF](https://www.researchgate.net/publication/386047702_Optimization_of_Direct_Sales_and_Sales_Canvasser_Sales_Target_Monitoring_With_RESTful_API_Implementation_on_Web-Based_Monitoring_System)). Dalam konteks kerja praktik "Pengembangan Backend Monitoring Penugasan Pegawai StudiKasus : Dinas Tenaga Kerja dan Transmigrasi" ini, konsep website dinamis diterapkan sebagai landasan pembangunan server backend Laravel yang melayani pengolahan data pegawai secara dinamis.
2.2.2 MySQL
MySQL merupakan sistem manajemen basis data (DBMS) yang berfungsi sebagai server database, menggunakan bahasa SQL sebagai sarana interaktif untuk pengelolaan data. MySQL mendukung arsitektur multithread dan multi-user, sehingga memungkinkan pengelolaan data secara efisien dalam lingkungan yang kompleks (Sitanggang et al., 2022 [Unduh PDF](https://www.researchgate.net/publication/377755106_Rancang_Bangun_Sistem_Penjualan_Tanaman_Hias_Berbasis_Web_Menggunakan_PHP_dan_MySQL)). MySQL menawarkan berbagai keunggulan yang membuatnya relevan untuk dipilih, antara lain kemampuan integrasi dengan bahasa pemrograman PHP, dukungan multi-user yang andal, kebutuhan sumber daya yang efisien, struktur tabel yang fleksibel, serta sifat open source yang bebas biaya sehingga umum digunakan dalam pengembangan sistem informasi berbasis web (Dyarenggasto & Setiyawati, 2024 [Unduh PDF](https://www.researchgate.net/publication/377287955_Perancangan_Sistem_Pengarsipan_Surat_dan_Penugasan_Berbasis_Web_Menggunakan_Framework_Laravel)).
2.2.3 Framework Laravel
Laravel adalah framework yang dikembangkan dengan menggunakan bahasa pemrograman PHP dan berlandaskan pada pola arsitektur Model-View-Controller (MVC). Konsep MVC ini sangat relevan untuk memisahkan antara antarmuka pengguna (front-end) dan pengelolaan logika aplikasi atau data (back-end). Laravel memiliki berbagai kelebihan seperti fitur routing untuk mengatur endpoint API, kemudahan manipulasi database melalui Eloquent Object Relational Mapping (ORM), dan query builder. Pemanfaatan framework Laravel dinilai mempercepat waktu pengembangan serta memberikan keandalan yang tinggi pada sistem monitoring penugasan pegawai (Friwaldi & Widiono, 2024 [Unduh PDF](https://www.researchgate.net/publication/386047702_Optimization_of_Direct_Sales_and_Sales_Canvasser_Sales_Target_Monitoring_With_RESTful_API_Implementation_on_Web-Based_Monitoring_System)).
2.2.4 Arsitektur RESTful API dan Laravel Sanctum
REST (Representational State Transfer) API adalah gaya arsitektur perangkat lunak yang mendefinisikan aturan untuk membuat layanan web. Dalam sistem monitoring penugasan pegawai di lingkungan Dinas Tenaga Kerja dan Transmigrasi ini, backend berfungsi sebagai penyedia API yang memberikan balasan berformat JSON atas permintaan HTTP (GET, POST, PUT, DELETE) dari aplikasi frontend. Pemisahan arsitektur ini mempermudah integrasi data dan meningkatkan fleksibilitas aplikasi di mana frontend berfokus pada visualisasi sementara backend mengolah data dan logika bisnis (Friwaldi & Widiono, 2024 [Unduh PDF](https://www.researchgate.net/publication/386047702_Optimization_of_Direct_Sales_and_Sales_Canvasser_Sales_Target_Monitoring_With_RESTful_API_Implementation_on_Web-Based_Monitoring_System)).
Untuk menjaga keamanan lalu lintas data API, Laravel menyediakan paket resmi bernama Laravel Sanctum. Sanctum memberikan sistem autentikasi token (token-based authentication) yang ringan untuk Single Page Applications (SPA) atau aplikasi terpisah. Ketika pengguna melakukan login, backend akan mencocokkan kredensial dan menerbitkan API token yang kemudian disimpan di session frontend untuk melakukan aktivitas secara terotorisasi.
2.2.5 Role-Based Access Control (RBAC)
Role-Based Access Control (RBAC) adalah metode pembatasan akses sistem jaringan kepada pengguna yang berwenang. Penerapan RBAC dengan membatasi hak akses berdasarkan peran pengguna terbukti efektif dalam meminimalisasi risiko penyalahgunaan data dan membatasi tindakan pengguna hanya pada fitur yang diizinkan (Dyarenggasto & Setiyawati, 2024 [Unduh PDF](https://www.researchgate.net/publication/377287955_Perancangan_Sistem_Pengarsipan_Surat_dan_Penugasan_Berbasis_Web_Menggunakan_Framework_Laravel)). Pada pengembangan backend monitoring penugasan pegawai ini, RBAC diimplementasikan melalui sistem Middleware di Laravel. Sistem mendefinisikan tiga tingkatan hak akses utama:
1. Super Admin (Kepala Bidang): Memiliki hak tertinggi untuk menyetujui (approve) kegiatan, menghapus data, dan mengelola pengguna.
2. Admin (Kepala Seksi): Bertugas untuk memonitor seluruh kegiatan pegawai, serta mengelola (membuat/mengubah) akun pengguna di bawahnya.
3. User / Pegawai: Entitas pelaksana kegiatan yang hanya berhak melaporkan (input), memperbarui status, dan melihat daftar kegiatannya sendiri.
2.2.6 JSON (JavaScript Object Notation)
JSON (JavaScript Object Notation) adalah format pertukaran data berbasis teks yang ringan, independen terhadap bahasa pemrograman, serta mudah dibaca oleh manusia dan mesin. Dalam arsitektur web modern, JSON digunakan sebagai media komunikasi data standar antara backend dan frontend. Penggunaan format JSON terbukti mempermudah pertukaran data secara aman dan mempercepat respons transmisi data pada RESTful API (Friwaldi & Widiono, 2024 [Unduh PDF](https://www.researchgate.net/publication/386047702_Optimization_of_Direct_Sales_and_Sales_Canvasser_Sales_Target_Monitoring_With_RESTful_API_Implementation_on_Web-Based_Monitoring_System)). Pada sistem monitoring penugasan pegawai ini, format JSON digunakan untuk membungkus respon data dari database backend Laravel ke frontend (KP-ASOY) dan sebaliknya.
2.2.7 Postman (API Testing)
Postman merupakan platform kolaborasi untuk pengembangan dan pengujian API (Application Programming Interface). Postman memungkinkan pengembang mengirimkan berbagai jenis permintaan HTTP (seperti GET, POST, PUT, DELETE) ke server local maupun production dan melihat respon data yang dihasilkan secara langsung untuk memverifikasi fungsionalitas server tanpa bergantung pada kesiapan antarmuka frontend. Pengujian fungsionalitas RESTful API menggunakan Postman dinilai sangat efektif dalam menemukan bug respon data pada tahap pengembangan backend secara dinamis (Putra et al., 2025 [Unduh PDF](https://www.researchgate.net/publication/382025345_RANCANG_BANGUN_SISTEM_INFORMASI_MONITORING_PENCAPAIAN_TARGET_KINERJA_PEGAWAI_PADA_PT_LABDA_ANUGERAH_TEKSTIL_BERBASIS_WEB_MENGGUNAKAN_METODE_WATERFALL)). Pada penelitian ini, Postman digunakan untuk melakukan pengujian fungsionalitas endpoint API (seperti login, pembuatan tugas, perubahan status, dan notifikasi).
2.2.8 Entity Relationship Diagram (ERD)
Entity Relationship Diagram (ERD) adalah model konseptual yang digunakan untuk menggambarkan struktur logis dan hubungan relasi antar tabel dalam suatu basis data relasional. ERD memvisualisasikan entitas-entitas penting dalam sistem, atribut yang melekat pada setiap entitas, serta relasi (seperti *one-to-many* atau *many-to-many*) antar tabel basis data. Perancangan model database terstruktur melalui ERD yang tepat sangat penting dalam memastikan integritas dan performa data dari server backend yang dibangun (Sitanggang et al., 2022 [Unduh PDF](https://www.researchgate.net/publication/377755106_Rancang_Bangun_Sistem_Penjualan_Tanaman_Hias_Berbasis_Web_Menggunakan_PHP_dan_MySQL)). Dalam pengembangan backend monitoring penugasan pegawai ini, ERD digunakan untuk merancang struktur database MySQL, menentukan Primary Key dan Foreign Key, serta memastikan relasi antara data pengguna (*users*), penugasan (*activities*), dan log notifikasi terhubung dengan konsisten.
2.2.9 Hypertext Preprocessor (PHP)
PHP (Hypertext Preprocessor) merupakan bahasa pemrograman server-side yang digunakan untuk membangun aplikasi berbasis web. PHP bekerja dengan cara memproses perintah pada server sebelum hasilnya dikirimkan dan ditampilkan pada browser pengguna. Bahasa pemrograman ini banyak digunakan dalam pengembangan website dinamis karena memiliki sintaks yang sederhana, mudah dipahami, serta mendukung integrasi dengan berbagai jenis database.
PHP bersifat open source sehingga dapat digunakan secara bebas dan memiliki komunitas pengembang yang sangat luas. Selain itu, PHP juga mendukung berbagai framework modern yang dapat mempercepat proses pengembangan aplikasi web, salah satunya adalah Laravel. Dalam implementasinya, PHP mampu menangani berbagai proses seperti pengolahan data, autentikasi pengguna, manajemen session, hingga koneksi database.
Pada penelitian ini, PHP digunakan sebagai bahasa pemrograman utama dalam pengembangan arsitektur backend Sistem Informasi Monitoring Penugasan Pegawai karena ketangguhannya dalam memproses logika bisnis, manajemen database, dan penyediaan antarmuka RESTful API (Sitanggang et al., 2022 [Unduh PDF](https://www.researchgate.net/publication/377755106_Rancang_Bangun_Sistem_Penjualan_Tanaman_Hias_Berbasis_Web_Menggunakan_PHP_dan_MySQL)).
2.2.10 Laragon
Laragon merupakan perangkat lunak local server yang digunakan untuk menjalankan aplikasi web pada komputer lokal. Laragon menyediakan berbagai layanan yang dibutuhkan dalam proses pengembangan website seperti Apache, MySQL, PHP, dan Node.js dalam satu paket aplikasi yang ringan dan mudah digunakan.
Laragon memiliki keunggulan dalam kemudahan konfigurasi, kecepatan proses, serta kompatibilitas dengan berbagai framework modern seperti Laravel. Dengan menggunakan Laragon, pengembang dapat melakukan proses development, testing, dan debugging aplikasi secara lokal sebelum sistem diimplementasikan pada server online.
Pada penelitian ini, Laragon digunakan sebagai lingkungan pengembangan (development environment) untuk menjalankan dan menguji arsitektur backend Sistem Informasi Monitoring Penugasan Pegawai selama proses pengembangan berlangsung (Shahib et al., 2024 [Unduh PDF](https://www.researchgate.net/search/publication?q=Penentuan+Jarak+Lokasi+UMKM+Menggunakan+Metode+Euclidean+Distance+Berbasis+Sistem+Informasi+Geografis)).
2.2.11 Unified Modelling Language (UML)
Unified Modelling Language (UML) merupakan bahasa pemodelan visual yang digunakan untuk menganalisis, merancang, dan menggambarkan suatu sistem perangkat lunak. UML digunakan sebagai standar pemodelan dalam pengembangan perangkat lunak berorientasi objek untuk membantu pengembang memahami kebutuhan serta alur kerja sistem secara lebih terstruktur.
UML berfungsi sebagai alat bantu dalam proses analisis dan perancangan sistem sehingga pengembang dapat memvisualisasikan struktur sistem, alur proses, serta hubungan antar komponen yang terdapat di dalam sistem. Dengan adanya UML, proses pengembangan perangkat lunak menjadi lebih mudah dipahami, terdokumentasi dengan baik, dan meminimalkan terjadinya kesalahan pada saat implementasi sistem.
UML terdiri dari berbagai jenis diagram yang memiliki fungsi berbeda-beda dalam proses perancangan sistem. Beberapa diagram yang umum digunakan antara lain Use Case Diagram, Activity Diagram, Sequence Diagram, dan Class Diagram. Use Case Diagram digunakan untuk menggambarkan hubungan antara pengguna dengan sistem, Activity Diagram digunakan untuk menggambarkan alur aktivitas atau proses kerja sistem, Sequence Diagram digunakan untuk menunjukkan interaksi antar objek dalam sistem, sedangkan Class Diagram digunakan untuk menggambarkan struktur kelas beserta hubungan antar kelas pada sistem.
Pada penelitian ini, UML digunakan sebagai alat bantu dalam merancang Sistem Informasi Monitoring Penugasan Pegawai Dinas Tenaga Kerja dan Transmigrasi agar proses analisis dan pengembangan sistem dapat dilakukan secara sistematis, terarah, dan sesuai dengan kebutuhan pengguna (Narulita et al., 2024 [Unduh PDF](https://www.researchgate.net/publication/383181827_Diagram_Unified_Modelling_Language_UML_untuk_Perancangan_Sistem_Informasi_Manajemen_Penelitian_dan_Pengabdian_Masyarakat_SIMLITABMAS)).
2.2.11.1 Use Case Diagram
Use Case Diagram merupakan diagram UML yang digunakan untuk menggambarkan interaksi antara aktor dengan sistem. Diagram ini menunjukkan fungsi-fungsi utama yang tersedia pada sistem serta hak akses yang dimiliki oleh setiap pengguna. Use Case Diagram digunakan untuk mengetahui kebutuhan fungsional sistem berdasarkan sudut pandang pengguna (Narulita et al., 2024 [Unduh PDF](https://www.researchgate.net/publication/383181827_Diagram_Unified_Modelling_Language_UML_untuk_Perancangan_Sistem_Informasi_Manajemen_Penelitian_dan_Pengabdian_Masyarakat_SIMLITABMAS)).
Dalam penelitian ini, Use Case Diagram digunakan untuk menggambarkan interaksi antara Super Admin, Admin, dan Pegawai dengan Sistem Informasi Monitoring Penugasan Pegawai Dinas Tenaga Kerja dan Transmigrasi, seperti proses login, pengelolaan data penugasan, monitoring laporan, persetujuan (approval) kegiatan, dan pengelolaan data pengguna. Berikut ini adalah simbol-simbol pada Use Case Diagram yang dapat dilihat pada tabel 2.1 berikut ini.
2.2.11.2 Activity Diagram
Activity Diagram merupakan salah satu diagram dalam UML yang digunakan untuk menggambarkan alur aktivitas atau proses kerja yang terjadi di dalam suatu sistem. Diagram ini mendeskripsikan urutan langkah-langkah aktivitas yang dilakukan oleh aktor maupun sistem secara berurutan dari awal hingga akhir proses, termasuk percabangan kondisi (decision) dan aktivitas paralel yang mungkin terjadi.
Activity Diagram sangat berguna untuk memvisualisasikan proses bisnis sistem secara lebih detail sehingga pengembang dapat memahami alur kerja setiap fitur sebelum tahap implementasi dimulai. Diagram ini juga mempermudah komunikasi antara pengembang dan pemangku kepentingan (stakeholder) mengenai bagaimana sistem akan bekerja secara operasional (Baehaki et al., 2024 [Unduh PDF](https://www.researchgate.net/publication/387071060_Sistem_Informasi_Layanan_Laundry_Berbasis_Website_di_Laundry_Happy_Clean)).
Dalam penelitian ini, Activity Diagram digunakan untuk menggambarkan alur proses pada Sistem Informasi Monitoring Penugasan Pegawai Dinas Tenaga Kerja dan Transmigrasi, seperti alur proses login pengguna, alur input penugasan oleh pegawai, alur proses review dan persetujuan (approval) oleh Admin dan Super Admin, serta alur pengiriman notifikasi kepada pengguna terkait. Berikut ini adalah simbol-simbol pada Activity Diagram yang dapat dilihat pada tabel 2.2 berikut ini.
BAB III ANALISIS DAN PERANCANGAN SISTEM
Fokus utama perancangan pada tahap ini diarahkan pada pembentukan arsitektur *Application Programming Interface* (API) yang terstruktur, efisiensi pemrosesan data pada *backend*, serta pemisahan logika bisnis dari antarmuka pengguna (*decoupled architecture*). Pada bagian ini, akan dibahas elemen-elemen perancangan sistem *backend* seperti struktur basis data yang direpresentasikan melalui *Entity Relationship Diagram* (ERD), alur logika pemrosesan data (*flowchart* / *activity diagram*), serta arsitektur integrasi sistem menggunakan standar RESTful API.
3.3 Kebutuhan Sistem
Dalam proses pengembangan **Backend Sistem Monitoring Penugasan Pegawai**, terdapat beberapa kebutuhan sistem yang diperlukan agar *Application Programming Interface* (API) dapat melayani permintaan dari antarmuka pengguna (*frontend*) dengan baik. Kebutuhan sistem terdiri dari perangkat keras (*hardware*), perangkat lunak (*software*), serta kebutuhan dari sisi pengguna (*user*).
a. Perangkat Keras (*Hardware*)
Perangkat keras yang digunakan dalam proses perancangan, pengembangan, dan pengujian *Backend* Sistem Monitoring Penugasan Pegawai pada Dinas Tenaga Kerja dan Transmigrasi Provinsi Kalimantan Barat adalah laptop dengan spesifikasi sebagai berikut:
1) Processor : AMD Ryzen 5 7535HS with Radeon Graphics
2) RAM : 8 GB
3) Penyimpanan : SSD
4) Sistem Operasi : Microsoft Windows 11 Home Single Language 64-bit
5) DirectX Version : DirectX 12
6) System Type : 64-bit Operating System
b. Perangkat Lunak (*Software*)
Perangkat lunak (*software*) merupakan alat yang digunakan untuk membantu proses perancangan, penulisan kode sumber, dan pengujian *endpoint* API agar dapat berjalan sesuai dengan kebutuhan. Adapun perangkat lunak yang digunakan dalam proses pengembangan *backend* ini adalah sebagai berikut:
1) Visual Studio Code (sebagai *code editor*)
2) Laravel Framework (sebagai kerangka kerja utama pembuatan *REST API*)
3) PHP (sebagai bahasa pemrograman *backend*)
4) Laragon (sebagai *local web server* dan manajemen sistem basis data MySQL)
5) Postman (sebagai alat pengujian *endpoint* API)
6) Web Browser (sebagai alat untuk mengakses *database management* seperti phpMyAdmin dan mencari dokumentasi)
3.3.3 Kebutuhan User
Kebutuhan *user* pada *Backend* Sistem Monitoring Penugasan Pegawai dibedakan berdasarkan hak akses (*role*) masing-masing pengguna yang dikelola melalui sistem autentikasi *token* (Laravel Sanctum). Setiap pengguna memiliki fungsi dan otorisasi akses *endpoint* yang berbeda sesuai dengan tugas dan tanggung jawabnya. Adapun kebutuhan *user* yang harus diakomodasi oleh *backend* adalah sebagai berikut:
a. User (Pegawai)
*Backend* harus menyediakan layanan API bagi pegawai lapangan untuk mengelola data kegiatan sesuai penugasan yang diberikan. Melalui API ini, *user* dapat melakukan pemanggilan data (*fetch*) untuk melihat daftar kegiatan yang dimiliki, melakukan *input* kegiatan, mengedit data kegiatan, serta memperbarui status penugasan menjadi selesai. Selain itu, *backend* juga bertanggung jawab menyediakan *endpoint* untuk menampilkan notifikasi apabila kegiatan telah ditinjau oleh *super admin*, serta memproses pengaturan profil akun seperti perubahan email dan kata sandi.
b. Admin (Kasi)
Admin bertugas membantu proses *monitoring* dan pengelolaan data pengguna. Oleh karena itu, *backend* menyediakan *endpoint* khusus yang memungkinkan admin untuk meregistrasi akun *user* baru, mengambil data daftar pengguna, serta mengakses seluruh data penugasan pegawai lapangan dari basis data untuk dipantau secara *real-time*. *Backend* juga memfasilitasi pembuatan *file* unduhan data penugasan (seperti format Excel) sebagai pemenuhan kebutuhan pelaporan admin.
c. Super Admin (Kabid)
*Super admin* merupakan pengguna dengan hak akses otorisasi penuh terhadap sistem API. *Backend* memfasilitasi *super admin* dengan akses penuh untuk mengelola (*Create, Read, Update, Delete*) seluruh entitas akun pengguna dan data penugasan. *Super admin* memiliki wewenang memanggil fungsi API untuk mengubah status penugasan menjadi telah ditinjau, menghapus data kegiatan yang disertai dengan alasan penghapusan (*soft delete*), serta memanipulasi pengelolaan data sistem secara keseluruhan. Selain itu, *backend* juga menyediakan layanan untuk me-reset *password* pengguna dan mengunduh seluruh rekapitulasi data kegiatan sistem.
### 3.4.5 Rancangan Antarmuka (Interface)
Meskipun fokus utama pengembangan sistem ini berada pada sisi *backend*, antarmuka pengguna (*user interface*) tetap dirancang sebagai *frontend* terpisah yang bertugas mengonsumsi layanan API. Pada tahap Analisis dan Perancangan (BAB III), rancangan antarmuka masih berupa sketsa kasar (*wireframe* / *low-fidelity mockup*) yang mendefinisikan tata letak (*layout*) sebelum proses implementasi fisik (*coding*).
Berikut adalah sketsa rancangan antarmuka yang akan terhubung dengan layanan API sistem:
**1. Sketsa Halaman Login**
Halaman ini dirancang untuk memfasilitasi pengguna dalam melakukan autentikasi. Ketika pengguna mengisi formulir, *frontend* akan mengirimkan *request* ke *endpoint* API `/api/login` pada *backend* untuk divalidasi guna mendapatkan *Token Sanctum*.
![Sketsa Halaman Login](file:///C:/Users/LENOVO/.gemini/antigravity/brain/ef10a8a1-642e-4195-87d0-b0eaa709e35a/login_wireframe_1779391022033.png)
**Gambar 3.4** Sketsa Rancangan Antarmuka Halaman Login (*Wireframe*)
**2. Sketsa Halaman Dashboard Penugasan**
Halaman *dashboard* merupakan antarmuka utama yang menampilkan daftar kegiatan pegawai. Halaman ini mensimulasikan pemanggilan data penugasan dari basis data secara dinamis (menggunakan metode HTTP GET) untuk ditampilkan dalam format tabel.
![Sketsa Halaman Dashboard](file:///C:/Users/LENOVO/.gemini/antigravity/brain/ef10a8a1-642e-4195-87d0-b0eaa709e35a/dashboard_wireframe_1779391046956.png)
**Gambar 3.5** Sketsa Rancangan Antarmuka Halaman Dashboard (*Wireframe*)
### 3.4.6 Spesifikasi Basis Data (Kamus Data)
Pada tahap ini, rancangan ERD diimplementasikan ke dalam bentuk fisik tabel pada basis data MySQL. Berikut adalah rincian struktur tabel yang digunakan pada *backend* sistem:
**1. Tabel `users`**
Tabel ini digunakan untuk menyimpan data autentikasi dan otorisasi pengguna sistem.
> *[TEMPATKAN SCREENSHOT STRUKTUR TABEL `users` DARI PHPMYADMIN DI SINI]*
**Gambar 3.5** Implementasi Struktur Tabel *Users* pada Basis Data
| Nama Field | Tipe Data | Keterangan |
| :--- | :--- | :--- |
| `id` | bigint | Primary Key, Auto Increment |
| `name` | varchar | Nama lengkap pengguna |
| `username` | varchar | Nama pengguna untuk akses *login* (Unik) |
| `email` | varchar | Alamat email terdaftar (Unik) |
| `password` | varchar | Kata sandi pengguna yang dienkripsi (*Bcrypt*) |
| `role` | enum | Tingkat hak akses sistem ('superadmin', 'admin', 'user') |
| `jabatan` | varchar | Jabatan pengguna dalam instansi |
**2. Tabel `pegawai`**
Tabel ini berfungsi untuk mencatat profil detail dari pegawai lapangan.
> *[TEMPATKAN SCREENSHOT STRUKTUR TABEL `pegawai` DARI PHPMYADMIN DI SINI]*
**Gambar 3.6** Implementasi Struktur Tabel Pegawai
| Nama Field | Tipe Data | Keterangan |
| :--- | :--- | :--- |
| `id` | bigint | Primary Key, Auto Increment |
| `nip` | varchar | Nomor Induk Pegawai (Unik) |
| `nama` | varchar | Nama lengkap pegawai |
| `user_id` | bigint | Foreign Key yang terhubung ke tabel `users` |
| `deleted_at` | timestamp | Digunakan untuk fitur *Soft Deletes* |
**3. Tabel `penugasan`**
Tabel utama ini digunakan untuk menyimpan riwayat kegiatan atau penugasan pegawai beserta statusnya.
> *[TEMPATKAN SCREENSHOT STRUKTUR TABEL `penugasan` DARI PHPMYADMIN DI SINI]*
**Gambar 3.7** Implementasi Struktur Tabel Penugasan
| Nama Field | Tipe Data | Keterangan |
| :--- | :--- | :--- |
| `id` | bigint | Primary Key, Auto Increment |
| `kegiatan` | varchar | Nama atau deskripsi kegiatan yang ditugaskan |
| `tanggal_mulai` | date | Tanggal dimulainya pelaksanaan kegiatan |
| `status` | enum | Status kegiatan ('proses', 'selesai', 'telah_ditinjau') |
| `created_by` | bigint | Relasi ke `users` (Admin yang membuat tugas) |
| `approved_by` | bigint | Relasi ke `users` (Super Admin yang meninjau) |
### 3.4.7 Perancangan Endpoint RESTful API
Untuk menjembatani pertukaran data antara *frontend* dan *database*, *backend* dirancang untuk menyediakan sekumpulan *endpoint* API yang menerima *request* HTTP dan mengembalikan respons berformat JSON.
> *[TEMPATKAN SCREENSHOT POSTMAN YANG SEDANG MELAKUKAN PENGUJIAN SALAH SATU API DI SINI]*
**Gambar 3.8** Pengujian Implementasi *Endpoint* API menggunakan Postman
Tabel berikut menunjukkan spesifikasi *endpoint* utama yang dikembangkan:
| HTTP Method | Endpoint API | Role Akses | Fungsi / Keterangan |
| :--- | :--- | :--- | :--- |
| `POST` | `/api/login` | Publik | Memvalidasi *username/password* dan mengembalikan *Token* |
| `GET` | `/api/dashboard` | Semua Role | Menampilkan statistik dan daftar aktivitas terbaru |
| `GET` | `/api/penugasan` | Semua Role | Mengambil *list* data penugasan berdasarkan *role* |
| `POST` | `/api/penugasan` | User | Menambahkan data kegiatan baru ke dalam sistem |
| `POST` | `/api/penugasan/{id}/update-status`| Admin / Super | Mengubah *progress* kegiatan menjadi selesai atau ditinjau |
| `POST` | `/api/penugasan/{id}/delete` | Super Admin | Membatalkan penugasan beserta alasan penghapusan |
| `GET` | `/api/export-penugasan` | Super Admin | Mengunduh hasil rekapitulasi data dalam format Excel |
### 3.4.8 Skema Keamanan dan Autentikasi (Laravel Sanctum)
Dalam *decoupled architecture*, sistem tidak menggunakan pengelolaan *session* tradisional antar-halaman, melainkan menggunakan sistem autentikasi berbasis *token* yang aman menggunakan pustaka **Laravel Sanctum**.
> *[TEMPATKAN SCREENSHOT RESPON JSON PADA POSTMAN SAAT BERHASIL LOGIN DI SINI]*
**Gambar 3.9** Respons *Token Sanctum* setelah Proses Autentikasi Berhasil
**Alur Implementasi Keamanan API:**
1. Pengguna mengirimkan *request* berisi kredensial (*username* dan *password*) ke *endpoint* `/api/login`.
2. *Backend* melakukan validasi pencocokan enkripsi. Jika berhasil, sistem menghasilkan *Personal Access Token* yang unik.
3. *Token* tersebut dikembalikan kepada antarmuka pengguna dalam bentuk JSON.
4. Untuk setiap interaksi selanjutnya (misalnya mengakses data `/api/penugasan`), klien diwajibkan menyisipkan token tersebut di dalam *HTTP Header* dengan format `Authorization: Bearer <token_anda>`.
5. *Middleware CheckRole* pada kerangka kerja Laravel akan melakukan intersepsi. Sistem akan mengekstrak profil *user* pemilik token tersebut dan membatasi intervensi fungsi sesuai dengan hak otorisasi yang diizinkan (berbasis *Role-Based Access Control*).
BAB IV HASIL DAN PEMBAHASAN
4.1 Implementasi Sistem
Sistem Informasi Monitoring Penugasan Pegawai telah berhasil diimplementasikan menggunakan arsitektur *decoupled* yang memisahkan bagian antarmuka pengguna (Frontend) dan logika server (Backend). Framework Laravel digunakan untuk membangun RESTful API dan basis data MySQL pada sisi *backend*.
### 4.1.1 Pengembangan Komponen Backend
Implementasi *backend* sistem dilakukan secara menyeluruh pada proyek **Laravel_KP** yang berjalan di *port* 8000. Seluruh logika bisnis, validasi data, dan komunikasi basis data dikelola eksklusif oleh komponen *backend* ini melalui serangkaian *endpoint* REST API yang dikonsumsi oleh *frontend* KP-ASOY. Berikut adalah rincian implementasi dari setiap komponen inti yang dibangun.
---
#### 4.1.1.1 Logika Autentikasi dan Manajemen Sesi (Login System)
Autentikasi sistem dibangun di atas **Laravel Sanctum** yang menghasilkan *Personal Access Token* unik untuk setiap sesi *login* yang berhasil. Logika ini terdapat pada *method* `login()` di dalam `AuthController.php`. Sistem secara cerdas mendeteksi apakah input yang dikirimkan berupa *email* (menggunakan `FILTER_VALIDATE_EMAIL`) atau *username* biasa, kemudian mencocokkan kredensial tersebut menggunakan fungsi `Hash::check()` terhadap *password* terenkripsi yang tersimpan di basis data. Sebagai lapisan keamanan tambahan, semua *token* lama milik pengguna dihapus terlebih dahulu sebelum *token* baru diterbitkan (`$user->tokens()->delete()`), sehingga setiap akun hanya memiliki satu sesi aktif dalam satu waktu.
```php
// File: Laravel_KP/app/Http/Controllers/AuthController.php
// Method: login()
public function login(Request $request)
{
$login = trim($request->username ?? $request->login);
$field = filter_var($login, FILTER_VALIDATE_EMAIL) ? 'email' : 'username';
$user = User::where($field, $login)->first();
if (!$user || !Hash::check($request->password, $user->password)) {
return response()->json(['message' => 'Login gagal.'], 401);
}
// Hapus token lama, terbitkan token baru
$user->tokens()->delete();
$token = $user->createToken('kp-asoy-token')->plainTextToken;
return response()->json(['token' => $token, 'user' => [...]], 200);
}
```
> *[TEMPATKAN SCREENSHOT RESPON JSON TOKEN DI POSTMAN DI SINI]*
> **Gambar 4.1** Implementasi Logika Autentikasi dan Penerbitan Token Sanctum
---
#### 4.1.1.2 Logika Pemrosesan Data Beranda Pengguna (Dashboard User Query)
*Method* `dashboard()` di `PenugasanController.php` bertanggung jawab membangun kueri statistik yang sadar konteks (*context-aware*). Ketika pengguna dengan *role* `user` (Pegawai) mengakses *endpoint* ini, *query* secara otomatis disaring menggunakan `whereHas('petugas')` untuk hanya menampilkan data yang relevan bagi pengguna tersebut saja. Sementara itu, Admin dan Super Admin akan mendapatkan seluruh agregat data tanpa filter. Sistem mengembalikan objek JSON tunggal berisi statistik ringkas (total tugas, jumlah per status) dan lima aktivitas terbaru, yang langsung dikonsumsi oleh *widget* statistik pada *dashboard frontend*.
```php
// File: Laravel_KP/app/Http/Controllers/Api/PenugasanController.php
// Method: dashboard()
public function dashboard()
{
$user = Auth::user();
$query = Penugasan::query();
// Filter hanya data milik user bersangkutan jika role = pegawai
if ($user && $user->role === 'user') {
$query->whereHas('petugas', fn($q) => $q->where('users.id', $user->id));
}
$totalTugas = (clone $query)->count();
$proses = (clone $query)->where('status', 'proses')->count();
$selesai = (clone $query)->where('status', 'selesai')->count();
$terbaru = (clone $query)->with('petugas')->where('status', '!=', 'dibatalkan')
->latest()->limit(5)->get();
return response()->json(['success' => true, 'data' => ['stats' => [...], 'recent_activities' => $terbaru]]);
}
```
> *[TEMPATKAN SCREENSHOT RESPON JSON /api/dashboard DI POSTMAN DI SINI]*
> **Gambar 4.2** Implementasi Kueri Statistik Dashboard yang Sadar Konteks Role
---
#### 4.1.1.3 Logika Validasi dan Penyimpanan Penugasan (Data Store & Validation)
Proses penyimpanan laporan kegiatan baru diimplementasikan pada *method* `store()` di `PenugasanController.php`. Sistem menerapkan validasi bertingkat menggunakan *array* aturan Laravel, termasuk validasi keunikan (`unique:penugasan,nomor_surat`) untuk mencegah duplikasi nomor surat, serta validasi `required|array|min:1` untuk memastikan minimal satu pegawai selalu ditunjuk dalam setiap penugasan. Dukungan *upload* berkas lampiran dokumentasi foto kegiatan juga diproses di sini melalui `$request->file('lampiran')->store('lampiran', 'public')`, yang secara otomatis menyimpan file ke direktori *public storage* dan merekam *path*-nya ke basis data.
```php
// File: Laravel_KP/app/Http/Controllers/Api/PenugasanController.php
// Method: store()
$request->validate([
'nomor_surat' => 'nullable|string|unique:penugasan,nomor_surat',
'kegiatan' => 'required|string',
'tanggal_mulai' => 'required|date',
'pegawai_ids' => 'required|array|min:1',
]);
// Proses upload lampiran jika ada
if ($request->hasFile('lampiran')) {
$lampiranPath = $request->file('lampiran')->store('lampiran', 'public');
}
$penugasan = Penugasan::create([...]);
$penugasan->petugas()->sync($request->pegawai_ids); // Simpan relasi pegawai
```
> *[TEMPATKAN SCREENSHOT FORM INPUT KEGIATAN / RESPON 201 DI POSTMAN DI SINI]*
> **Gambar 4.3** Implementasi Validasi Data dan Penyimpanan Penugasan Baru
---
#### 4.1.1.4 Arsitektur Pengondisian dan Penyaringan Riwayat (Pagination & Policy)
*Method* `index()` pada `PenugasanController.php` mengimplementasikan mekanisme penyaringan data berbasis kebijakan *role* (*role-based policy*) yang konsisten. Kueri Eloquent menggunakan *eager loading* (`with(['petugas', 'pembuat'])`) untuk memuat data relasional dalam satu eksekusi SQL yang efisien dan menghindari masalah *N+1 query*. Penyaringan data diterapkan secara kondisional: pegawai hanya dapat melihat riwayat penugasan yang ditujukan padanya saja (difilter melalui tabel *pivot* `penugasan_pegawai`), sementara Admin dan Super Admin memperoleh akses terhadap keseluruhan dataset tanpa pembatasan.
```php
// File: Laravel_KP/app/Http/Controllers/Api/PenugasanController.php
// Method: index()
public function index(Request $request)
{
$user = Auth::user();
// Eager loading untuk efisiensi query (hindari N+1 problem)
$query = Penugasan::with(['petugas', 'pembuat']);
// Policy: User/Pegawai hanya melihat data miliknya sendiri
if ($user && $user->role === 'user') {
$query->whereHas('petugas', fn($q) => $q->where('users.id', $user->id));
}
$data = $query->latest()->get();
return response()->json(['success' => true, 'data' => $data]);
}
```
> *[TEMPATKAN SCREENSHOT HALAMAN RIWAYAT AKTIVITAS / RESPON GET /api/penugasan DI SINI]*
> **Gambar 4.4** Implementasi Arsitektur Penyaringan Riwayat Berbasis Role
---
#### 4.1.1.5 Logika Enkripsi dan Validasi Keamanan Akun (Password Hashing)
Keamanan data akun pengguna dijaga melalui penerapan enkripsi *password* menggunakan fungsi `bcrypt()` yang merupakan implementasi standar industri untuk *hashing* kata sandi yang tidak dapat dibalik (*one-way hash*). Logika ini terdapat di *method* `register()` dan `updateProfile()` pada `AuthController.php`. Saat pembuatan akun baru, *password* selalu disimpan dalam bentuk terenkripsi. Begitu pula saat pembaruan profil, validasi `Rule::unique()->ignore($user->id)` diterapkan untuk memastikan username yang diperbarui tidak menabrak username pengguna lain namun tetap mengizinkan pengguna mempertahankan username lamanya sendiri.
```php
// File: Laravel_KP/app/Http/Controllers/AuthController.php
// Method: register() & updateProfile()
// REGISTER: Enkripsi password saat pembuatan akun baru
$user = User::create([
'password' => bcrypt($request->password), // One-way hashing
'role' => strtolower($request->role),
...
]);
// UPDATE PROFILE: Validasi keunikan yang mengabaikan ID user sendiri
$request->validate([
'username' => ['required', Rule::unique('users','username')->ignore($user->id)],
'password' => 'nullable|string|min:6',
]);
if ($request->filled('password')) {
$user->password = bcrypt($request->password);
}
```
> *[TEMPATKAN SCREENSHOT HALAMAN PENGATURAN AKUN / RESPON PUT /api/profile/update DI SINI]*
> **Gambar 4.5** Implementasi Enkripsi BCrypt dan Validasi Pembaruan Data Akun
---
#### 4.1.1.6 Mekanisme Pemicu dan Manajemen Pemberitahuan (Notification Trigger)
Sistem notifikasi diimplementasikan menggunakan fitur *Database Notification* bawaan Laravel yang terintegrasi dengan *method* `updateStatus()` dan `destroy()` di `PenugasanController.php`. Ketika Super Admin mengubah status penugasan menjadi `selesai` atau `dibatalkan`, sistem secara otomatis memicu pengiriman notifikasi kepada seluruh pegawai yang terdaftar dalam penugasan tersebut menggunakan *class* `PenugasanStatusNotification`. Notifikasi ini disimpan ke tabel `notifications` di basis data dan dapat diambil kapan saja melalui *endpoint* `/api/notifications` yang dikelola oleh `NotificationController.php`.
```php
// File: Laravel_KP/app/Http/Controllers/Api/PenugasanController.php
// Method: updateStatus() — Pemicu Notifikasi
if (in_array($request->status, ['selesai', 'ditolak'])) {
$action = $request->status === 'selesai' ? 'disetujui' : 'ditolak';
// Kirim notifikasi ke SEMUA pegawai yang terlibat dalam penugasan ini
if ($penugasan->petugas->isNotEmpty()) {
Notification::send(
$penugasan->petugas,
new PenugasanStatusNotification($penugasan, $request->status, $action)
);
}
}
// File: Laravel_KP/app/Http/Controllers/Api/NotificationController.php
// Method: index() — Pengambilan Notifikasi
$notifications = $user->notifications()->latest()->take(20)->get();
```
> *[TEMPATKAN SCREENSHOT IKON LONCENG NOTIFIKASI / RESPON GET /api/notifications DI SINI]*
> **Gambar 4.6** Implementasi Mekanisme Pemicu Notifikasi dan Pengambilan Pemberitahuan
---
#### 4.1.1.7 Logika Filtrasi Hak Akses dan Proteksi Rute (RBAC Middleware)
Proteksi seluruh *endpoint* API diimplementasikan melalui dua lapis mekanisme. **Lapis pertama** adalah *middleware* `auth:sanctum` milik Laravel yang memvalidasi keberadaan dan keabsahan *Bearer Token* di setiap *HTTP Header* permintaan. **Lapis kedua** adalah *middleware* `CheckRole` kustom pada `CheckRole.php` yang membaca properti `role` dari objek pengguna yang terotentikasi dan membandingkannya dengan daftar *role* yang diizinkan untuk mengakses rute tersebut. Penolakan akses akan menghasilkan respons JSON standar dengan kode status HTTP 403 *Forbidden*.
```php
// File: Laravel_KP/app/Http/Middleware/CheckRole.php
public function handle(Request $request, Closure $next, ...$roles)
{
// Lapisan 1: Pastikan user sudah login dan memiliki token valid
// Lapisan 2: Periksa apakah role user ada dalam daftar role yang diizinkan
if (!$request->user() || !in_array($request->user()->role, $roles)) {
return response()->json([
'status' => false,
'message' => 'Akses ditolak! Anda tidak punya hak akses untuk aksi ini.'
], 403);
}
return $next($request);
}
// File: Laravel_KP/routes/api.php — Penerapan Middleware
Route::middleware('auth:sanctum')->group(function () {
Route::post('/login', ...); // Public
Route::get('/penugasan', [PenugasanController::class, 'index']); // Protected
// ...
});
```
> *[TEMPATKAN SCREENSHOT PERCOBAAN AKSES TANPA TOKEN / RESPON 403 DI POSTMAN DI SINI]*
> **Gambar 4.7** Implementasi Middleware RBAC dan Proteksi Rute API
---
#### 4.1.1.8 Kueri Relasional dan Pengelolaan Pengguna (Admin Eloquent Relationship)
Sistem memanfaatkan kemampuan *Eloquent ORM* Laravel untuk membangun kueri relasional yang kompleks secara efisien. Relasi `belongsToMany` antara model `Penugasan` dan `User` melalui tabel *pivot* `penugasan_pegawai` memungkinkan satu penugasan diberikan kepada banyak pegawai sekaligus. Endpoint `GET /api/users` pada `api.php` mengimplementasikan pengambilan data pengguna terstruktur menggunakan `User::select()` untuk membatasi kolom yang dikembalikan (menghindari eksposur data sensitif seperti *password hash*). Endpoint `GET /api/pegawai` secara khusus memfilter hanya pengguna dengan *role* `user` sebagai daftar pegawai yang bisa ditugaskan.
```php
// File: Laravel_KP/routes/api.php — Endpoint Manajemen Pengguna
// Ambil semua pengguna (hanya kolom aman, tanpa password)
Route::get('/users', function () {
return response()->json([
'data' => User::select('id','name','username','email','role','jabatan','created_at')->get()
]);
});
// Ambil daftar pegawai saja (role = 'user'), untuk dropdown form penugasan
Route::get('/pegawai', function () {
return response()->json([
'data' => User::where('role', 'user')->select('id','name','username','jabatan')->get()
]);
});
// File: Laravel_KP/app/Models/Penugasan.php — Relasi Pivot
public function petugas() {
return $this->belongsToMany(User::class, 'penugasan_pegawai', 'penugasan_id', 'pegawai_id');
}
```
> *[TEMPATKAN SCREENSHOT HALAMAN DAFTAR PENGGUNA / RESPON GET /api/users DI SINI]*
> **Gambar 4.8** Implementasi Kueri Relasional Eloquent dan Endpoint Manajemen Pengguna
---
#### 4.1.1.9 Logika Operasi Pembaruan Data Kondisional Pengguna (Admin User Update)
Operasi pembaruan data pengguna diimplementasikan pada *endpoint* `PUT /api/users/{id}` di `api.php`. Logika ini menerapkan prinsip *conditional update*, di mana *field password* hanya akan diperbarui jika pengguna secara eksplisit mengisinya (`$request->filled('password')`). Bila tidak ada *password* baru yang dikirim, data *password* lama akan tetap dipertahankan. Proses enkripsi menggunakan `bcrypt()` selalu diterapkan sebelum penyimpanan. Sistem juga dilengkapi perlindungan ekstra yang mencegah penghapusan akun Super Admin melalui *endpoint* `DELETE /api/users/{id}`, memastikan integritas administrasi sistem terjaga.
```php
// File: Laravel_KP/routes/api.php — Endpoint Update & Delete User
// UPDATE USER: Password hanya diperbarui jika diisi (conditional update)
Route::put('/users/{id}', function (Request $request, $id) {
$user = User::findOrFail($id);
$data = $request->only(['name', 'username', 'role']);
if ($request->filled('password')) {
$data['password'] = bcrypt($request->password); // Hanya jika ada password baru
}
$user->update($data);
return response()->json(['success' => true, 'message' => 'User berhasil diupdate.']);
});
// DELETE USER: Proteksi superadmin dari penghapusan
Route::delete('/users/{id}', function ($id) {
$user = User::findOrFail($id);
if ($user->role === 'superadmin') {
return response()->json(['message' => 'Superadmin tidak dapat dihapus.'], 403);
}
$user->delete();
});
```
> *[TEMPATKAN SCREENSHOT FORM EDIT USER / RESPON PUT /api/users/{id} DI POSTMAN DI SINI]*
> **Gambar 4.9** Implementasi Logika Pembaruan Data Kondisional pada Manajemen Pengguna
---
#### 4.1.1.10 Arsitektur Pengolahan Statistik Global dan Ekspor Laporan (Super Admin Analytics)
Fitur ekspor laporan diimplementasikan menggunakan pustaka **Maatwebsite Excel** yang terintegrasi dengan *class* `PenugasanExport.php`. Kelas ini mengimplementasikan beberapa *interface* sekaligus: `FromCollection` untuk sumber data, `WithHeadings` untuk baris *header*, `WithMapping` untuk transformasi data, dan `WithDrawings` untuk menyisipkan gambar lampiran foto kegiatan secara langsung ke dalam sel kolom Excel yang sesuai. Endpoint `GET /api/export-penugasan` akan memicu unduhan otomatis file `.xlsx` yang terformat rapi dengan data lengkap seluruh penugasan.
```php
// File: Laravel_KP/app/Exports/PenugasanExport.php
class PenugasanExport implements FromCollection, WithHeadings, WithMapping, WithDrawings
{
public function collection() {
return Penugasan::with('petugas')->latest()->get();
}
public function headings(): array {
return ['No','Nomor Surat','Kegiatan','Lokasi','Keterangan','Lampiran','Tanggal','Status','Petugas'];
}
// Sisipkan gambar lampiran ke sel Excel kolom F
public function drawings() {
foreach ($penugasans as $p) {
if ($p->lampiran && Storage::disk('public')->exists($p->lampiran)) {
$drawing->setPath(storage_path('app/public/' . $p->lampiran));
$drawing->setCoordinates('F' . $row);
}
}
}
}
// File: Laravel_KP/routes/api.php
Route::get('/export-penugasan', [PenugasanController::class, 'export']);
```
> *[TEMPATKAN SCREENSHOT FILE EXCEL HASIL UNDUHAN / TOMBOL EXPORT DI SINI]*
> **Gambar 4.10** Implementasi Ekspor Laporan Excel dengan Lampiran Foto Kegiatan
---
#### 4.1.1.11 Logika Distribusi Penugasan Massal (Database Transaction)
Salah satu implementasi teknis kritis adalah penggunaan **Database Transaction** pada *method* `store()` dan `update()` di `PenugasanController.php`. Operasi penyimpanan dibungkus dalam blok `DB::beginTransaction()` dan `DB::commit()`, sehingga jika salah satu dari dua operasi terkait — yaitu penyimpanan data penugasan (`Penugasan::create()`) dan sinkronisasi data pegawai ke tabel *pivot* (`$penugasan->petugas()->sync($request->pegawai_ids)`) — mengalami kegagalan, seluruh operasi akan di-*rollback* (`DB::rollback()`) secara atomik. Ini memastikan tidak ada data yang setengah tersimpan yang dapat merusak integritas basis data relasional.
```php
// File: Laravel_KP/app/Http/Controllers/Api/PenugasanController.php
// Method: store() — Database Transaction untuk Atomisitas
DB::beginTransaction();
try {
// Operasi 1: Simpan data penugasan utama
$penugasan = Penugasan::create([
'kegiatan' => $request->kegiatan,
'tanggal_mulai' => $request->tanggal_mulai,
'status' => 'proses',
'created_by' => Auth::id(),
]);
// Operasi 2: Sinkronisasi pegawai ke tabel pivot (bisa 1 atau banyak pegawai)
$penugasan->petugas()->sync($request->pegawai_ids);
DB::commit(); // Kedua operasi sukses → simpan permanen
return response()->json(['success' => true, 'data' => $penugasan->load('petugas')], 201);
} catch (\Exception $e) {
DB::rollback(); // Satu operasi gagal → batalkan semua
return response()->json(['success' => false, 'message' => $e->getMessage()], 500);
}
```
> *[TEMPATKAN SCREENSHOT RESPON SUKSES 201 SAAT INPUT KEGIATAN DI POSTMAN DI SINI]*
> **Gambar 4.11** Implementasi Database Transaction untuk Distribusi Penugasan Massal
---
#### 4.1.1.12 Penanganan Galat Sisi Server dan Logika Validasi Pengecualian (Error Handling)
Seluruh *method* pada `PenugasanController.php`, `NotificationController.php`, dan `AuthController.php` diimplementasikan dengan pola penanganan galat (*error handling*) yang konsisten menggunakan blok `try-catch`. Setiap potensi kegagalan operasi (*exception*) ditangkap dan dikembalikan sebagai respons JSON terstandarisasi dengan kode HTTP yang sesuai (400, 401, 403, 404, 500) beserta pesan yang informatif. Validasi *request* dari Laravel juga secara otomatis menghasilkan respons 422 *Unprocessable Entity* dengan detail kesalahan per-*field* yang memudahkan *frontend* menampilkan pesan galat yang tepat sasaran kepada pengguna.
```php
// Pola Error Handling Konsisten di Seluruh Backend
// 1. Validasi Request (HTTP 422 otomatis oleh Laravel)
$request->validate([
'nomor_surat.unique' => 'Nomor surat ini sudah terdaftar.', // Pesan kustom
'pegawai_ids.required' => 'Pilih minimal satu petugas.',
]);
// 2. Try-Catch dengan respons JSON terstandarisasi
try {
$penugasan = Penugasan::findOrFail($id); // Lempar 404 jika tidak ada
// ... logika bisnis ...
return response()->json(['success' => true, 'data' => $penugasan]);
} catch (\Illuminate\Database\Eloquent\ModelNotFoundException $e) {
return response()->json(['success' => false, 'message' => 'Data tidak ditemukan.'], 404);
} catch (\Exception $e) {
return response()->json(['success' => false, 'message' => $e->getMessage()], 500);
}
```
> *[TEMPATKAN SCREENSHOT RESPON ERROR VALIDASI 422 / RESPON 404 DI POSTMAN DI SINI]*
> **Gambar 4.12** Implementasi Penanganan Galat Terstandarisasi pada Seluruh Endpoint API
---
4.2 Pengujian Sistem (Black Box Testing)
Pengujian sistem dilakukan menggunakan metode *Black Box Testing*. Pengujian ini bertujuan untuk memastikan bahwa seluruh fungsionalitas sistem berjalan dengan baik sesuai dengan kebutuhan, dengan cara memberikan masukan (input) tertentu dan mengamati keluaran (output) yang dihasilkan tanpa menganalisis struktur kode di dalamnya. Pengujian ini berfokus pada interaksi antarmuka pengguna terhadap *backend* API.
Berdasarkan pengujian langsung pada aplikasi terintegrasi, berikut adalah hasil pengujian *Black Box* yang dibagi berdasarkan *role* pengguna dan fitur spesifiknya:
**Tabel 4.1 Pengujian Akses Login (Semua Role)**
| No | Test Case | Skenario Pengujian | Hasil yang diharapkan | Hasil Pengujian | Referensi Bukti |
|:--:|:---|:---|:---|:---:|:---:|
| 1 | Validasi Login | Memasukkan *username* dan *password* valid (Superadmin/Admin/Pegawai) | Sistem memvalidasi ke API, menerbitkan *Token*, dan mengarahkan ke halaman *dashboard* sesuai *role*. | Berhasil | Gambar 4.x |
| 2 | Invalid Login | Memasukkan *username* atau *password* yang salah | Sistem menolak akses dan menampilkan pesan error peringatan "Username atau password salah". | Berhasil | Gambar 4.x |
| 3 | Form Kosong | Tidak mengisi form *username* dan *password* lalu menekan login | Sistem menampilkan peringatan validasi *native* (*"Please fill out this field"*) dan mencegah *submit*. | Berhasil | Gambar 4.x |
**Tabel 4.2 Pengujian Fitur Role Pegawai (User)**
| No | Test Case | Skenario Pengujian | Hasil yang diharapkan | Hasil Pengujian | Referensi Bukti |
|:--:|:---|:---|:---|:---:|:---:|
| 1 | Dashboard & Notifikasi | Membuka halaman utama (*dashboard*) setelah login | Sistem memuat ringkasan tugas (Proses/Selesai) dan notifikasi terbaru secara *real-time*. | Berhasil | Gambar 4.x |
| 2 | Input Kegiatan | Mengirim form kegiatan dengan melampirkan file dokumentasi | Sistem menyimpan data beserta file lampiran ke *database*, lalu menampilkannya di riwayat dengan status "Proses". | Berhasil | Gambar 4.x |
| 3 | Input Kegiatan (Tanpa Foto) | Mengirim form kegiatan lengkap tanpa mengunggah file foto | Sistem tetap memproses data dengan aman menggunakan format JSON, dan tugas muncul di *dashboard*. | Berhasil | Gambar 4.x |
| 4 | Ubah Status Tugas | Mengklik tombol "Selesaikan Tugas" pada rincian tugas | Status tugas langsung berubah menjadi "Selesai" (label hijau) dan notifikasi terkirim ke sistem. | Berhasil | Gambar 4.x |
**Tabel 4.3 Pengujian Fitur Role Admin (Kepala Seksi)**
| No | Test Case | Skenario Pengujian | Hasil yang diharapkan | Hasil Pengujian | Referensi Bukti |
|:--:|:---|:---|:---|:---:|:---:|
| 1 | Monitoring Global | Membuka halaman "Semua Kegiatan" di menu admin | Tabel menampilkan seluruh daftar tugas dari semua pegawai di instansi beserta status terkininya. | Berhasil | Gambar 4.x |
| 2 | Manajemen User (Tambah) | Admin mendaftarkan akun pegawai baru beserta jabatannya | Sistem menyimpan data ke tabel *users* dan akun tersebut langsung dapat digunakan untuk *login*. | Berhasil | Gambar 4.x |
| 3 | Manajemen User (Edit/Hapus) | Admin mengubah data jabatan pegawai atau menghapus akun | Data akun pada tabel *users* langsung diperbarui/dihapus (*soft delete*) secara presisi. | Berhasil | Gambar 4.x |
**Tabel 4.4 Pengujian Fitur Role Super Admin (Kepala Bidang)**
| No | Test Case | Skenario Pengujian | Hasil yang diharapkan | Hasil Pengujian | Referensi Bukti |
|:--:|:---|:---|:---|:---:|:---:|
| 1 | Approval (Verifikasi) | Super Admin memeriksa rincian tugas lalu menekan "Approve" | Status kegiatan berubah secara permanen menjadi "Telah Ditinjau". | Berhasil | Gambar 4.x |
| 2 | Pembatalan Tugas | Super Admin menghapus tugas pegawai melalui tombol Hapus | Data tugas berhasil dibatalkan dari sistem dan hilang dari *dashboard* utama. | Berhasil | Gambar 4.x |
| 3 | Export Laporan | Super Admin menekan tombol cetak/unduh Laporan | Sistem merespons (*download*) file berformat Excel (.xlsx) yang memuat rekapitulasi data. | Berhasil | Gambar 4.x |
# BAB V PENUTUP
## 5.1 Kesimpulan
Berdasarkan hasil analisis, perancangan, dan implementasi yang telah dilakukan selama kegiatan kerja praktik, dapat disimpulkan bahwa penerapan arsitektur terpisah (*decoupled architecture*) antara *Frontend* (menggunakan antarmuka KP-ASOY) dan *Backend* (menggunakan API Laravel_KP) telah berhasil diwujudkan dengan sangat baik. Pemisahan arsitektur ini memecahkan masalah redundansi basis data yang sebelumnya terjadi dan berhasil menstandarisasi jalur komunikasi data secara eksklusif melalui REST API berbasis JSON. Sistem pengamanan pertukaran data juga telah berjalan optimal melalui penerapan autentikasi berbasis *token* JWT menggunakan fitur bawaan Laravel Sanctum.
Secara fungsionalitas, sistem telah berhasil mengakomodasi tiga tingkatan hak akses (*role-based access control*), yaitu Pegawai (*User*), Kasi (Admin), dan Kabid (*Super Admin*), secara konsisten pada setiap *endpoint* API dan *middleware*. Fitur utama mulai dari pelaporan aktivitas dengan dukungan berkas multimedia (*multipart form-data*), pemantauan kegiatan oleh Admin, hingga validasi dan penghapusan logis (*soft deletes*) oleh Super Admin dapat beroperasi secara komprehensif. Selain itu, perbaikan krusial pada tabel *pivot* relasional telah memastikan fitur notifikasi bekerja secara dinamis untuk memberikan umpan balik langsung kepada pegawai saat laporannya ditinjau.
Hasil pengujian sistem melalui metode *Black Box Testing* mengonfirmasi bahwa seluruh modul pada antarmuka pengguna dapat menerjemahkan dan menampilkan respons dari *backend* API tanpa kegagalan fatal (*fatal error*). Validasi *form* telah berjalan dengan presisi, di mana skenario penanganan galat (*error handling*) mampu memberikan informasi yang tepat saat terjadi kesalahan *input*, sementara pengujian manipulasi basis data memastikan pembaruan status tersinkronisasi secara *real-time* ke sistem pelaporan statistik *dashboard*. Dengan demikian, aplikasi ini dinilai layak dan siap diimplementasikan untuk mendukung efisiensi birokrasi di Dinas Tenaga Kerja dan Transmigrasi Provinsi Kalimantan Barat.
## 5.2 Saran
Dalam rangka peningkatan kualitas sistem di masa yang akan datang, disarankan adanya optimasi lebih lanjut terkait pengalaman pengguna (*User Experience* / UX) pada antarmuka *frontend*. Mengingat komunikasi antara *frontend* dan API rentan terhadap jeda waktu respons jaringan (*latency*), penyediaan indikator visual pemuatan (*loading skeleton* atau *spinner*) sangat direkomendasikan agar pengguna tidak merasa aplikasi membeku saat menunggu respons. Selain itu, fitur pemulihan kata sandi (*reset password*) mandiri melalui tautan *email* perlu ditambahkan guna mengurangi beban administratif *Super Admin*.
Dari sisi arsitektur komunikasi, untuk mencapai pemantauan aktivitas pegawai yang sepenuhnya *real-time* tanpa mengharuskan pengguna memuat ulang (*refresh*) halaman secara manual, sistem disarankan untuk mengadopsi teknologi *WebSockets* (seperti *Laravel Reverb* atau *Pusher*). Implementasi *WebSockets* akan memungkinkan *backend* untuk melakukan *push notification* atau siaran data (*broadcasting*) langsung ke *dashboard* *frontend* secara instan sesaat setelah terjadi perubahan status penugasan di basis data.
Pada aspek keamanan dan ketahanan peladen (*server robustness*), sangat disarankan untuk menerapkan mekanisme pembatasan laju permintaan (*rate-limiting*) yang ketat pada *endpoint-endpoint* krusial (terutama API otentikasi) untuk mencegah serangan pembobolan kata sandi secara paksa (*brute-force*). Diharapkan pula adanya pencatatan riwayat audit (*audit trail*) otomatis yang lebih rinci di dalam *backend* untuk melacak rekam jejak setiap manipulasi data yang dilakukan oleh Admin maupun Super Admin, guna menjamin akuntabilitas pengelolaan sistem secara absolut.
## 5.3 Rekomendasi
Bagi pihak instansi, dalam hal ini Dinas Tenaga Kerja dan Transmigrasi Provinsi Kalimantan Barat, sangat direkomendasikan untuk menyelenggarakan sosialisasi atau pelatihan singkat bagi seluruh calon pengguna akhir (*end-user*). Pelatihan ini penting untuk menjamin kelancaran transisi dari prosedur pelaporan tugas yang bersifat konvensional ke platform digital berbasis web ini, serta meminimalisir kemungkinan *human error* dalam proses *input* laporan harian.
Terkait dengan infrastruktur peluncuran (*deployment*), direkomendasikan agar instansi menggunakan peladen berbasis *cloud* (seperti *Virtual Private Server* / VPS) dengan spesifikasi komputasi yang memadai. *Frontend* dan *Backend* sebaiknya di-host pada lingkungan *container* yang terpisah (misalnya menggunakan *Docker*) guna memaksimalkan stabilitas arsitektur *decoupled*. Penggunaan sertifikat keamanan *HTTPS/SSL* juga mutlak direkomendasikan demi menjaga kerahasiaan pertukaran *Token Sanctum* dan *payload* data antara peramban web klien dengan *server* API.
Secara akademis, sistem *monitoring* penugasan ini memiliki fondasi *backend* yang sangat kuat sehingga dapat direkomendasikan sebagai landasan bagi penelitian atau kerja praktik mahasiswa selanjutnya. Sistem ini dapat dikembangkan lebih ekstensif dengan mengintegrasikan fitur pengenalan wajah (*face recognition*) terintegrasi kecerdasan buatan (AI) serta pelacakan koordinat geolokasi (GPS) sebagai fitur presensi lapangan yang lebih cerdas, mengubah aplikasi ini dari sekadar instrumen pelaporan menjadi ekosistem manajemen kepegawaian yang komprehensif.
DAFTAR PUSTAKA
Baehaki, R., Azukruf, R., & Haryono, W. (2024). Perancangan Aplikasi Sistem Informasi Layanan Laundry Berbasis Website di Laundry Happy Clean. Jurnal Komputer Antartika.
* Tautan Unduh PDF Langsung (ResearchGate): https://www.researchgate.net/publication/387071060_Sistem_Informasi_Layanan_Laundry_Berbasis_Website_di_Laundry_Happy_Clean
Dyarenggasto, Y. P., & Setiyawati, N. (2024). Perancangan Sistem Pengarsipan Surat dan Penugasan Berbasis Web Menggunakan Framework Laravel. Jurnal Indonesia: Manajemen Informatika dan Komunikasi, 5(1), 622-634.
* Tautan DOI Resmi: https://doi.org/10.35870/jimik.v5i1.528
* Tautan Unduh PDF Langsung (ResearchGate): https://www.researchgate.net/publication/377287955_Perancangan_Sistem_Pengarsipan_Surat_dan_Penugasan_Berbasis_Web_Menggunakan_Framework_Laravel
Friwaldi, R. D., & Widiono, S. (2024). Optimization of Direct Sales and Sales Canvasser Sales Target Monitoring With RESTful API Implementation on Web-Based Monitoring System. Journal of Applied Informatics and Computing (JAIC), 8(2).
* Tautan DOI Resmi: https://doi.org/10.30871/jaic.v8i2.8644
* Tautan Unduh PDF Langsung (ResearchGate): https://www.researchgate.net/publication/386047702_Optimization_of_Direct_Sales_and_Sales_Canvasser_Sales_Target_Monitoring_With_RESTful_API_Implementation_on_Web-Based_Monitoring_System
Putra, I K. S., Putra, I G. J. E., & Utami, N. W. (2025). Rancang Bangun Sistem Informasi Monitoring Pencapaian Target Kinerja Pegawai pada PT. Labda Anugerah Tekstil Berbasis Web Menggunakan Metode Waterfall. Jurnal Sistem Informasi (JUSIN), 6(2), 79–90.
* Tautan DOI Resmi: https://doi.org/10.32546/jusin.v6i2.3225
* Tautan Unduh PDF Langsung (ResearchGate): https://www.researchgate.net/publication/382025345_RANCANG_BANGUN_SISTEM_INFORMASI_MONITORING_PENCAPAIAN_TARGET_KINERJA_PEGAWAI_PADA_PT_LABDA_ANUGERAH_TEKSTIL_BERBASIS_WEB_MENGGUNAKAN_METODE_WATERFALL
Narulita, S., Nugroho, A., & Abdillah, M. Z. (2024). Diagram Unified Modelling Language (UML) untuk Perancangan Sistem Informasi Manajemen Penelitian dan Pengabdian Masyarakat (SIMLITABMAS). Bridge: Jurnal Publikasi Sistem Informasi dan Telekomunikasi, 2(3), 244–256.
* Tautan DOI Resmi: https://doi.org/10.62951/bridge.v2i3.174
* Tautan Unduh PDF Langsung (ResearchGate): https://www.researchgate.net/publication/383181827_Diagram_Unified_Modelling_Language_UML_untuk_Perancangan_Sistem_Informasi_Manajemen_Penelitian_dan_Pengabdian_Masyarakat_SIMLITABMAS
Rizki, D. F. A., & Chotijah, U. (2025). Perancangan Sistem Monitoring dan Manajemen Proyek Pegawai Berbasis Website dengan Framework Laravel. Jurnal Informatika dan Teknik Elektro Terapan (JITET), 13(3S1).
* Tautan DOI Resmi: https://doi.org/10.23960/jitet.v13i3S1.7770
* Tautan Unduh PDF Langsung (ResearchGate): https://www.researchgate.net/publication/386401037_PERANCANGAN_SISTEM_MONITORING_DAN_MANAJEMEN_PROYEK_PEGAWAI_BERBASIS_WEBSITE_DENGAN_FRAMEWORK_LARAVEL
Shahib, M. U., Irawan, B., & Bhakti, R. M. H. (2024). Penentuan Jarak Lokasi UMKM Menggunakan Metode Euclidean Distance Berbasis Sistem Informasi Geografis. Jurnal Tekno Kompak, 18(2).
* Tautan Unduh PDF Langsung (ResearchGate): https://www.researchgate.net/search/publication?q=Penentuan+Jarak+Lokasi+UMKM+Menggunakan+Metode+Euclidean+Distance+Berbasis+Sistem+Informasi+Geografis
Sitanggang, R., Dachi, T. U., & Manurung, I. H. G. (2022). Rancang Bangun Sistem Penjualan Tanaman Hias Berbasis Web Menggunakan PHP dan MySQL. Jurnal Teknologi Kesehatan dan Ilmu Sosial (TEKESNOS), 4(1), 84–90.
* Tautan OJS Resmi: https://e-journal.sari-mutiara.ac.id/index.php/tekesnos/article/view/2822
* Tautan Unduh PDF Langsung (ResearchGate): https://www.researchgate.net/publication/377755106_Rancang_Bangun_Sistem_Penjualan_Tanaman_Hias_Berbasis_Web_Menggunakan_PHP_dan_MySQL