[muhammadali124]

Problem

The hr_contract -> hr.version table rename produces hr.version rows
whose date_version column never existed on the old table. When the
new, required=True column gets added by the ORM schema sync, it is
left at its Python-declared default (fields.Date.today) for every
converted contract - the date the migration itself happened to run,
not anything derived from the contract's real data.

This matters because hr.version._compute_dates computes:

version.date_start = max(version.date_version, version.contract_date_start) \
    if version.contract_date_start \
    else version.date_version

Since date_version ends up pinned to the migration date for every
migrated employee, date_start resolves to the migration date too -
overriding the real, original contract start date entirely for this
purpose. hr.version._is_overlapping_period, used by
hr.payslip._get_employee_contracts() during compute_sheet(), then
silently excludes the contract for any payslip whose period is
earlier than the migration date:

def _is_overlapping_period(self, date_from, date_to):
    if not (self.contract_date_start and date_from and date_to):
        return False
    period_start = date_from or date.min
    period_end = date_to or date.max
    contract_end = self.date_end or date.max
    return period_start <= contract_end and self.date_start <= period_end

The practical effect: after an 18.0 -> 19.0 upgrade, calling
compute_sheet() on any pre-existing payslip dated before the
migration (regardless of its state - draft, verify, or done) silently
wipes its lines down to zero, with no error raised anywhere in the
chain. Confirmed this is not narrow - on a real migrated database with
~3,900 employees, essentially the entire hr_version table (3,932 of
3,934 rows) ended up with date_version pinned to the single date the
migration ran, and all ~3,100 pre-migration payslips (draft, verify,
and done combined) are affected.

Fix

Backfill date_version from contract_date_start for exactly the
rows affected (those where a real contract_date_start exists and
disagrees with date_version), mirroring the pattern this same
function already uses for the other branch - employees who had no
prior contract at all, whose newly-created hr.version row explicitly
gets date_version set from create_date a few lines below. This
fix brings the table-rename branch up to the same standard.

Testing

Reproduced and verified against a real database migrated through
16.0 -> 17.0 -> 18.0 -> 19.0 (OpenUpgrade, -u all). Before the fix:
recomputing a genuine pre-migration payslip via compute_sheet()
wipes its lines to zero. Applied the equivalent UPDATE manually
against the affected hr_version rows and confirmed the same
payslips then recompute with real salary-rule output again, and that
date_version values post-fix match each employee's real original
contract start date rather than the single migration-run date.

[hbrunn]

this fails if hr_contract wasn't installed, so please make it conditional on contract_date_start existing

[muhammadali124]

@hbrunn Thanks for pointing out! I have gated it behind a condition.

[pedrobaeza]

Please rebase and squash the commits into one.