[dnplkndll]

pre-migration.py

A service log's date becomes date_from, and nothing says so.

20.0 gives a service record a span instead of a point: date is dropped,
date_from and date_to are added, and a CHECK enforces the order::

CHECK((date_to IS NULL) OR (date_from IS NOT NULL AND date_to >= date_from))

The analysis reports a DEL and two NEWs, which reads as three unrelated
changes. The field definitions say otherwise -- 20.0's date_from carries
19.0's date help text unchanged, "Date when the cost has been
executed", and the same default=fields.Date.context_today:

19.0  date      = fields.Date(help='Date when the cost has been executed', ...)
20.0  date_from = fields.Date(string='Start of Service',
                              help='Date when the cost has been executed', ...)

and 20.0's own _get_odometer-adjacent code passes date_from wherever it
needs the service's date.

Because date_from carries that default, nothing about the upgrade looks
wrong without this: the column is created, every existing row is filled with
the day the upgrade ran, and every service in the vehicle's history
silently moves to today. The seed's six service logs hold six different
dates; all six come out identical.

Renaming in pre-migration carries the values and leaves date_to null,
which the CHECK allows.

tests

• openupgrade_scripts/scripts/fleet/tests/test_fleet_migration.py

---

CI: red until #118 lands

The test job fails on duplicate key value violates unique constraint "res_country_state_name_code_uniq" (Ladakh / Odisha). Not this branch:
base's pre-migration, which renames those two external ids, lives in #118 and
is not on 20.0 yet, so every branch cut from 20.0 alone hits it. Per the
fork's model the per-PR check is the lean one; the real migration gate is the
integration branch (#120), where all of this runs green over the full
585-module seed.

AI-assisted (Claude Code); every change reviewed, tested, and owned by the author.