[19.0] [FIX] partner_stage: rename res_partner.state -> stage_state

[bosd]

Summary

The stored related field res.partner.state (added in partner_stage/models/res_partner.py) collides with account_move.state in Odoo Enterprise's account_reports VAT report SQL.

account_reports.account_return._check_suite_common_vat_report issues:

SELECT ARRAY_AGG(move.id)
FROM account_move move
JOIN account_fiscal_position fpos ON fpos.id = move.fiscal_position_id
JOIN res_partner partner ON partner.id = move.commercial_partner_id
WHERE
    state = 'posted'
    AND move.company_id IN %(company_ids)s
    ...

The unqualified state = 'posted' matches both move.state and partner.state once partner_stage is installed, and Postgres raises:

psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous

This breaks the VAT closing checks on any deployment that combines partner_stage with Odoo Enterprise's account_reports.

Fix

Rename the field to stage_state — same store / related / readonly semantics, more descriptive name, no collision with downstream queries.

• models/res_partner.py: field renamed.
• migrations/19.0.1.2.0/pre-migrate.py: renames the Postgres column from state to stage_state for existing installations (idempotent guard against installations that already have stage_state from a fresh install or a re-run).
• init_hook.py: the post-install SQL writes to the new column name.
• Manifest bumped 19.0.1.1.0 → 19.0.1.2.0.

Test plan

• Fresh install: column is created as stage_state, init_hook populates default stage cleanly.
• Upgrade from 19.0.1.1.0: pre-migrate renames the existing state column to stage_state; data preserved.
• Re-run upgrade: pre-migrate is a no-op because stage_state already exists.
• Combined with Odoo Enterprise's account_reports: VAT report closing checks now run without an AmbiguousColumn error. (Verified by the maintainer on an FLC production database; PR-side CI does not have enterprise.)

Breaking change

The field is renamed. Any third-party that reads res.partner.state directly (rather than the canonical res.partner.stage_id.state) needs to follow the rename. A pre-migration could not be more clever than this without making assumptions about external consumers.

[OCA-git-bot]

Hi @dreispt,
some modules you are maintaining are being modified, check this out!

[BhaveshHeliconia]

Functional LGTM,
But last digit should be increased in manifest version for fix PRs

[dreispt]

to bump MAJOR

[bosd]

Addressed the review: bumped the manifest to a major version 19.0.2.0.0 (per @dreispt — a field rename res_partner.state → stage_state is a breaking change) and moved the migration to migrations/19.0.2.0.0/ to match. @dreispt @BhaveshHeliconia ready when you are 🙏

[bosd]

Heads-up on a small but important change in the latest push: I made the migration idempotent / self-healing instead of a plain rename. The simple RENAME state -> stage_state only heals a DB where the legacy column is the only one — if a database already has stage_state (reinstall, or the field rename landed first), a stray state column can linger alongside it and keep the VAT report ambiguous. The new migration covers all four cases (state-only → rename, both → backfill+drop legacy, stage_state-only → noop, neither → ORM creates it). Verified in production where exactly the both-columns case recurred. ruff/pre-commit green.

[BhaveshHeliconia]

LGTM!

[dreispt]

Good for me, please check the test build.

[bosd]

Pushed a test for the migration (tests/test_migration.py) covering all three reconciliation branches (state-only → rename, both → drop legacy, stage_state-only → noop) — the schema changes run inside the test transaction and roll back. This restores coverage (codecov/project) and re-triggers CI; the earlier red 'test with Odoo' was a flaked 'Initialize containers' (Docker/Postgres) step, not a test failure.