Deploy WebGIS 01-05 dengan Docker
This commit is contained in:
@@ -0,0 +1,230 @@
|
||||
# RANGKUMAN PENTING PROJECT 05 - WebGIS Poverty Mapping
|
||||
|
||||
File ini merangkum catatan penting saja dari beberapa file catatan revisi/migrasi.
|
||||
|
||||
---
|
||||
|
||||
## 1. File SQL yang Penting Disimpan
|
||||
|
||||
Simpan file SQL berikut sebagai backup database dan migrasi:
|
||||
|
||||
1. `schema.sql`
|
||||
- Struktur database dasar.
|
||||
- Dipakai jika ingin instal ulang database dari awal.
|
||||
|
||||
2. `migration_fix_multi_ri_pin.sql`
|
||||
- Memperbaiki masalah admin rumah ibadah yang punya lebih dari satu rumah ibadah.
|
||||
- Menambahkan aturan satu akun penerima hanya boleh punya satu pin aktif.
|
||||
|
||||
3. `migration_revisi_persetujuan_hapus.sql`
|
||||
- Menambahkan fitur pengajuan/persetujuan hapus marker rumah ibadah dan pin penerima.
|
||||
|
||||
4. `migration_revisi_sinkronisasi.sql`
|
||||
- Memperbaiki sinkronisasi penerima dengan rumah ibadah terdekat.
|
||||
|
||||
Rekomendasi:
|
||||
- Jangan letakkan file SQL di folder publik saat hosting.
|
||||
- Simpan di folder backup lokal, misalnya `backup_sql/`.
|
||||
|
||||
---
|
||||
|
||||
## 2. Perbaikan Paling Penting pada Sistem
|
||||
|
||||
### A. Admin Rumah Ibadah Multi-RI
|
||||
|
||||
Masalah lama:
|
||||
- Admin rumah ibadah hanya terbaca punya 1 rumah ibadah karena query memakai `LIMIT 1`.
|
||||
- Akibatnya, pin/marker dari rumah ibadah lain tidak muncul.
|
||||
|
||||
Perbaikan:
|
||||
- Sistem sekarang mendukung admin yang mengelola lebih dari satu rumah ibadah.
|
||||
- Query memakai daftar ID rumah ibadah, bukan hanya 1 ID.
|
||||
|
||||
Dampak:
|
||||
- Pin penerima dan rumah ibadah milik admin tampil lebih lengkap.
|
||||
- Laporan, riwayat, program bantuan, dan penyaluran mengikuti semua rumah ibadah milik admin.
|
||||
|
||||
---
|
||||
|
||||
### B. Satu Akun Penerima Hanya Boleh Satu Pin Aktif
|
||||
|
||||
Masalah lama:
|
||||
- Satu akun penerima bisa punya lebih dari satu pin aktif.
|
||||
- Ini menyebabkan data tidak sinkron dan penerima bisa muncul di beberapa rumah ibadah.
|
||||
|
||||
Perbaikan:
|
||||
- Sebelum menambah pin, sistem mengecek apakah user penerima sudah punya pin aktif.
|
||||
- Pin aktif yang dimaksud adalah status `menunggu` atau `diterima`, dan belum disetujui hapus.
|
||||
- Database juga ditambah unique key agar satu user tidak bisa punya lebih dari satu pin aktif.
|
||||
|
||||
---
|
||||
|
||||
### C. Sinkronisasi Radius 300 Meter
|
||||
|
||||
Masalah lama:
|
||||
- Penerima bisa terhubung ke rumah ibadah yang salah.
|
||||
- Jika radius beberapa rumah ibadah saling beririsan, sistem belum selalu memilih yang paling dekat.
|
||||
|
||||
Perbaikan:
|
||||
- Penerima dihitung ulang berdasarkan rumah ibadah aktif terdekat dalam radius 300 meter.
|
||||
- Jika rumah ibadah dihapus, penerima dilepas lalu dicari ulang ke rumah ibadah aktif terdekat lain.
|
||||
|
||||
---
|
||||
|
||||
### D. Persetujuan Hapus Marker/Pin
|
||||
|
||||
Alur baru:
|
||||
- Super admin bisa menghapus marker rumah ibadah dan pin penerima secara langsung.
|
||||
- Admin rumah ibadah hanya bisa mengajukan hapus rumah ibadah/penerima.
|
||||
- Penerima bisa mengajukan hapus pin miliknya sendiri.
|
||||
- Pengajuan hapus harus disetujui super admin.
|
||||
|
||||
Dampak:
|
||||
- Data tidak langsung hilang sembarangan.
|
||||
- Ada kontrol dari super admin.
|
||||
- Marker yang sudah disetujui hapus tidak tampil lagi di peta dan laporan aktif.
|
||||
|
||||
---
|
||||
|
||||
### E. CRUD Akun
|
||||
|
||||
Super admin dapat mengelola:
|
||||
- Akun admin rumah ibadah.
|
||||
- Akun penerima.
|
||||
|
||||
Admin rumah ibadah dapat mengelola:
|
||||
- Akun penerima saja.
|
||||
|
||||
Fitur:
|
||||
- Tambah akun.
|
||||
- Lihat daftar akun.
|
||||
- Filter role/status.
|
||||
- Cari nama/username.
|
||||
- Edit akun.
|
||||
- Hapus akun jika belum punya relasi data.
|
||||
- Nonaktifkan akun jika sudah punya relasi agar audit data tidak rusak.
|
||||
|
||||
---
|
||||
|
||||
### F. Validasi Program dan Penyaluran Bantuan
|
||||
|
||||
Perbaikan penting:
|
||||
- Program bantuan tidak otomatis mengambil rumah ibadah pertama.
|
||||
- Admin yang punya banyak rumah ibadah harus memilih rumah ibadah.
|
||||
- Penyaluran hanya bisa dicatat jika program dan penerima berada di rumah ibadah yang sama.
|
||||
- Tombol "Catat" tidak muncul lagi jika program sudah selesai.
|
||||
- Dropdown penerima difilter sesuai rumah ibadah dari program yang dipilih.
|
||||
|
||||
---
|
||||
|
||||
### G. Perbaikan Logika NULL
|
||||
|
||||
Masalah lama:
|
||||
- Nilai kosong seperti nominal, jarak meter, atau rumah_ibadah_id bisa tersimpan sebagai `0`, bukan `NULL`.
|
||||
|
||||
Perbaikan:
|
||||
- Query INSERT/UPDATE dipisah agar nilai kosong benar-benar masuk sebagai `NULL`.
|
||||
|
||||
Dampak:
|
||||
- Data lebih bersih.
|
||||
- Tidak muncul rumah_ibadah_id = 0 atau jarak_meter = 0 yang menyesatkan.
|
||||
|
||||
---
|
||||
|
||||
### H. Validasi Client-side
|
||||
|
||||
Ditambahkan validasi sebelum data dikirim:
|
||||
- Program wajib dipilih.
|
||||
- Penerima wajib dipilih.
|
||||
- Nama program wajib diisi.
|
||||
- Bulan harus 1-12.
|
||||
- Tahun minimal 2000.
|
||||
- Nama, username, dan password wajib saat membuat akun baru.
|
||||
- Password minimal 6 karakter.
|
||||
|
||||
---
|
||||
|
||||
## 3. Catatan Error SQL
|
||||
|
||||
### Error #1044 information_schema
|
||||
|
||||
Penyebab:
|
||||
- Akun MySQL tidak punya akses membaca `INFORMATION_SCHEMA`.
|
||||
|
||||
Solusi:
|
||||
- Gunakan file migrasi versi manual.
|
||||
- Atau jalankan `jalankan_migrasi_fix.php` jika file itu tersedia.
|
||||
- Setelah selesai, hapus `jalankan_migrasi_fix.php`.
|
||||
|
||||
---
|
||||
|
||||
### Error #1064 IF NOT EXISTS
|
||||
|
||||
Penyebab:
|
||||
- Versi MySQL/MariaDB tidak mendukung syntax:
|
||||
`ALTER TABLE ... ADD COLUMN IF NOT EXISTS`
|
||||
|
||||
Solusi:
|
||||
- Gunakan file `migration_fix_multi_ri_pin.sql` versi kompatibel.
|
||||
- Jika ada penerima dengan pin aktif ganda, rapikan dulu lewat dashboard super admin.
|
||||
- Setelah itu jalankan ulang migration.
|
||||
|
||||
---
|
||||
|
||||
## 4. File Catatan yang Bisa Digabung/Hapus
|
||||
|
||||
Setelah rangkuman ini dibuat, file catatan berikut boleh dipindahkan ke backup:
|
||||
|
||||
- `CATATAN_FIXED_MULTI_RI.md`
|
||||
- `CATATAN_PERBAIKAN_LOGIKA.md`
|
||||
- `CATATAN_REVISI_CRUD_AKUN.md`
|
||||
- `CATATAN_REVISI_PERSETUJUAN_HAPUS.md`
|
||||
- `CATATAN_SQL_ERROR_1044.md`
|
||||
- `CATATAN_SQL_ERROR_1064.md`
|
||||
|
||||
Jangan langsung buang permanen jika proyek masih diperiksa dosen/penguji.
|
||||
|
||||
---
|
||||
|
||||
## 5. Rekomendasi Struktur Folder
|
||||
|
||||
Gunakan struktur seperti ini:
|
||||
|
||||
```text
|
||||
05/
|
||||
├── index.php
|
||||
├── login.php
|
||||
├── register.php
|
||||
├── koneksi.php
|
||||
├── auth.php
|
||||
├── tambah_penerima.php
|
||||
├── tambah_penyaluran.php
|
||||
├── tambah_program_bantuan.php
|
||||
├── edit_user.php
|
||||
├── hapus_user.php
|
||||
├── ...
|
||||
└── backup_dokumentasi/
|
||||
├── RANGKUMAN_PENTING_PROJECT_05.md
|
||||
└── backup_sql/
|
||||
├── schema.sql
|
||||
├── migration_fix_multi_ri_pin.sql
|
||||
├── migration_revisi_persetujuan_hapus.sql
|
||||
└── migration_revisi_sinkronisasi.sql
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Kesimpulan
|
||||
|
||||
Yang paling penting disimpan:
|
||||
1. `schema.sql`
|
||||
2. Semua file `migration_*.sql`
|
||||
3. Satu file rangkuman ini
|
||||
4. File PHP aplikasi utama
|
||||
|
||||
Yang tidak wajib ada di folder utama aplikasi:
|
||||
- File catatan `.md`
|
||||
- File SQL backup
|
||||
- File migrasi yang sudah selesai dijalankan
|
||||
|
||||
Untuk hosting, file SQL dan catatan revisi sebaiknya tidak ikut berada di folder publik.
|
||||
Reference in New Issue
Block a user