# 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.