marwan/HH
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
HH/docs/workflows/inquiries.md
ismail 6baa34dec3 update and nug fixes
2026-07-11 19:24:28 +03:00

29 KiB
Raw Blame History

Inquiries — Workflow & Lifecycle

Source of truth: apps/complaints/ (the Inquiry model lives inside the complaints app, not a separate one). URL namespace inquiries, mounted at /inquiries/. This document describes the current implementation only. Every claim is cited as file:line.

⚠ Read first — docs/workflows.md is partly out of date for Inquiries. The most important change: the dept_response_acceptance_status field that backed the "PX accepts/rejects" loop was removed (migration 0039), so that loop no longer exists in code. The model also has no clean()/CheckConstraint enforcing statuses.

1. Purpose

Inquiry is "for general questions/requests. Similar to complaints but for non-complaint inquiries." (apps/complaints/models.py:1528-1533).

Architectural differences vs. Complaint (intended, per docs/workflows.md:31-39):

  • Single department, flat fields — Inquiry carries department-response data as flat columns on the row (transferred_to_department, outgoing_department, department_response_en/ar, models.py:1824-1854). Complaint uses a multi-department join model.
  • One-level review — champion responds → PX accepts/rejects → resolve. No department-manager tier (docs/workflows.md:34-35). (See §14 — the accept/reject field was removed.)
  • Resolve requires a PX response — the PX team must write inquiry.response before resolving (ui_views.py:3356-3358).
  • No investigation sub-flow like Complaint's InvestigationResponse. InquiryExplanation is a simple token-response mechanism (§8).
  • No signals — apps/complaints/signals.py wires receivers only for Complaint/ComplaintUpdate/ComplaintInvolvedDepartment; zero Inquiry signal receivers.

Shared vocabulary with Complaints: open → in_progress → resolved → closed (models.py:1695-1705).

2. How a Case Starts

2.1 Who can create

  • DRF/API: CanCreateInquiry (apps/complaints/permissions.py:39-67) — PX Admins, Hospital Admins, Source Users with can_create_inquiries, everyone else (incl. patients). InquiryViewSet requires IsAuthenticated (views.py:2895).
  • UI form: @login_required (ui_views.py:2978).

2.2 Creation channels (4 entry points)

Channel View URL name Auth
Authenticated UI form ui_views.inquiry_create (ui_views.py:2980) inquiries:inquiry_create (urls_inquiries.py:11) @login_required
Public portal (complaints app) ui_views.public_inquiry_submit (ui_views.py:4707) inquiries:public_inquiry_submit (urls_inquiries.py:27) None
Public portal (core app) apps.core.views.public_inquiry_submit (apps/core/views.py:170) core:public_inquiry_submit (apps/core/urls.py:38) None
DRF API InquiryViewSet.perform_create (views.py:2909) — IsAuthenticated + CanCreateInquiry

Incoming vs. Outgoing — controlled by is_outgoing (models.py:1803-1805): False (default) = incoming (from a patient/source into the hospital); True = outgoing (hospital contacts an external/other department; paired with outgoing_department, models.py:1834). Set via hidden form field (forms.py:676-681), read in create view (ui_views.py:3001-3011). Public submissions are always incoming. Reports split on this flag (inquiry_export_incoming/outgoing, ui_views.py:4196,4216) — corresponding to "Reports - Incoming/Outgoing Inquiries.xlsx".

2.3 Information required before submission

InquiryForm (forms.py:564) — required: hospital, location_type, category, subject, message. Optional: patient, area, department, contact_name/phone/email, section, priority, source, is_outgoing, outgoing_department.

Public form (public_inquiry_submit) — hand-rolled validation (ui_views.py:4725-4735) requires: name, phone, hospital, subject, message.

⚠ Gap: PublicInquiryForm (forms.py:857) exists and declares name/phone/hospital/location_type required, but public_inquiry_submit validates manually and does not use it — may be vestigial.

2.4 What happens immediately after submission

Inquiry.save() (models.py:1980-2027):

  1. Loads previous status into _status_was (models.py:1982).
  2. Stamps resolved_at/closed_at only on transitions into those statuses, not on creation (models.py:1993-2000).
  3. Generates reference number if missing: generate_reference("INQ", hospital) → INQ-YYYYMM-NNNN (models.py:2002-2005).
  4. Sets SLA deadline due_at = now + sla_hours from InquirySLAConfig (models.py:2007-2012).
  5. Auto-derives timeline_sla bucket (24/48/72/>72h) from due_at - created_at (models.py:2014-2025).
  6. Default status = OPEN (models.py:1703).

Background tasks after creation:

  • analyze_inquiry_with_ai.delay(...) — AI priority/department/taxonomy/emotion (tasks.py:2991).
  • notify_staff_new_item.delay("inquiry", ...) — admin notification email (tasks.py:2490).
  • link_inquiry_patient.delay(...) — async patient lookup (tasks.py:3314).
  • InquiryUpdate "Inquiry created." timeline entry (ui_views.py:3046).

Activation gate: a new inquiry is open and cannot be sent to a department until activated to in_progress. Send endpoints reject status == "open" (ui_views.py:3594, 3841).

⚠ Gap — no creation acknowledgement to inquirer: unlike Complaint (which has a send_complaint_creation_sms post_save signal), Inquiry has no creation-acknowledgement signal. The inquirer is not auto-notified on submission; only staff are notified via notify_staff_new_item.

3. Complete Lifecycle

3.1 Status "enum"

There is no InquiryStatus enum class and no VALID_INQUIRY_TRANSITIONS map. Status is a plain CharField with inline choices (models.py:1695-1705): open, in_progress, resolved, closed.

3.2 Transition enforcement — effectively NONE

  • No clean() method on Inquiry.
  • No constraints/CheckConstraint in Meta or migrations (models.py:1971-1978) — only indexes.

⚠ Gap vs docs/workflows.md:11-13: that doc claims invalid statuses are "rejected at the model (clean()) and DB (CheckConstraint) level." This is true for Complaint, but NOT for Inquiry. inquiry_change_status accepts any string the user POSTs and saves it (the only guard is resolved-requires-response). The choices are not DB-enforced.

3.3 Where transitions actually happen

From → To Mechanism File:line
open → in_progress inquiry_activate (sets status + activated_at if open) ui_views.py:3207
open → in_progress inquiry_update_contact_stage stage under_process ui_views.py:4274
resolved/closed → in_progress inquiry_assign auto-reopens on reassignment ui_views.py:3282
resolved/closed → in_progress inquiry_reopen ui_views.py:3409
* → resolved inquiry_respond (sets response + status) — requires non-empty response ui_views.py:3486
* → resolved API InquiryViewSet.respond — requires response views.py:2963
* → resolved inquiry_change_status — blocks if no response ui_views.py:3356
* → closed inquiry_change_status with status="closed" (no dedicated close view) ui_views.py:3330
* → anything inquiry_change_status accepts arbitrary new_status ui_views.py:3345

save() stamps resolved_at/resolved_by/closed_at/closed_by on entry (models.py:1993-2000) using _acting_user (set by views).

4. Status Definitions

Status Purpose When entered Who moves forward Next
open Received; not yet owned/worked On creation (default) PX/Admin/Manager/Employee via inquiry_activate in_progress
in_progress Being actively worked Activation, reassignment of resolved/closed, reopen, under_process stage Assignee/PX/Champion resolved, closed (or reopen)
resolved A PX response has been written and sent inquiry_respond / API respond / change_status (gated on response) PX/Admin/Hosp-Admin/Manager/Employee/Assignee/Champion closed; reopen → in_progress
closed Permanently completed inquiry_change_status to closed PX/Admin/Hosp-Admin/Manager/Employee reopen → in_progress (rare)

is_active_status returns True for open/in_progress (models.py:2132).

⚠ Status-choice anomaly: the detail view exposes status_choices that include "contacted" and "contacted_no_response" (ui_views.py:2758-2765). These are NOT valid Inquiry statuses (they're contact_status values mixed in). If selected via change-status, they persist as out-of-choices values — treat as a UI bug.

5. Workflow Actions

All UI inquiry URLs are in urls_inquiries.py (namespace inquiries); views in ui_views.py; API on InquiryViewSet (views.py:2890).

Action URL name View (file:line) Permission Effect
Activate inquiry_activate (<pk>/activate/) ui_views.py:3179 PX/Hosp-Admin/PX-Mgmt/PX-Employee Assigns to self; open→in_progress + activated_at
Assign inquiry_assign (<pk>/assign/) ui_views.py:3252 PX/Hosp-Admin/Dept-Manager-of-this-dept Assign to user; auto-reopens resolved/closed → in_progress
Change status inquiry_change_status (<pk>/change-status/) ui_views.py:3330 PX/Hosp-Admin/PX-Mgmt/PX-Employee Arbitrary status; resolved blocked without response; only way to set closed
Reopen inquiry_reopen (<pk>/reopen/) ui_views.py:3388 PX/Hosp-Admin/Dept-Manager Only from resolved/closed; → in_progress
Add note inquiry_add_note (<pk>/add-note/) ui_views.py:3439 @login_required (no role gate) Timeline note
Respond (PX) inquiry_respond (<pk>/respond/) ui_views.py:3459 PX/Hosp-Admin/Assignee/Champion-of-(dept/outgoing_dept) Writes inquiry.response, sets responded_at/_by, response_sent_at, → resolved; sends SMS+email to inquirer
Send to department inquiry_transfer_to_department (<pk>/transfer-to-department/) ui_views.py:3578 PX/Hosp-Admin/Dept-Manager/PX-Mgmt/PX-Employee; rejects open Full send + token (§14)
Send-to (AJAX) inquiry_send_to (<pk>/send-to/) ui_views.py:3818 PX/Hosp-Admin/Dept-Manager/PX-Mgmt/PX-Employee; rejects open Unified send to person OR department (§14)
Dept response (logged-in) inquiry_department_response (<pk>/department-response/) ui_views.py:4003 PX/Hosp-Admin/Champion-of-(dept/outgoing_dept) Champion submits department_response_en/ar + AI summary
Send dept-response reminder inquiry_send_dept_response_reminder ui_views.py:4115 PX/Hosp-Admin/PX-Mgmt/PX-Employee Manual reminder email to champion
Send to staff (token explanation) inquiry_send_to_staff (<pk>/send-to-staff/) ui_views.py:2901 PX/Hosp-Admin/PX-Mgmt/PX-Employee Token InquiryExplanation request to a staff member (§8)
Escalate inquiry_escalate (<pk>/escalate/) ui_views.py:3728 PX/Hosp-Admin/PX-Mgmt/PX-Employee; blocks closed/cancelled Stamps escalated_at, emails target
Update contact stage inquiry_update_contact_stage (<pk>/update-contact/) ui_views.py:4227 PX/Hosp-Admin/Assignee Updates 3-stage contact timeline + timeline_sla
Edit inquiry_edit (<pk>/edit/) ui_views.py:3102 PX/Hosp-Admin/PX-Mgmt/PX-Employee; blocks closed Edit fields
Export incoming/outgoing inquiry_export_* ui_views.py:4186,4206 @login_required (RBAC inside) Excel reports by is_outgoing
Public submit public_inquiry_submit ui_views.py:4707 None Public creation
Public track public_inquiry_track ui_views.py:4843 None Public status lookup by reference
Token response (dept) inquiry_respond_with_token (<pk>/respond/<token>/) views.py:5141 None (token) Champion submits dept response via token (§14)
Token explanation (staff) inquiry_explanation_form (<id>/explain/<token>/) views.py:5077 None (token) Staff submits InquiryExplanation
Restore inquiry_restore ui_views.py:7227 PX/Hosp-Admin/PX-Mgmt/PX-Employee Restores soft-deleted

API (InquiryViewSet): respond (views.py:2962), generate_ai_response (views.py:2980 — bilingual AI reply draft), reanalyze_ai (views.py:3103), plus default ModelViewSet CRUD.

6. Decision Points

  • Activation gate — every send endpoint rejects status == "open" (ui_views.py:3594, 3841). Matches docs/workflows.md:7-9.
  • Resolve gate — response must be non-empty (ui_views.py:3356, 3482; API views.py:2968).
  • Reopen gate — only from resolved/closed (ui_views.py:3402); reassignment also reopens (ui_views.py:3282).
  • Escalate gate — blocked if closed/cancelled (ui_views.py:3744).
  • Department must have champion/manager to be a transfer target (ui_views.py:3610, 3916).
  • Need-more-info — no dedicated "request info" action; analogues are token InquiryExplanation, inquiry_add_note, and the 3-stage contact tracking (contacted_no_response).
  • PX acceptance of dept response — ⚠ NO LONGER EXISTS (docs/workflows.md:35 is stale). See §14.
  • Patient confirmation — does not exist. Patient can only view status via public track. Reopen is staff-only.

7. Assignment Flow

  • Initial owner — none. assigned_to/assigned_at null on creation. created_by stamped (models.py:1728).
  • Self-activation — inquiry_activate sets assigned_to = current_user, assigned_at, (if open) status=in_progress + activated_at (ui_views.py:3202).
  • Directed assignment — inquiry_assign (ui_views.py:3268); emails assignee; notifies department.
  • Reassignment — same path; records old assignee; reopens if needed (ui_views.py:3275).
  • Transfer / outgoing fields — two parallel concepts: transferred_to_department (models.py:1824) and outgoing_department (models.py:1834), both set together by transfer/send-to (ui_views.py:3638, 3923). transferred_at/transferred_by/transfer_count track the event.
  • Owner cascade — Inquiry.get_owner() (models.py:2037): section(champion→supervisor→deputy_supervisor) → department(champion→deputy_manager→supervisor→deputy_supervisor→manager_2nd→manager_3rd).
  • Escalation — inquiry_escalate: does NOT reassign; stamps escalated_at + emails target.
  • Final owner — whoever performs inquiry_respond (sets responded_by) / change_status to resolved/closed.

8. Investigation Process

InquiryExplanation (models.py:2380): "Staff/recipient response to an inquiry via token-based link. Mirrors ComplaintExplanation pattern." Fields: inquiry, staff, explanation, token (unique), is_used, submitted_via, SLA fields. InquiryExplanationAttachment (models.py:2460).

No investigation sub-flow (no Q&A loop). The mechanism is:

  1. PX/Admin triggers inquiry_send_to_staff (ui_views.py:2901): creates an InquiryExplanation with a fresh token; emails the staff a link /inquiries/<id>/explain/<token>/.
  2. Staff opens inquiry_explanation_form (views.py:5077), submits text + attachments; is_used flipped, responded_at stamped.
  3. The explanation is stored but not automatically promoted into department_response_en — it's an advisory collection mechanism, distinct from the primary department-response path (§14).

⚠ Runtime bug: inquiry_send_to_staff calls InquirySLAConfig.get_active_config() (ui_views.py:2938) and reads sla_config.dept_response_sla_hours (ui_views.py:2939). Neither exists — InquirySLAConfig has no get_active_config classmethod (models.py:1432) and the field is dept_response_hours, not dept_response_sla_hours. This code path raises AttributeError.

9. Communication Flow

Event Where
Acknowledgement/receipt ⚠ none automatic (no creation signal); only staff notified via notify_staff_new_item
Progress update timeline notes (inquiry_add_note); contact stages (inquiry_update_contact_stage)
Need-more-info token explanation request to staff (inquiry_send_to_staff); inquirer "no response" = contacted_no_response stage
Department response inquiry_department_response notifies inquirer SMS+email (ui_views.py:4075); token path inquiry_respond_with_token (views.py:5195)
Response sent/closure inquiry_respond sends SMS+email to inquirer (ui_views.py:3512); in-app "resolved" notice to admins. No separate closure notification.
Public tracking public_inquiry_track (ui_views.py:4843) — friendly labels/progress + department_response_en/ar

Notification helpers (apps/notifications/settings_service.py): send_inquiry_department_assigned (:250), send_inquiry_assigned (:463), send_inquiry_resolved (:488), send_inquiry_reopened (:514).

10. Escalation Flow

Manual — inquiry_escalate (ui_views.py:3728): PX/Hosp-Admin/PX-Mgmt/PX-Employee; blocked if closed/cancelled; requires a valid active Staff; stamps escalated_at; does NOT change status/assignee; emails target (Hospital Admin/Dept Manager/role-holders, computed in inquiry_detail ui_views.py:2775).

Automatic (SLA breach) — InquirySLAConfig (models.py:1432): sla_hours, reminder timings, dept-response SLA fields. Celery beat:

  • check-overdue-inquiries → check_overdue_inquiries (tasks.py:2886) every 15 min: sets is_overdue/breached_at.
  • send-inquiry-sla-reminders → send_inquiry_sla_reminders (tasks.py:2915) every 15 min: emails assigned_to first + second reminders.

⚠ Department-response auto-escalation is DISABLED in code: check_overdue_inquiry_dept_responses (tasks.py:3126) flags dept_response_is_overdue but the auto-escalate branch unconditionally logs "Auto-escalation skipped ... (disabled)" and continues (tasks.py:3178), even though dept_response_auto_escalate_enabled defaults True (models.py:1487). So escalation is manual only.

11. Resolution Process

VERIFIED — docs/workflows.md:36-38 is correct: resolve requires a PX response.

  • inquiry_change_status: if new_status == "resolved" and not inquiry.response: reject (ui_views.py:3356).
  • inquiry_respond: rejects empty (ui_views.py:3482); writes inquiry.response + sets resolved (ui_views.py:3486); stamps response_sent_at + notifies inquirer (ui_views.py:3512).
  • API respond: same (views.py:2968).

Who can mark resolved: via inquiry_respond — PX/Hosp-Admin/assignee/Champion of department or outgoing_department (ui_views.py:3466); via change_status — PX/Hosp-Admin/PX-Mgmt/PX-Employee.

Approval required? No. Patient confirmation? Not required/captured. save() stamps resolved_at/resolved_by from _acting_user.

⚠ Gap: inquiry_respond clears response_en/response_ar and writes only the aggregate response field (ui_views.py:3487). The bilingual columns exist but this path doesn't populate them.

12. Closure Process

  • No dedicated close view. Closure is via inquiry_change_status with status="closed" (ui_views.py:3330).
  • Permission: PX/Hosp-Admin/PX-Mgmt/PX-Employee.
  • save() stamps closed_at/closed_by on entry (models.py:1997).
  • Closed inquiries cannot be edited (inquiry_edit guard, ui_views.py:3116).
  • Reopen — inquiry_reopen from resolved/closed → in_progress (ui_views.py:3388); inquiry_assign auto-reopens resolved/closed on reassignment (ui_views.py:3282).
  • Permanently completed? No permanent lock; a closed inquiry can always be reopened. Soft-deletion is separate, restorable.

13. Exception Flows

  • Duplicate — no duplicate-detection.
  • Withdrawn/Invalid — no withdrawn/invalid/cancelled status (those are Complaint statuses). cancelled is referenced defensively (models.py:2167, ui_views.py:3744) but is never a valid Inquiry status.
  • Wrong department — handled by re-transfer (transfer_count increments); no explicit bounce-back.
  • Missing info — inquiry_add_note / token InquiryExplanation; no "pending info" status.
  • No patient response — 3-stage contact timeline (contacted_nr_at, models.py:1886) + contact_status="contacted_no_response". No auto-close.
  • Transferred — transfer_count tracks; both dept fields set; sent_to_department/sent_to_department_at cross-module signal set.
  • Merged — no merge feature.
  • Reopened — see §12.

14. Department-Response Sub-Flow (CRITICAL)

14.1 Activation gate

inquiry_transfer_to_department (ui_views.py:3594) and inquiry_send_to (ui_views.py:3841) both reject status == "open" with "Activate this inquiry before sending it to a department." So open → in_progress (via inquiry_activate) is mandatory first.

14.2 How an inquiry is sent to a department

(A) inquiry_transfer_to_department (ui_views.py:3578) — the richer path:

  • Validates: permission, not-open, department_id, department active with champion/manager, valid contact person.
  • Sets: outgoing_department, transferred_to_department = department, transferred_at, transferred_by, transfer_count += 1, sent_to_department = True, sent_to_department_at.
  • Computes dept-response SLA: dept_response_sla_due_at = now + dept_response_hours; resets overdue/reminder/escalation flags.
  • Generates a one-time response_token = secrets.token_urlsafe(32), sets response_token + response_token_sent_at.
  • Builds token link https://{domain}/inquiries/{pk}/respond/{token}/; emails the contact person with deadline; calls send_inquiry_department_assigned.
  • Writes InquiryUpdate type transferred_to_department.

(B) inquiry_send_to (ui_views.py:3818) — unified AJAX (person OR department):

  • Department branch auto-targets champion+manager via get_champion_and_manager.
  • Sets transfer fields + resets dept-response SLA.
  • ⚠ Inconsistency: sets sent_to_department = True only if inquiry.department_id == department.pk (ui_views.py:3929), unlike path (A) which always sets it. Sending to a different department via this endpoint does not set the cross-module "sent" signal.
  • Notifies champion+manager by email+SMS; does NOT generate a response_token (no token link) — relies on in-app notification only.

14.3 Who receives it

The department's champion and/or manager (get_champion_and_manager). In path (A) the chosen contact_person (validated by department.is_valid_contact_person).

14.4 Champion's response submission (two ways)

(i) Token-response path — /inquiries/<pk>/respond/<token>/ → inquiry_respond_with_token (views.py:5141), no auth:

  • Validates response_token and not None; rejects if response_token_used.
  • Accepts response_en/response_ar (at least one required).
  • Writes department_response_en/ar, department_responded_at, clears dept_response_is_overdue, response_token_used = True.
  • Generates AI summary into department_response_summary_en/ar.
  • Notifies the inquirer SMS+email with public track URL.
  • ⚠ Dead code: inquiry.dept_response_acceptance_status = "pending" at views.py:5173 — this field was removed (migration 0039); silently dropped on save.

(ii) Authenticated champion response — /inquiries/<pk>/department-response/ → inquiry_department_response (ui_views.py:4003):

  • Permission: PX/Hosp-Admin/Champion of department or outgoing_department.
  • Writes department_response_en/ar, department_responded_at/_by, clears overdue; AI summary; notifies inquirer.
  • Does NOT set any acceptance status (field doesn't exist).

14.5 One-level review — accept/reject

⚠ STALE-DOC — this loop no longer exists in the data model. docs/workflows.md:34-35 and the field-name table reference dept_response_acceptance_status (pending/acceptable/not_acceptable). Migration 0001_initial.py:440 defined it; migration 0039 removed dept_response_acceptance_status, dept_response_acceptance_notes, dept_response_accepted_at, dept_response_accepted_by.

Consequences:

  • No PX "accept"/"reject" view for Inquiry dept responses (no URL/function). The only acceptance_status setters are for Complaint.
  • The Inquiry model has no column to hold an accept/reject decision.
  • The only surviving reference is the dead assignment at views.py:5173.

So today the actual flow is: champion submits department_response_en/ar → it's simply available to PX (shown in detail, fed into generate_ai_response prompt) → PX writes their own patient-facing inquiry.response via inquiry_respond → status="resolved". No explicit accept/reject decision and no reject-loop. The champion's response is never "cleared" automatically; nothing returns a rejected response to the champion.

14.6 Reject loop

⚠ Not implemented for Inquiry (no backing field, no endpoint). docs/workflows.md:16-17 describes the loop generally; for Inquiry it's aspirational/dead.

Field-Name Reference (dept-response concept map)

Concept Field(s) on Inquiry File:line
Target dept transferred_to_department / outgoing_department models.py:1824, 1834
Sent flag sent_to_department + sent_to_department_at models.py:1810, 1813
Transfer meta transferred_at, transferred_by, transfer_count models.py:1807, 1816, 1832
Response text department_response_en/ar + AI department_response_summary_en/ar models.py:1843-1846
Response at/by department_responded_at, department_responded_by models.py:1847-1854
Acceptance (REMOVED — migration 0039) was dept_response_acceptance_status
Token response_token, response_token_used, response_token_sent_at models.py:1857-1862
Dept SLA dept_response_sla_due_at, dept_response_is_overdue, _reminder_sent_at, _escalated_at models.py:1865-1881
PX reply response, response_en/ar, response_sent_at, responded_at/_by models.py:1784-1791

15. End-to-End Example

Patient submits inquiry via public form
  ↓ (ui_views.py:4707)  → status=open, ref INQ-202607-0001, due_at set,
                          AI analysis + admin notify dispatched
                          [⚠ inquirer NOT auto-acknowledged]
PX staff activates
  ↓ (ui_views.py:3179)  → status=in_progress, activated_at, assigned_to=self
PX transfers to Department X
  ↓ (ui_views.py:3578)  → transferred_to_department=X, sent_to_department=True,
                          response_token generated, token link emailed to champion,
                          dept_response_sla_due_at set
                          [DECISION: champion responds via token or logged-in]
Champion submits dept response via token link
  ↓ (views.py:5141)  → department_response_en set, department_responded_at,
                       response_token_used=True, AI summary generated,
                       inquirer notified SMS+email
                       [⚠ NO PX accept/reject — field removed]
                       [DECISION POINT: PX must write patient-facing response]
PX writes inquiry.response (generate_ai_response optional)
  ↓ (ui_views.py:3459)  → response set, responded_at/by, response_sent_at,
                          status=resolved, inquirer notified SMS+email,
                          admins notified
PX closes
  ↓ (ui_views.py:3330)  → status=closed, closed_at/by
                          [PERMANENT unless reopened → in_progress]

Appendix — Flagged gaps vs docs/workflows.md

  1. dept_response_acceptance_status removed (0039); the "PX accepts/rejects" loop is no longer backed by code. Dead assignment at views.py:5173.
  2. No clean()/CheckConstraint on Inquiry; status enforced only ad-hoc in views; arbitrary strings persistable via change-status.
  3. Bug in inquiry_send_to_staff (ui_views.py:2938) — calls nonexistent InquirySLAConfig.get_active_config() / dept_response_sla_hours.
  4. Auto dept-response escalation disabled (tasks.py:3178).
  5. Inconsistent sent_to_department between transfer (always sets) and send-to (only when target == primary dept).
  6. Invalid status choices exposed in detail view (contacted/contacted_no_response).
  7. No creation acknowledgement to inquirer.
  8. inquiry_respond clears response_en/ar, fills only aggregate response.
  9. is_straightforward field defined/serialized but never used in any decision.
  10. cancelled/partially_resolved referenced defensively but never valid Inquiry statuses.