Repository navigation
Conversation
…ng payments account.payment at 18.0 turns journal_id and company_id into its own stored required fields (in <=17.0 they were delegated to the move). The existing fill only set journal_id when the move journal is bank/cash/credit, and never set company_id at all, leaving legacy payments with NULLs in required columns: the SET NOT NULL of both columns fails at load, and the lazy ORM compute of company_id falls back to self.env.company on first edit, silently assigning the editing user company. Both values are fully derivable from the payment move: fill company_id for every payment, and fall back to the move journal for payments whose move lives outside bank/cash/credit journals, so historical rows keep their real journal and both NOT NULL constraints can install.
OCA/OpenUpgrade d95d630 now adds the account_payment.company_id column and fills it from the move in the same UPDATE. Merged with this branch, the UPDATE assigns company_id twice, which PostgreSQL rejects (multiple assignments to same column), and _new_columns lists the column twice. Keep only what upstream still lacks: the journal_id fallback for payments whose move sits outside bank, cash and credit journals.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
At 18.0
account.paymentstops delegating to its move (_inheritsdropped), andjournal_id/company_idbecome the payment's own stored required fields (bothcompute=..., store=True, required=True).company_idis filled from the move upstream since d95d630 («[OU-FIX] account: fill account.payment company_id from its move»). This PR covers the other field.The current
fill_account_payment()setsjournal_idfrom the move only when the move's journal is of typebank/cash/credit. Payments whose move lives in any other journal type (e.g.general, common for netting/compensation flows) are left withjournal_id = NULL. The NULLs then blockSET NOT NULLonjournal_idat load, so the required column ends up without its NOT NULL constraint.The journal is fully derivable from the payment's move (
move_idis never NULL for legacy payments). This patch falls back to the move's journal for payments whose move sits outside bank/cash/credit journals, so historical rows keep their true journal andSET NOT NULLsucceeds.The first commit also filled
company_id. The second drops that half, now that upstream does it: merged with upstream, the UPDATE would assigncompany_idtwice, which PostgreSQL rejects.