Diagnosis & Approval

Diagnosis & Approval

After a repair is reported, it moves through diagnosis, optional approval, and quality checking before being marked as complete. This article covers the diagnosis phase, the approval workflow, quality checks, and repair completion.

Diagnosis Phase

When a repair is in reported status, clicking “Diagnose Issue” moves it to diagnosed. During diagnosis, the technician records:

• Root Cause (root_cause) — Free-text description of the underlying issue
• Failure Type (failure_type) — Classification of what failed
• Severity Assessment (severity) — Updated if the initial report was inaccurate

The system records diagnosed_at (timestamp) and diagnosed_by (the authenticated user) automatically.

7 Failure Types

Value	Label	Description
mechanical	Mechanical	Physical component failure, broken parts, misalignment
electrical	Electrical	Wiring, power supply, circuit board, or connector fault
software	Software	Firmware bug, configuration error, or software crash
wear_and_tear	Wear and Tear	Normal degradation from regular use over time
user_error	User Error	Damage caused by incorrect operation or handling
environmental	Environmental	Water damage, heat exposure, dust ingress, or impact
unknown	Unknown	Root cause could not be determined

4 Severity Levels

Severity	Meaning	Equipment Impact
Minor	Cosmetic damage only	No stock change; equipment remains available
Moderate	Reduced functionality	At user discretion via equipment_usable_during_repair
Major	Equipment unusable	Automatically removed from available stock
Critical	Safety hazard	Immediately removed from stock; flagged as safety risk

Approval Workflow

From the diagnosed status, a repair can optionally move to awaiting_approval. The “Request Approval” button appears when the estimated_cost exceeds £500. A manager or CoreAdmin must then approve or reject the repair.

Approve:

• Endpoint: POST /repairs/{id}/approve
• Moves status from awaiting_approval to in_repair
• Records approved_by (user ID) and approved_at (timestamp)
• Sets repair_started_at to the current time
• Triggers equipment availability adjustment

Reject:

• Endpoint: POST /repairs/{id}/reject
• Moves status back to diagnosed for re-assessment
• Requires a rejection_reason (max 500 characters)
• Records rejected_by (user ID) and rejected_at (timestamp)

Quality Check Phase

When a repair reaches testing status, a quality check must be performed before the repair can be completed.

• Endpoint: POST /repairs/{id}/quality-check
• Parameters: passed (boolean, required), notes (string, optional, max 1000 characters)

Pass (passed = true):

• Status moves to completed
• Records quality_check_passed = true
• Records quality_checked_by (user ID) and quality_checked_at (timestamp)
• Saves quality_check_notes
• Equipment availability is restored

Fail (passed = false):

• Status returns to in_repair for further work
• Records quality_check_passed = false with the same timestamp and user fields
• Saves quality_check_notes describing the failure

Completing a Repair

A repair can reach completed status either by passing the quality check or by transitioning directly from in_repair. Upon completion, the following fields are recorded:

• resolution_notes — Description of how the issue was resolved
• repair_completed_at — Timestamp of completion
• follow_up_required — Boolean flag for post-repair monitoring
• follow_up_date — Scheduled date for the follow-up check (if required)

Configurable Settings

The repair approval and completion behaviour can be customised in Settings → Repairs:

• require_approval_for_completion — When enabled, all repairs must pass through the awaiting_approval stage before work can begin, regardless of estimated cost
• repair_number_prefix — Customise the prefix for repair reference numbers (default: RPR-)
• default_priority — Set the default priority level for new repairs

Cancellation

A repair can be cancelled from any non-terminal status via POST /repairs/{id}/cancel. This requires a cancellation_reason (max 500 characters) and records cancelled_by and cancelled_at. If the repair was in in_repair status, equipment availability is automatically restored.