Skip to content

Format the inspection models' display dates - #77

Open
roncodes wants to merge 2 commits into
mainfrom
fix/inspection-model-dates
Open

Format the inspection models' display dates#77
roncodes wants to merge 2 commits into
mainfrom
fix/inspection-model-dates

Conversation

@roncodes

Copy link
Copy Markdown
Member

Why

The inspection forms index in the console shows a full datetime instance string in its Created column instead of a date. Reported while testing the inspections feature against a live instance.

InspectionFormModel and InspectionSubmissionModel return the raw Date from their display-date getters:

get createdAt() {
    return this.created_at;
}

Every other model in this package formats them, and guards an unparseable value first — see vehicle.js and work-order.js:

@computed('created_at') get createdAt() {
    if (!isValidDate(this.created_at)) {
        return null;
    }

    return formatDate(this.created_at, 'yyyy-MM-dd HH:mm');
}

What changed

  • inspection-form: createdAt, updatedAt, publishedAt now format as yyyy-MM-dd HH:mm, matching the rest of the package.
  • inspection-submission: the same for createdAt, updatedAt, submittedAt, resolvedAt. The submissions index binds a column straight to submittedAt.
  • inspection-form: the frequency attribute is removed. Nothing schedules an inspection from it. It is being dropped from the FleetOps API resource, report schema and console in Add the driver-facing inspections API, and cover the inspection platform (#267 rebased) fleetops#319, so leaving the attribute here would only keep a dead field in the store.

The underscored attributes (created_at, published_at, …) are untouched, so anything that needs a real Date — the details panels use format-date-fns on them directly — is unaffected.

Companion

The inspection form and submission models handed out `createdAt` and its
siblings as the raw `Date` from the attribute. A table column bound to
`createdAt` therefore rendered a full datetime instance string instead of
a date, which is what the inspection forms index shows today.

Every other model in this package formats these getters, guarding an
unparseable value with `isValidDate` first, so do the same here.

The form model also carried a `frequency` attribute. Nothing schedules an
inspection from it, and FleetOps has dropped it from the API resource and
the console, so it is removed here too.
roncodes added a commit to fleetbase/fleetops that referenced this pull request Sep 10, 2026
Five things reported while testing inspection forms in the console.

Publish stayed in the header after a form was published, so the only
thing pressing it could do was report that the form was already
published. It now appears only while the form can be published, and as
`type="success"`. Generate Link moves the other way: it needs a
published form, so it appears at the same moment Publish leaves.

A field's machine name came from `dasherize`, which rewrites spaces and
underscores and leaves everything else alone — "Sidewall condition,
offside rear" became `sidewall-condition,-offside-rear`. The name is an
identifier: it travels as an item result's `item_key` and is what a
report groups on. It is now a real slug, with anything that is not a
letter or a digit acting as a separator.

`frequency` is gone. It was inherited metadata: a column, an attribute
and a filter that nothing scheduled an inspection from. It is removed
from the v1 resource, the model's fillable and filter params, the
report schema, the index column and query param, the details panel and
the create defaults. The database column is deliberately left in place
— the create migration has already run on live instances, and a dead
nullable column is cheaper than editing a migration mid-test. A later
migration can drop it.

Type rendered through `smart-humanize`, so a form of type `dvir` read
"Dvir". Option lists already carry the labels, so this adds a table cell
that reads them: `table/cell/fleet-ops-option` takes the list name from
the column's `optionsKey` and falls back to humanizing anything with no
matching option, so a retired value is still legible. The index Type
column and the details panel's type and status now use it.

The Created column's own bug is in fleetops-data, where the model hands
out a raw `Date` — fleetbase/fleetops-data#77 fixes that.
The inspection form and submission tests still asserted that the camelCase
date getters return the raw Date, so they failed once the getters began
formatting it, and the null branch of each isValidDate guard was never run,
which held coverage below the 100% gate.

Assert each getter through assertDateGetters, like the other models: the
yyyy-MM-dd HH:mm rendering of a real date, and null for null, undefined and
an unparseable Date. Also assert that the form no longer declares frequency.
@codecov

codecov Bot commented Sep 11, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (7831acc) to head (cf162ce).

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #77   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          114       114           
  Lines         2899      2913   +14     
  Branches       687       694    +7     
=========================================
+ Hits          2899      2913   +14     
Flag Coverage Δ
fleetops-data 100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
addon/models/inspection-form.js 100.00% <100.00%> (ø)
addon/models/inspection-submission.js 100.00% <100.00%> (ø)

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7831acc...cf162ce. Read the comment docs.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant