PROMIS

Konteks & masalah

Change Request yang diajukan ke tim IT melewati beberapa tim dan beberapa tahap workflow sebelum ditutup. Setiap perpindahan adalah perubahan status, dan sah tidaknya sebuah perpindahan bergantung pada posisi request saat itu serta siapa yang memintanya.

Aturan tersebut berada di frontend. Akibatnya sebuah request bisa dipindahkan ke status yang seharusnya tidak pernah dicapainya, atau dipindahkan oleh orang yang rolenya tidak mengizinkan.

Pengguna & tim

Tim-tim yang dilewati sebuah Change Request, dan pemohon yang menunggunya. Kebutuhan keduanya sama: status terkini, siapa penanggung jawabnya sekarang, sejauh mana progresnya — dan semua itu harus bisa dipercaya.

Kontribusi pribadi

• Memindahkan aturan transisi status Change Request dari frontend ke backend.
• Memvalidasi setiap perubahan terhadap tiga hal: status sebelumnya, role pengguna, dan tahap workflow yang diizinkan.
• Menyediakan hanya status tervalidasi melalui API.
• Membangun ulang tampilan status, penanggung jawab, dan progres di frontend di atas data tervalidasi tersebut.

Arsitektur & keputusan

Next.js di frontend, NestJS di backend, MySQL sebagai database.

Aturan yang ditegakkan di frontend hanyalah anjuran. Ia berlaku hanya untuk pengguna yang melewati interface itu, pada build itu, tanpa panggilan API langsung di tengahnya. Memindahkan aturan transisi ke sisi server membuat backend menjadi satu-satunya penentu sah atau tidaknya sebuah perubahan status, dan menyisakan satu tugas bagi frontend: menampilkan apa yang dinyatakan benar oleh API.

Fitur utama

• Transisi status Change Request divalidasi di backend.
• Setiap transisi diperiksa terhadap status sebelumnya, role pengguna, dan tahap workflow yang diizinkan.
• Status, penanggung jawab, dan progres ditampilkan di frontend hanya dari data tervalidasi.

Tantangan & solusi

Tidak ada satu pun pemeriksaan yang cukup berdiri sendiri. Role saja memungkinkan seorang manajer mendorong request melewati tahap yang belum dicapainya. Status sebelumnya saja memungkinkan siapa pun memajukan request yang bukan tanggung jawabnya. Tahap workflow saja mengabaikan siapa yang meminta.

Karena itu transisi divalidasi terhadap ketiganya sekaligus, sebelum perubahan ditulis. Request yang gagal di salah satu pemeriksaan akan ditolak, bukan disimpan lalu diperbaiki belakangan.

Hasil

Change Request tidak lagi bisa melompati tahap atau dipindahkan oleh pengguna tanpa hak akses, karena backend menolak transisi itu sebelum tersimpan.