# Ogun State Asset Management Remediation Plan

Source audit: `PRODUCTION_AUDIT_REPORT.md`  
Current production readiness score: 4/10  
Target production readiness score before launch: 8/10 or higher  
Launch recommendation until remediation is complete: No-Go

## A. Remediation Strategy

The remediation should be handled in phases, not as one large refactor. The first priority is to remove security and accountability risks that could expose or corrupt MDA asset data. The second priority is to restore engineering confidence through tests and CI. The third priority is to add public-sector asset lifecycle controls: transfer, maintenance, disposal, and verification.

The recommended sequencing is:

1. Security and access-control fixes.
2. Test-suite repair and regression coverage.
3. Audit logging and accountability.
4. Data integrity and import/export hardening.
5. Core asset lifecycle modules.
6. Production operations, compliance, and launch hardening.

## B. Phase 1: Critical Security Fixes

Target timeline: 1-2 weeks  
Launch gate: Must complete before any production pilot

### 1. Fix Cross-MDA Authorization

**Issues addressed:**

- `AssetPolicy.php` compares `asset.ministry_id` to `user.id`.
- `AssetRequestPolicy.php` compares `request.ministry_id` to `user.id`.

**Actions:**

- Update both policies to compare against `auth()->user()->ministry_id`.
- Add tests for:
  - Ministry user can view own MDA assets.
  - Ministry user cannot view another MDA's assets by direct URL.
  - Ministry user can view own MDA requests.
  - Ministry user cannot view another MDA's requests by direct URL.

**Acceptance criteria:**

- Cross-MDA direct URL access returns `403` or `404`.
- Own-MDA access works.
- Tests cover both assets and requests.

### 2. Prevent Ministry Request Spoofing

**Issue addressed:**

- Ministry request creation accepts `ministry_id` from form input.

**Actions:**

- Remove `ministry_id` from ministry-submitted request validation.
- In `Ministry\AssetRequestController`, set `ministry_id` from `Auth::user()->ministry_id`.
- Reject request creation if the authenticated user has no assigned ministry.
- Add a tampering test where a ministry user submits another MDA's `ministry_id`.

**Acceptance criteria:**

- Submitted `ministry_id` is ignored or rejected.
- Created request always belongs to the authenticated user's MDA.
- Tampering test passes.

### 3. Disable Public Registration

**Issue addressed:**

- Public registration is open and automatically logs in new users.

**Actions:**

- Disable public registration routes in production.
- Replace open registration with admin-created users or invite-only onboarding.
- Ensure every new user is assigned:
  - Role.
  - Ministry/MDA where applicable.
  - Active/inactive status.

**Acceptance criteria:**

- `/register` is unavailable in production.
- New accounts can only be created by authorized admins or invite flow.
- Unauthorized users cannot self-onboard.

### 4. Enforce Inactive User Blocking

**Issue addressed:**

- `is_active` exists but login does not enforce it.

**Actions:**

- Update `LoginRequest` to reject inactive users.
- Add a clear login error message that does not leak sensitive status details.
- Add tests for inactive-user login failure.

**Acceptance criteria:**

- Inactive users cannot log in.
- Active users can log in normally.
- Login failure remains safe and non-enumerating.

## C. Phase 2: Test and CI Stabilization

Target timeline: 1 week  
Launch gate: Must complete before UAT expansion

### 1. Repair Pest Test Configuration

**Issue addressed:**

- `php artisan test` fails before running because the test case is applied twice.

**Actions:**

- Remove duplicate `uses(Tests\TestCase::class, RefreshDatabase::class)` declarations from feature tests where `tests/Pest.php` already applies them.
- Run the full test suite.
- Fix any revealed failures.

**Acceptance criteria:**

- `php artisan test` runs successfully.
- Test result is documented in the audit/remediation evidence.

### 2. Add Security Regression Tests

**Actions:**

- Add tests for:
  - Cross-MDA asset access.
  - Cross-MDA request access.
  - Tampered `ministry_id` request creation.
  - Inactive user login.
  - Public registration disabled in production mode.
  - Asset media deletion ownership.
  - Admin-only user management.
  - Supplier cannot access other supplier orders.
  - Approver cannot approve out of turn.

**Acceptance criteria:**

- Critical security behavior is covered by feature tests.
- CI must fail if any access boundary regresses.

### 3. Add CI Gate

**Actions:**

- Add CI workflow for:
  - Composer install.
  - PHP syntax/lint.
  - Laravel tests.
  - Frontend build if applicable.
  - Optional static analysis.

**Acceptance criteria:**

- Pull requests cannot be merged if tests fail.
- CI output is visible and repeatable.

## D. Phase 3: Audit Trail and Accountability

Target timeline: 2-3 weeks  
Launch gate: Must complete before real asset records are onboarded

### 1. Implement Database-Backed Activity Logs

**Issue addressed:**

- `ActivityLogService` writes to Laravel log files instead of persisting to the `activity_logs` table.

**Actions:**

- Update `ActivityLogService` to write to the database.
- Capture:
  - Actor user ID.
  - Actor role.
  - Ministry/MDA.
  - Action.
  - Subject type and ID.
  - Before/after values where applicable.
  - IP address.
  - User agent.
  - Timestamp.
  - Request/correlation ID.

**Acceptance criteria:**

- Sensitive actions are queryable from the database.
- Audit records cannot be edited through normal app UI.
- Audit logs exist for asset create/update/delete, request create/approve/reject/fulfill, procurement changes, user changes, imports, exports, login, and logout.

### 2. Add Asset History Timeline

**Actions:**

- Add an asset history view showing:
  - Creation.
  - Updates.
  - MDA changes.
  - Status changes.
  - Maintenance events.
  - Disposal events.
  - Verification events.
  - Uploaded evidence.

**Acceptance criteria:**

- Admins and authorized auditors can see the complete asset history.
- Ministry users can see history for their own MDA assets only.

### 3. Add Export and Report Audit Events

**Actions:**

- Log every PDF/Excel export.
- Include report type, filters, actor, timestamp, and record count.

**Acceptance criteria:**

- Sensitive reporting activity is auditable.
- Export abuse can be investigated.

## E. Phase 4: Data Integrity and File Hardening

Target timeline: 2 weeks

### 1. Fix Asset Import Mapping

**Issue addressed:**

- Import uses fields that do not match the asset schema/model.

**Actions:**

- Replace `category_id` with `asset_category_id`.
- Decide whether `location` and `serial_number` are core columns or custom attributes.
- Validate ministry code exists before import.
- Validate category exists or explicitly allow category creation.
- Validate asset tag uniqueness before insert.
- Produce row-level import errors.

**Acceptance criteria:**

- Import creates valid assets with correct category and MDA.
- Invalid rows are skipped with clear error output.
- Import tests cover success, duplicate tag, unknown ministry, invalid dates, and invalid amounts.

### 2. Harden File Uploads

**Actions:**

- Add `files` and `files.*` validation.
- Limit file types to approved images and documents.
- Limit file size and upload count.
- Store sensitive evidence outside public access where appropriate.
- Add media ownership checks before deletion.

**Acceptance criteria:**

- Invalid file types are rejected.
- Oversized files are rejected.
- Users cannot delete media outside the current asset.
- Evidence access respects MDA and role boundaries.

### 3. Fix Asset Update Validation

**Actions:**

- Split create and update requests.
- Make asset tag unique validation update-safe.
- Add missing validation rules:
  - `purchase_date <= today`.
  - `salvage_value <= purchase_cost`.
  - valid status enum.

**Acceptance criteria:**

- Existing assets can be edited without asset tag false failures.
- Invalid financial/depreciation data is rejected.

### 4. Fix Status Consistency

**Actions:**

- Remove `status_id` filtering where no such column exists.
- Replace `maintenance` string checks with `under_maintenance`.
- Prefer enum constants over raw strings.

**Acceptance criteria:**

- Dashboard counts and filters return accurate values.
- Status behavior is covered by tests.

## F. Phase 5: Core Asset Lifecycle Modules

Target timeline: 6-10 weeks  
Launch gate: Required for full public-sector production use

### 1. Asset Transfer Workflow

**Build:**

- Transfer request.
- Source MDA.
- Destination MDA.
- Current custodian.
- New custodian.
- Reason.
- Approval status.
- Supporting documents.
- Transfer history.

**Acceptance criteria:**

- Assets cannot be moved between MDAs without authorization.
- Transfer history is immutable and visible in asset timeline.
- Both source and destination changes are audited.

### 2. Maintenance Workflow

**Build:**

- Maintenance request.
- Maintenance officer/vendor assignment.
- Fault description.
- Estimated cost.
- Actual cost.
- Start date.
- Completion date.
- Status.
- Evidence upload.
- Maintenance history.

**Acceptance criteria:**

- Maintenance records are linked to assets.
- Costs feed into reporting.
- Assets under maintenance are visible in dashboard/reporting.

### 3. Disposal and Retirement Workflow

**Build:**

- Disposal request.
- Reason for disposal.
- Approval chain.
- Valuation/recovery amount where applicable.
- Supporting documents.
- Final disposal status.
- Lockdown rules for disposed assets.

**Acceptance criteria:**

- Disposed assets cannot be edited without privileged override.
- Disposal is auditable.
- Disposal reports are available by MDA, date, category, and reason.

### 4. Physical Verification and Audit Workflow

**Build:**

- Verification exercise.
- Assigned auditor/team.
- Asset scan/manual verification.
- Found/missing/damaged status.
- Evidence/photo upload.
- Reconciliation report.
- Exception list.

**Acceptance criteria:**

- Auditors can run verification exercises.
- Missing/damaged assets are reportable.
- Reconciliation reports are exportable and auditable.

### 5. Custodian Assignment

**Build:**

- Assign assets to staff/custodian.
- Track start/end dates.
- Record handover evidence.
- Show custodian history.

**Acceptance criteria:**

- Every assigned asset can show current and historical custodian.
- Custodian changes are audited.

## G. Phase 6: Performance, Compliance, and Production Operations

Target timeline: 3-5 weeks

### 1. Reporting and Export Scalability

**Actions:**

- Paginate report screens.
- Queue large PDF/Excel exports.
- Notify users when exports are ready.
- Add indexes for common filters.

**Acceptance criteria:**

- Large datasets do not exhaust memory.
- Export jobs are tracked and auditable.

### 2. Production Security Hardening

**Actions:**

- Enforce `APP_DEBUG=false`.
- Enforce HTTPS.
- Set secure cookies.
- Enable session encryption where appropriate.
- Configure trusted proxies.
- Add security headers at web server or middleware layer.
- Ensure `.env` is untracked and secrets are managed securely.

**Acceptance criteria:**

- Production config review passes.
- No debug stack traces are exposed.
- Cookies are secure and HTTP-only.

### 3. Backup, Restore, and Retention

**Actions:**

- Define backup schedule.
- Define restore procedure.
- Run restore drill.
- Define retention policy for:
  - Assets.
  - Requests.
  - Audit logs.
  - Uploaded evidence.
  - Soft-deleted records.

**Acceptance criteria:**

- Backup and restore process is documented and tested.
- Retention policy is approved by project stakeholders.

### 4. Privacy and NDPA Readiness

**Actions:**

- Minimize staff personal data.
- Restrict access to user/staff records.
- Add audit logs for access to sensitive records.
- Define document retention and deletion rules.
- Add privacy notice where relevant.

**Acceptance criteria:**

- Personal data handling is documented.
- Access to staff/user data follows least privilege.

## H. Suggested Delivery Roadmap

| Phase | Duration | Priority | Outcome |
| --- | --- | --- | --- |
| Phase 1: Critical security fixes | 1-2 weeks | P0 | Removes immediate access-control and onboarding risks |
| Phase 2: Tests and CI | 1 week | P0 | Restores engineering confidence |
| Phase 3: Audit trail | 2-3 weeks | P0/P1 | Establishes government accountability |
| Phase 4: Data/file hardening | 2 weeks | P1 | Improves import, upload, and reporting integrity |
| Phase 5: Lifecycle modules | 6-10 weeks | P1 | Makes the app a true asset management system |
| Phase 6: Production operations | 3-5 weeks | P1/P2 | Prepares for secure and scalable launch |

## I. Immediate Sprint Backlog

Recommended first sprint:

1. Fix `AssetPolicy` ministry ownership check.
2. Fix `AssetRequestPolicy` ministry ownership check.
3. Remove client-controlled `ministry_id` from ministry request creation.
4. Disable public registration in production.
5. Enforce `is_active` during login.
6. Repair Pest duplicate test binding.
7. Add cross-MDA direct URL tests.
8. Add tampered ministry request creation test.
9. Add inactive-user login test.
10. Add media deletion ownership test.

## J. Go/No-Go Criteria After Remediation

The app should remain No-Go until all of the following are true:

- Critical authorization bugs are fixed and tested.
- Public registration is disabled or invite-only.
- Inactive users cannot log in.
- Full test suite passes in CI.
- Audit logs are database-backed and cover sensitive actions.
- Uploads and imports are validated and tested.
- Transfer, maintenance, disposal, and verification workflows exist or the production scope explicitly excludes them.
- Reports scale beyond small demo datasets.
- Production environment is hardened.
- Backup and restore process is documented and tested.

## K. Target Production Readiness

After Phase 1 and Phase 2:

- Expected score: 5.5/10 to 6/10.
- Suitable for controlled UAT only.

After Phase 3 and Phase 4:

- Expected score: 6.5/10 to 7/10.
- Suitable for expanded pilot with non-critical or migrated test data.

After Phase 5 and Phase 6:

- Expected score: 8/10 or higher.
- Suitable for production launch, subject to final security review, UAT sign-off, and operational readiness approval.