Custom field persistence fixes and order reporting schema

[roncodes]

Summary

Custom field values were never persisted for fuel reports or service areas. The upload landed and the record saved, but the custom_field_values rows were silently dropped.

Ember Data's REST serializer sends a record under a camelCase root (fuelReport, serviceArea). The base controller's payload reader accepts both spellings, so ordinary attributes saved fine, but these two afterSave hooks read $request->array('fuel_report.custom_field_values') / 'service_area.custom_field_values' from the raw request, which was always empty. Single-word resources (driver, vehicle, order, …) were unaffected because their root spells the same either way.

Change

Both hooks now read the values from the payload the base controller already extracted, which the after hook receives as its third argument. The root key's spelling no longer matters.

Context

Found while testing the ember-ui signature pad custom field on a fuel report (ember-ui feature/code-coverage-campaign). This branch carries the fleetops side of that testing round.

Verification

• php -l passes on both controllers inside the API container.
• Manual: sign a fuel report custom field, press Done, save, and confirm a row appears in custom_field_values and view mode shows the signature.

---

Order reporting schema

This branch also reworks the fleet-ops report schema (server/src/Support/Reporting/FleetOpsReportSchema.php) so the report builder can answer basic order questions such as "which products sold the most this month?" and "what did orders total this month?". It needs fleetbase/core-api#269.

Orders

• Identifiers: the order's ID and Internal ID are now selectable. Before, core-api hid every *_id column as a foreign key, so the ID never appeared.
• Order columns added:
  • customer and facilitator kind;
  • dispatched and started flags;
  • time window;
  • ad hoc distance, POD method, route optimized, priority and notes.
• Relationships added:
  • Tracking: tracking number, region and latest tracking status;
  • Order Config, Customer Vendor, Created By, Purchase Rate → Service Quote, and Payload Return.
• Payload: now has its own columns, and exposes its items (payload.entities) with name, SKU, price, dimensions, metadata and destination. Selecting an item column gives one row per item; group by an item column to summarise per product.
• Summary columns:
  • Total/Completed/Canceled Orders are distinct counts, so they stay correct when item rows are selected;
  • distance and duration totals/averages;
  • transaction amount sum/average, which now sum transaction.amount (they summed a column that doesn't exist on orders).
• Labels:
  • a table's own columns drop the table name ("Order ID" → "ID", "Order Type" → "Type");
  • distance and duration are labelled in meters and seconds, which is how they're stored;
  • money columns are marked "(minor units)".
• No meta assumptions: meta has no fixed shape, so no column assumes a key in it. meta stays selectable as raw JSON on orders and items, and reports read keys from it with computed columns, for example CAST(JSON_UNQUOTE(JSON_EXTRACT(payload.entities.meta, '$.quantity')) AS DECIMAL(15,2)).

Other tables

The old schema referenced 13 columns or join keys that don't exist in the database:

• Drivers: declared name/email/phone and a current_vehicle_uuid join. These now come from the user and vehicle relationships.
• Vehicles: joined drivers on a non-existent current_driver_uuid.
• Fuel Reports: declared cost, odometer_reading and report_date. It now uses amount, odometer, metric_unit and created_at.

Every table, and the item join, now leaves soft-deleted rows out.

Compatibility

CI installs core-api 1.6.55 from composer.lock. The schema still registers there, because softDeletes() is only called when the installed core-api supports it. The schema tests pass against both 1.6.55 and the core-api branch.

Verification

• Every one of the 338 declared columns and join keys exists in the dev MySQL schema. The old schema had 13 that didn't.
• Against 76 real storefront orders on MySQL in strict mode, these return correct results through the API:
  • top products (grouping by item name and summing a computed quantity from item meta);
  • monthly totals;
  • an order list with ID, tracking number and items.
• ReportSchemaContractsTest/ProviderContractsTest pass, the schema is at 100% line coverage, and lint is clean.