BUG pada halaman Pengampu Kelas (Kelas & Dosen)

[banghajidotcom]

Pada halaman ini ditemukan BUG yang sifatnya FATAL secara administratif, disebabkan kesalahan logika (dan mungkin juga karena belum ada aturan baku). Kronologi kasusnya sebagai berikut:

1. Admin melakukan perubahan data (edit-update) pada Pengampu Kelas.
2. Pesan yang tampil adalah Not Found!, tetapi data berhasil berubah.
3. Salah seorang mahasiswa mencetak FRS, dan...
4. Matakuliah yang (telah) diambil sebelumnya (pada semester yang sama) menjadi "HILANG" karena sebab poin 1.
5. Pada hasil studi (KHS dan Transkrip), matakuliah seperti poin 4 juga "HILANG".

BUG di atas muncul karena terjadi perubahan ID pengampu kelas yang menyebabkan tidak sinkron dengan rincian studi.

Melihat pada kronologi dan BUG (lojik) tersebut khususnya poin selain 2, perlu dibuat aturan:

• Proses input Pengampu Kelas harus sudah selesai sebelum waktu pengisian FRS dimulai.
• Tidak boleh ada permission untuk melakukan edit-update/delete pada Pengampu Kelas sejak dimulainya waktu pengisian FRS semester aktif tersebut sampai kapan pun.

[osi-stmikplk]

Boleh klarifikasi untuk perubahan pengampu kelas ini adalah pada bagian yang menjadi bagian generate ID yah? Jadi data yang dirubah asumsi saya adalah kelas, pengampu kelas/dosen, MK, dan TA.

Pada versi selanjutnya ini tidak semestinya terjadi, namun pada versi sekarang BUG tersebut memang akan terjadi karena proses ID digenerate seperti hal tersebut akibat kebutuhan untuk mempermudah proses migrasi.

Ada solusi diantaranya:

• perubahan bisa dilakukan tapi saat di edit maka ID tidak di generate ulang, atau
• seperti disampaikan di atas, data tidak dapat diubah karena sudah ada yang mereferensikannya

Menggunakan asumsi data tidak dapat dirubah setelah dibuat dan dimulai FRS juga tidak pas, karena ada kemungkinan pergantian dosen. Jadi menurut pendapat saya data bisa dirubah tapi tidak merubah ID. Bagaimana dengan ini?

[banghajidotcom]

Menggunakan asumsi data tidak dapat dirubah setelah dibuat dan dimulai FRS juga tidak pas, karena ada kemungkinan pergantian dosen. Jadi menurut pendapat saya data bisa dirubah tapi tidak merubah ID. Bagaimana dengan ini?

Siap, solusi "tidak merubah ID" bisa diterapkan :+1:

[osi-stmikplk]

ada yang lebih mudah tapi ini hanya untuk DB yang mendukung, yaitu FK dengan opsi cascade update :green_apple:

[banghajidotcom]

bahaya itu, kalo "terhapus" berarti semua data yang direferensi akan ... :ghost:

[osi-stmikplk]

Di FK kan ada 2 friend: cascade delete dan cascade update.

Kalau yang kamu makasudkan untuk terhapus itu kalau dia di setting cascade delete, nah di sini kita tidak aktifkan yang cascade delete tapi diaktivkan yang cascade update.

Bagaimana untuk ini? Sepertinya ini yang paling cepat dan mudah :apple:

[banghajidotcom]

oke, setuju, tolong dikerjakan ya hehe :sunglasses: btw, itu mungkin bakal ratausan record yg akan diupdate :ghost:

[osi-stmikplk]

:facepunch: tinggal bikin make:migration :eyeglasses:

tar ku pull dulu pull req punya mu nih dan kemudian mohon di test lah ...

[banghajidotcom]

mana? hehe

[osi-stmikplk]

Dibuat begini dulu, tambahkan validator dan untuk edit tidak merubah ID.

Hal ini karena didepannya kita tidak menggunakan generated id sebagai Primary Key.

Mohon di test @banghaji

[banghajidotcom]

oke sebentar di-fetch dulu si osi-stmikplk nya :smile:

[banghajidotcom]

siip friend, kasus solved :+1: boleh di close