337 lines
9.1 KiB
Markdown
337 lines
9.1 KiB
Markdown
# Prompt for Django Agent – Motamarat Project
|
||
|
||
## Objective
|
||
|
||
Develop a complete Django-based system for managing CME/CPD activities, requests, approvals, and registry workflows in alignment with the Motamarat Project BRD. The solution should include full backend (Django + DRF) implementation, frontend templates using ColorAdmin, and workflow automation based on roles and statuses.
|
||
|
||
---
|
||
|
||
## 1. Project Overview
|
||
|
||
The **Motamarat Project** is a CME/CPD management and accreditation system designed for hospital educational departments. It manages:
|
||
|
||
* Requests for CME/CPD activities.
|
||
* Multi-level approvals (Department → CME Head → Specialist → Coordinator → Requester).
|
||
* Conversion of approved requests into accredited CPD Activities.
|
||
* Scientific programs, speaker management, financial forecasting, and attendance tracking.
|
||
* Integration with Mustamir, SCFHS, and Motamarat for accreditation and announcement.
|
||
|
||
---
|
||
|
||
## 2. App Structure
|
||
|
||
Create three main Django apps:
|
||
|
||
1. **cme_requests** – for activity requests and approval workflows.
|
||
2. **cpd_registry** – for accredited activities and their detailed management.
|
||
3. **cme_plans** – for yearly planning and pre-approved activities per CoE.
|
||
|
||
A shared **core_cme** app may contain reusable models, enums, mixins, and integrations.
|
||
|
||
---
|
||
|
||
## 3. Implementation Sequence
|
||
|
||
Follow this exact order when generating the project:
|
||
|
||
1. `models.py`
|
||
2. `signals.py` (if needed)
|
||
3. `utils.py` (for validation, workflow logic, integrations)
|
||
4. `forms.py`
|
||
5. `views.py`
|
||
6. `urls.py`
|
||
7. Templates list
|
||
8. DRF layer (`serializers.py`, `api_views.py`, `routers & urls`)
|
||
|
||
---
|
||
|
||
## 4. Core Models (models.py)
|
||
|
||
### 4.1 Common Models
|
||
|
||
* **TimeStampedModel**, **SoftDeleteModel** – abstract base classes.
|
||
* **ChoiceEnums** – include enums for event types, delivery methods, languages, status, sub-status, sites, etc.
|
||
* **Lookup Tables** – Country, City, Specialty, TargetAudience, Department, SubDepartment, etc.
|
||
|
||
### 4.2 CME Requests
|
||
|
||
**CMEActivityRequest**
|
||
|
||
* request_number (unique)
|
||
* requester (FK User)
|
||
* title_ar, title_en
|
||
* event_type, is_repeated, repeated_accreditation_no
|
||
* aims_outcomes, goals_objectives (JSON, list ≤50 words)
|
||
* learning_methods, evaluation_method
|
||
* professional_fields, target_audiences (M2M)
|
||
* learning_gap, needs_assessment_tools
|
||
* specialty, subspecialty, language, other_language
|
||
* proposed_date, remarks
|
||
* international_speakers (Yes/No + count 1–20)
|
||
* location (country, city, venue_type, capacity)
|
||
* delivery_method, estimated_expenses, estimated_income
|
||
* collaboration details, attachments
|
||
* workflow fields: status, sub_status, assigned_to
|
||
|
||
### 4.3 Approvals
|
||
|
||
* **DepartmentApproval** (FK request, approver, decision, comment)
|
||
* **CMEHeadReview** (FK request, editor, JSON of changes, added_approvers)
|
||
* **AdditionalApproval** (FK request, approver, decision, comment)
|
||
* **CMECoordinatorProcess** (conference date reservation, Mustamir payload)
|
||
* **RequesterDateApproval** (decision, comment)
|
||
* **RequestAttachment** (FK request, file, type)
|
||
|
||
### 4.4 CPD Registry
|
||
|
||
**CPDActivity**
|
||
|
||
* category, date_of_event, scfhs_request_no, accreditation_no
|
||
* status (Approved/Rejected/Cancelled)
|
||
* hours, motamarat_status, announcement_status
|
||
* request_number, requester_name, request_date
|
||
* committee_chairman, duration_days (1–5), assigned_to, site
|
||
* comments, timestamps
|
||
|
||
**OrganizingCommitteeMember**, **Speaker**, **ScientificProgramItem**, **FinancialForecast**, **AnnouncementRequest**, **AttendanceBatch**, **Attendance**
|
||
|
||
Each sub-model should include validation and relationships per BRD.
|
||
|
||
### 4.5 CME Plans
|
||
|
||
**CMEPlanSubmission** – yearly CoE submissions.
|
||
**CMEPlannedEvent** – nested planned events under a submission.
|
||
|
||
---
|
||
|
||
## 5. Signals (signals.py)
|
||
|
||
* Auto-generate request_number on save.
|
||
* Validate 6-week rule for proposed_date.
|
||
* Send email notifications for each step transition.
|
||
* On completion, auto-create CPDActivity from CMEActivityRequest.
|
||
* When accreditation_no or hours are added → notify requester.
|
||
* On speaker finalization → send info email.
|
||
|
||
---
|
||
|
||
## 6. Utils (utils.py)
|
||
|
||
### Submodules:
|
||
|
||
* **choices.py** – all enumerations.
|
||
* **validators.py** – 6-week rule, ranges, conditionals.
|
||
* **workflow.py** – finite-state transitions.
|
||
* **finance.py** – budget and net distribution logic.
|
||
* **integrations.py** – API stubs for Mustamir, SCFHS, Motamarat.
|
||
* **emails.py** – templated notifications.
|
||
|
||
---
|
||
|
||
## 7. Forms (forms.py)
|
||
|
||
Create Django forms for each model with conditional fields and validation logic:
|
||
|
||
* `CMEActivityRequestForm`
|
||
* `DepartmentApprovalForm`, `CMEHeadReviewForm`, `AdditionalApprovalForm`
|
||
* `CMECoordinatorConferenceForm`, `RequesterDateApprovalForm`, `EventConfirmForm`
|
||
* `CPDActivityForm`, `SpeakerForm`, `ScientificProgramForm`
|
||
* `FinancialForecastFormset`, `AnnouncementForm`, `AttendanceForm`
|
||
* `CMEPlanSubmissionForm`, `CMEPlannedEventForm`
|
||
|
||
---
|
||
|
||
## 8. Views (views.py)
|
||
|
||
### CME Requests App
|
||
|
||
Use Django CBVs:
|
||
|
||
* Create, List, Detail, Update views for requests.
|
||
* Workflow actions as separate form views:
|
||
|
||
* SubmitRequestView
|
||
* DepartmentApprovalView
|
||
* CMEHeadReviewView
|
||
* AdditionalApprovalView
|
||
* ConferenceDateConfirmView
|
||
* RequesterDateApprovalView
|
||
* EventConfirmView
|
||
* CompleteRequestView (creates CPDActivity)
|
||
|
||
### CPD Registry App
|
||
|
||
* Manage CPDActivity and related objects (committee, speakers, program, finances, announcement, attendance).
|
||
* Actions: send to Motamarat, speaker emails, attendee reminders.
|
||
|
||
### CME Plans App
|
||
|
||
* CRUD for CMEPlanSubmission.
|
||
* HeadReviewView, SpecialistDesignView, CompletePlanView.
|
||
|
||
---
|
||
|
||
## 9. URLs (urls.py)
|
||
|
||
### CME Requests
|
||
|
||
```
|
||
requests/
|
||
requests/new/
|
||
requests/<pk>/submit/
|
||
requests/<pk>/approve/
|
||
requests/<pk>/review/
|
||
requests/<pk>/conference-date/
|
||
requests/<pk>/complete/
|
||
```
|
||
|
||
### CPD Registry
|
||
|
||
```
|
||
activities/
|
||
activities/<pk>/speakers/
|
||
activities/<pk>/program/
|
||
activities/<pk>/finances/
|
||
activities/<pk>/announcement/
|
||
activities/<pk>/attendance/
|
||
```
|
||
|
||
### CME Plans
|
||
|
||
```
|
||
plans/
|
||
plans/<pk>/review/
|
||
plans/<pk>/design/
|
||
plans/<pk>/complete/
|
||
```
|
||
|
||
---
|
||
|
||
## 10. Templates
|
||
|
||
Organize templates under respective apps:
|
||
|
||
### cme_requests
|
||
|
||
* request_form.html
|
||
* request_detail.html
|
||
* request_list.html
|
||
* dept_approval.html
|
||
* head_review.html
|
||
* additional_approval.html
|
||
* conference_date.html
|
||
* requester_date.html
|
||
* event_confirm.html
|
||
* request_timeline.html
|
||
|
||
### cpd_registry
|
||
|
||
* activity_list.html
|
||
* activity_detail.html
|
||
* speakers.html
|
||
* program.html
|
||
* finances.html
|
||
* announcement.html
|
||
* attendance.html
|
||
* certificate.html
|
||
|
||
### cme_plans
|
||
|
||
* plan_form.html
|
||
* plan_list.html
|
||
* plan_detail.html
|
||
* plan_review.html
|
||
* plan_design.html
|
||
|
||
Include shared email templates under `emails/`.
|
||
|
||
---
|
||
|
||
## 11. DRF Layer
|
||
|
||
### serializers.py
|
||
|
||
* `CMEActivityRequestSerializer` (nested approvals)
|
||
* `DepartmentApprovalSerializer`, `CMEHeadReviewSerializer`, etc.
|
||
* `CPDActivitySerializer` (nested models)
|
||
* `SpeakerSerializer`, `ScientificProgramSerializer`, `FinanceSerializer`
|
||
* `AnnouncementSerializer`, `AttendanceSerializer`
|
||
* `CMEPlanSubmissionSerializer`, `CMEPlannedEventSerializer`
|
||
|
||
### api_views.py
|
||
|
||
Implement ViewSets with custom workflow actions:
|
||
|
||
* `CMEActivityRequestViewSet` – handles submission & approval steps.
|
||
* `CPDActivityViewSet` – handles registry and notifications.
|
||
* `CMEPlanSubmissionViewSet` – handles plan reviews.
|
||
* `LookupViewSet` – provides dropdown data.
|
||
|
||
### routers & urls
|
||
|
||
```
|
||
router.register('requests', CMEActivityRequestViewSet)
|
||
router.register('activities', CPDActivityViewSet)
|
||
router.register('plans', CMEPlanSubmissionViewSet)
|
||
router.register('lookups', LookupViewSet)
|
||
```
|
||
|
||
Use nested routers for committee/speakers/programs/attendance.
|
||
|
||
---
|
||
|
||
## 12. Integration Points
|
||
|
||
* **Mustamir API** – for submission and status tracking.
|
||
* **Motamarat API** – for event announcement.
|
||
* **SCFHS API** – for accreditation status and CME hours.
|
||
* **Email/Notification Service** – for workflow communication.
|
||
|
||
---
|
||
|
||
## 13. Automation & Validations
|
||
|
||
* Enforce 6-week lead time before event.
|
||
* Conditional field rendering in templates and API.
|
||
* Auto emails at workflow transitions.
|
||
* Auto creation of CPDActivity after final approval.
|
||
* Attendance reminders (D-1 and event day 06:30).
|
||
|
||
---
|
||
|
||
## 14. Deliverables
|
||
|
||
* Django project scaffold with modular apps.
|
||
* DRF API endpoints with nested routes.
|
||
* Admin panel customization for each model.
|
||
* ColorAdmin templates for all forms and lists.
|
||
* Email notification system integrated via Celery.
|
||
* Integration stubs for external systems.
|
||
* Documentation for setup and environment variables.
|
||
|
||
---
|
||
|
||
## 15. Environment & Dependencies
|
||
|
||
* Django 5.x, DRF 3.15+
|
||
* PostgreSQL
|
||
* Celery + Redis (for async tasks)
|
||
* django-filter, drf-nested-routers
|
||
* requests (for integrations)
|
||
* ColorAdmin theme for frontend
|
||
|
||
---
|
||
|
||
## 16. Testing & QA
|
||
|
||
* Unit tests for models, serializers, and views.
|
||
* Workflow integration tests.
|
||
* API tests for each endpoint.
|
||
* Validation of lead time, financials, and conditional rules.
|
||
|
||
---
|
||
|
||
## 17. Expected Outcome
|
||
|
||
The agent should generate a **fully functional Django + DRF project** implementing all workflows, validations, and integrations described above. The system must be modular, production-ready, and compliant with the BRD's described business logic for the Motamarat Project.
|