Skip to main content

2025-09-05

1. Struktur Definisi Proyek (Collection MongoDB: projects)

Di MongoDB, ini akan menjadi collection projects Anda. Setiap dokumen dalam collection ini merepresentasikan satu proyek tunggal.

Model Proyek yang Diusulkan (Project.php)

Definisi Field (collection projects)

CRUD Awal (Konteks Laravel/MongoDB)

  • Buat (Create): Panggilan standar Project::create($validatedData) di controller Anda.
  • Baca (Read - List): Project::where('isArchived', false)->get() dengan filter yang diterapkan melalui klausa where() tambahan.
  • Baca (Read - Detail): Project::findOrFail($id).
  • Perbarui (Update): $project->update($validatedData).
  • Hapus (Delete - Soft): $project->update(['isArchived' => true]).

2. Organisasi dan Alur Jadwal & Pelacakan Dokumen Proyek

Dengan MongoDB, Anda memiliki pilihan: menyematkan (embed) revisi di dalam dokumen induk atau menyimpannya dalam collection terpisah.
  • Embedding: Proses baca cepat, tetapi dapat menyebabkan dokumen menjadi besar (batas 16MB) dan menyulitkan query untuk semua revisi di seluruh sistem.
  • Collection Terpisah (Referencing): Pendekatan yang direkomendasikan dan lebih skalabel. Ini meniru struktur relasional tetapi dengan fleksibilitas NoSQL. Ini menjaga ukuran dokumen tetap terkendali dan memungkinkan query yang kuat pada revisi itu sendiri.
Mari kita lanjutkan dengan pendekatan Collection Terpisah.

Model 1: ProjectDocument (Collection: projectDocuments)

Collection ini menyimpan catatan master untuk setiap dokumen yang dikendalikan. Ini berisi metadata dan, yang terpenting, ringkasan status terkininya untuk pencarian cepat. Contoh currentRevision Embedded Document: Ini adalah kunci untuk performa. Saat Anda memuat daftar dokumen, Anda tidak memerlukan query kedua untuk menemukan status setiap dokumen.

Model 2: DocumentRevision (Collection: documentRevisions)

Collection ini adalah riwayat yang dapat diaudit—log dari setiap versi setiap dokumen. Contoh fileReference Embedded Document: Ini memberikan fleksibilitas untuk penyedia penyimpanan yang berbeda.

Alur dan CRUD (Konteks Laravel/MongoDB)

  1. Membuat Dokumen Baru:
  • Pengguna mengisi formulir untuk dokumen baru (docCode, title, dll.) dalam sebuah proyek.
  • Secara Transaksional:
  1. Buat catatan ProjectDocument.
  2. Buat catatan DocumentRevision pertama (cth., Rev A) dengan status: 'Draft'.
  3. Perbarui embedded document currentRevision pada ProjectDocument dengan info dari revisi baru.
  4. Mengajukan untuk Ditinjau (Transisi Status):
  • Penulis mengunggah file dan mengklik “Submit”.
  • Backend memperbarui catatan DocumentRevision yang sesuai, mengubah status dari Draft menjadi Submitted for Review dan mengatur actualSubmissionDate.
  • currentRevision.status pada ProjectDocument juga diperbarui untuk mencerminkan perubahan ini.
  1. Menyetujui/Menolak (Transisi Status):
  • Peninjau membuat keputusan.
  • Backend memperbarui status catatan DocumentRevision menjadi Approved atau Resubmission Required.
  • currentRevision.status pada ProjectDocument diperbarui.
  1. Membuat Revisi Baru:
  • Pengguna memulai revisi baru (misalnya, karena yang sebelumnya Resubmission Required atau perlu pembaruan).
  • Secara Transaksional:
  1. Temukan DocumentRevision lama dan perbarui status-nya menjadi Superseded.
  2. Buat catatan DocumentRevision baru (cth., Rev B) dengan status: 'Draft'.
  3. Perbarui embedded document currentRevision pada ProjectDocument induk untuk menunjuk ke Rev B yang baru ini.

Tampilan Alternatif Collection (Cara Melakukan Query)

Tampilan frontend tetap sama, tetapi query backend akan memanfaatkan struktur MongoDB ini.

1. Tampilan Daftar Dokumen (Berbasis List)

  • Query: Cukup ProjectDocument::where('projectId', $projectId)->get().
  • Mengapa cepat: Semua data yang diperlukan (docCode, title, currentRevision.status, currentRevision.revisionNumber) ada di dokumen utama. Tidak diperlukan join atau lookup untuk menampilkan daftar, membuatnya sangat berkinerja.

2. Tampilan Linimasa (Berbasis Jadwal)

  • Query: DocumentRevision::whereIn('documentId', $documentIds)->get(). ($documentIds adalah array _id dari dokumen proyek).
  • Logika: Query ini mengambil semua revisi historis dan saat ini untuk dokumen dalam proyek. Anda kemudian dapat melakukan iterasi melalui ini di backend atau frontend Anda untuk membangun linimasa, memplot bar berdasarkan plannedSubmissionDate dan plannedApprovalDate. Anda dapat memfilter query ini hanya untuk revisi yang “aktif” jika diperlukan.

3. Tampilan Papan Kanban (Berbasis Alur Kerja)

  • Query: ProjectDocument::where('projectId', $projectId)->get().
  • Logika: Data untuk papan Kanban juga berasal langsung dari collection projectDocuments. Logika frontend akan mengelompokkan dokumen ke dalam kolom berdasarkan nilai field currentRevision.status. Tindakan seret dan lepas (drag-and-drop) akan memicu panggilan API untuk melakukan transisi status yang dijelaskan dalam alur kerja di atas.

Diagram Alur & Entitas

Tentu saja. Memvisualisasikan alur dan hubungan adalah langkah penting. Berikut adalah visualisasi menggunakan notasi Mermaid untuk alur siklus hidup dokumen dan hubungan entitas data.

1. Alur Kerja Revisi Dokumen (Alur)

Diagram ini mengilustrasikan siklus hidup satu revisi dokumen. Ini menunjukkan status yang dapat dimiliki revisi dan tindakan yang menyebabkannya beralih dari satu status ke status lain. Konsep kuncinya adalah bahwa tindakan seperti “Setujui” atau “Tolak” bersifat final untuk revisi tertentu (mis., Rev A). Untuk melanjutkan pekerjaan, revisi baru (Rev B) dibuat, yang memulai kembali siklus hidup dari status Draft.

2. Diagram Hubungan Entitas Data (Struktur)

Diagram ER ini menunjukkan bagaimana berbagai collection MongoDB (projects, projectDocuments, documentRevisions, dll.) saling terkait. Ini memperjelas hubungan “satu-ke-banyak” yang menjadi tulang punggung sistem Anda.
  • Sebuah Project berisi banyak ProjectDocuments.
  • Sebuah ProjectDocument memiliki riwayat banyak DocumentRevisions.
  • Users memainkan berbagai peran (Manajer Proyek, Penulis, Peninjau).

Cara Menafsirkan Diagram ER:

  • ||--|{: Merepresentasikan hubungan “satu-ke-banyak”. Misalnya, satu catatan PROJECTS terkait dengan banyak catatan PROJECT_DOCUMENTS.
  • }o--|{: Juga merepresentasikan hubungan “satu-ke-banyak”, tetapi digambar dari perspektif sisi “satu”. Misalnya, satu catatan USERS dapat terkait dengan banyak PROJECTS sebagai manajer.
  • PK: Singkatan dari Primary Key (di MongoDB, ini adalah _id).
  • FK: Singkatan dari Foreign Key. Ini menunjukkan field yang menyimpan _id dari collection lain untuk membuat hubungan (mis., PROJECT_DOCUMENTS.projectId menyimpan PROJECTS._id).

UI / UX

Permintaan yang sangat baik. Memvisualisasikan alur antarmuka pengguna (UI) dan hubungannya dengan operasi CRUD backend adalah kunci untuk memahami bagaimana sistem akan berfungsi. Berikut adalah visualisasi menggunakan notasi flowchart Mermaid. Saya telah membaginya menjadi dua area utama seperti sebelumnya: Manajemen Proyek dan Manajemen Dokumen Proyek.

1. Alur CRUD Manajemen Proyek

Diagram ini mengilustrasikan perjalanan pengguna untuk mengelola Daftar Proyek. Ini adalah implementasi CRUD yang standar dan lugas.

Penjelasan Alur Proyek:

  1. Tampilan Collection (Daftar Proyek):
  • Pengguna memulai dari daftar semua proyek, disajikan dalam Datatable. Ini adalah layar utama “Baca” (List).
  • Dari sini, mereka dapat memulai pembuatan proyek baru atau memilih yang sudah ada untuk melihat detailnya.
  1. UI Formulir Buat (Formulir Buat Proyek):
  • Formulir sederhana untuk memasukkan detail proyek (projectName, projectCode, dll.).
  • Mengirimkan formulir ini membuat permintaan POST ke API Anda. Jika berhasil, pengguna dialihkan kembali ke daftar, yang sekarang menampilkan proyek baru.
  1. UI Tampilan Item (Dasbor Proyek):
  • Ini adalah tampilan rinci dari satu proyek. Ini menampilkan semua informasi proyek.
  • Halaman ini adalah pusat untuk tindakan yang terkait dengan proyek spesifik ini, seperti mengeditnya, mengarsipkannya, atau, yang paling penting, menavigasi ke dokumen terkaitnya.
  1. UI Formulir Edit (Formulir Edit Proyek):
  • Identik dengan formulir buat tetapi sudah diisi sebelumnya dengan data proyek yang ada.
  • Mengirimkannya membuat permintaan PUT atau PATCH untuk memperbarui catatan.

2. Alur CRUD Manajemen Dokumen Proyek

Alur ini lebih kompleks karena melibatkan beberapa jenis tampilan dan proses pembaruan yang didorong oleh alur kerja (perubahan status).

Penjelasan Alur Dokumen:

  1. Titik Masuk (Dasbor Proyek): Pengguna sudah melihat proyek tertentu dan memilih untuk mengelola dokumennya.
  2. Tampilan Collection (Inti):
  • Pengguna disajikan dengan satu atau lebih cara untuk melihat daftar dokumen. Sebuah tombol atau menu memungkinkan mereka untuk beralih antar tampilan.
  • Datatable: Tampilan default yang kaya informasi.
  • Linimasa: Memvisualisasikan jadwal.
  • Kanban: Memvisualisasikan status alur kerja.
  • Grid: Terbaik untuk dokumen berorientasi visual seperti gambar arsitektur atau mockup, menunjukkan thumbnail.
  • Tree Datatable: Ideal untuk set dokumen kompleks di mana dokumen bersarang, seperti spesifikasi master dengan beberapa sub-bagian.
  • Semua tampilan ini menawarkan dua tindakan utama: Menambah dokumen baru atau Melihat detail dokumen yang ada.
  1. UI Formulir Buat (Formulir Buat Dokumen):
  • Formulir ini untuk membuat catatan master dokumen (ProjectDocument). Ini menangkap metadata seperti docCode dan title. Revisi awal biasanya dibuat secara otomatis di latar belakang dengan status Draft.
  1. UI Tampilan Item (Halaman Detail Dokumen):
  • Ini adalah pusat untuk satu dokumen. Ini menunjukkan semua metadatanya dan, yang paling penting, daftar revisinya (Rev A, Rev B, dll.).
  • Dari sini, pengguna dapat melakukan dua jenis “pembaruan” yang berbeda:
  • Edit Metadata: Mengubah catatan master dokumen (mis., memperbaiki kesalahan ketik pada judul).
  • Buat Revisi Baru: Ini adalah tindakan alur kerja utama. Ini membuka formulir untuk mengunggah file baru, membuat catatan DocumentRevision baru dan memulai siklus hidupnya.
  1. Kasus Khusus - Pembaruan Kanban:
  • Tampilan Kanban menawarkan proses pembaruan yang unik dan efisien. Alih-alih membuka formulir, pengguna cukup menyeret kartu dari satu kolom (mis., Diajukan untuk Ditinjau) ke kolom lain (mis., Disetujui).
  • Tindakan UI ini memicu permintaan PATCH langsung ke API untuk memperbarui hanya status revisi tersebut, memberikan pengalaman pengguna yang cepat dan intuitif untuk mengelola alur kerja.

Wireframes (Berbasis Tabel)

Tentu. Berikut adalah output gabungan, memasangkan setiap wireframe UI (diperkirakan dalam tabel Markdown) dengan rincian komponennya. Ini memberikan tata letak visual dan penjelasan fungsional untuk setiap layar utama.

1. Daftar Proyek (Tampilan List/Datatable)

Tata Letak UI

Rincian Komponen

Tujuan: Untuk menampilkan daftar semua proyek aktif, memungkinkan pengguna untuk mencari, memfilter, dan menavigasi ke proyek tertentu atau membuat yang baru.

2. Formulir Buat / Edit Proyek

Tata Letak UI

Rincian Komponen

Tujuan: Untuk menyediakan antarmuka pengguna untuk memasukkan atau mengubah detail proyek. Tampilan ini digunakan bersama untuk mode “Buat” dan “Edit”.

3. Dasbor Proyek (Lihat Detail Proyek)

Tata Letak UI

Rincian Komponen

Tujuan: Untuk berfungsi sebagai pusat utama untuk satu proyek, menampilkan semua informasinya dan menyediakan navigasi ke modul terkait seperti dokumen.

4. Daftar Dokumen (Tampilan List/Datatable)

Tata Letak UI

Rincian Komponen

Tujuan: Terletak di dalam sebuah proyek, tampilan ini mencantumkan semua dokumen yang terkait dengannya dan memungkinkan pengguna untuk beralih antara mode visualisasi yang berbeda.

5. Halaman Detail Dokumen (Lihat Detail Dokumen)

Tata Letak UI

Rincian Komponen

Tujuan: Untuk menampilkan informasi lengkap dan riwayat versi untuk satu dokumen.

6. Formulir Buat Revisi Baru

Tata Letak UI

Rincian Komponen

Tujuan: Formulir terfokus untuk mengunggah versi baru dari dokumen yang ada dan mengatur jadwalnya.

Wireframes (Berbasis Teks)

Oke, berikut adalah wireframe dasar untuk tampilan CRUD utama yang telah kita diskusikan, dengan fokus pada tata letak dan elemen inti. Wireframe ini adalah sketsa sederhana, bukan UI yang dirancang sepenuhnya. Tujuannya adalah untuk mengilustrasikan struktur dan alur interaksi.

1. Daftar Proyek (Tampilan List/Datatable)

Elemen Kunci:
  • Tombol “Proyek Baru”: Memulai operasi Buat (Create).
  • Pencarian & Filter: Memungkinkan pengguna menemukan proyek dengan cepat.
  • Datatable: Kolom menampilkan informasi kunci proyek. Mengklik baris akan mengarahkan ke Dasbor Proyek.
  • Paginasi: Menangani jumlah proyek yang besar.

2. Formulir Buat/Edit Proyek

Elemen Kunci:
  • Judul: Menunjukkan apakah ini formulir Buat atau Edit.
  • Tombol “Kembali”: Kembali ke Daftar Proyek atau Dasbor.
  • Isian Formulir: Menangkap semua data proyek.
  • Indikator Wajib: Menandai dengan jelas bidang yang wajib diisi.
  • Tombol “Batal” & “Simpan”: Aksi untuk formulir. Kode Proyek harus dinonaktifkan dalam mode edit.

3. Dasbor Proyek (Lihat Detail Proyek)

Elemen Kunci:
  • Judul: Menampilkan Nama Proyek.
  • Tombol “Kembali”: Kembali ke Daftar Proyek.
  • Tombol Aksi: “Edit” dan “Arsipkan”.
  • Bidang Tampilan: Menyajikan semua data proyek dalam format hanya-baca.
  • Navigasi Tab: Mengorganisir informasi terkait (dokumen, anggota tim, risiko, dll.). Tab “Dokumen” mengarah ke tampilan Manajemen Dokumen.

4. Daftar Dokumen (Tampilan List/Datatable)

Tampilan ini berada di dalam Dasbor Proyek, di bawah tab “Dokumen”.
Elemen Kunci:
  • Tombol “Kembali”: Kembali ke Dasbor Proyek.
  • Tombol ”+ Tambah Dokumen”: Membuat catatan ProjectDocument baru.
  • Dropdown “Lihat”: Memilih antara tampilan Datatable, Linimasa, Kanban, Grid, Tree Table.
  • Filter: Spesifik untuk atribut dokumen (Disiplin, Status).
  • Datatable: Menampilkan metadata dokumen. Mengklik baris mengarah ke Halaman Detail Dokumen.

5. Halaman Detail Dokumen (Lihat Detail Dokumen)

Elemen Kunci:
  • Tombol “Kembali”: Kembali ke Daftar Dokumen.
  • Tombol “Edit Metadata”: Memungkinkan pengeditan catatan dokumen inti.
  • Tombol “Buat Revisi Baru”: Memulai pengunggahan file baru dan pembuatan DocumentRevision baru.
  • Metadata Dokumen: Menampilkan atribut utama dokumen.
  • Tabel Revisi: Menampilkan riwayat revisi dokumen, termasuk status, penulis, tanggal, dan tautan unduh untuk file.

6. Formulir Buat Revisi Baru

Elemen Kunci:
  • Label Jelas: Menunjukkan formulir untuk membuat revisi baru.
  • Input Penting: Pemilih Tanggal untuk menentukan jadwal.
  • Input Penting: Bidang Unggah File untuk menempatkan versi dokumen terbaru.
Wireframe ini adalah titik awal. Spesifik UI Anda akan bergantung pada pilihan desain, pengguna target, dan tampilan serta nuansa keseluruhan yang ingin Anda capai.