[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.

[muhammadali124]

@pedrobaeza Just checking in, anything else needed from my side here? Happy to make further changes if useful.
I had rebased and squashed commits before the approval.