[19.0][FIX] stock_account: product.value and stock.valuation.layer have different semantics - #5881
Open
hbrunn wants to merge 84 commits into
Open
[19.0][FIX] stock_account: product.value and stock.valuation.layer have different semantics#5881hbrunn wants to merge 84 commits into
hbrunn wants to merge 84 commits into
Conversation
[19.0][MIG] auth_passkey_portal: nothing to do
[19.0][MIG] project_hr_skills: nothing to do
[19.0][MIG] hr_skills_event: nothing to do
…rvey [19.0][MIG] website_slides_survey
[19.0][OU-ADD] mail_plugin: Nothing to do
[19.0][OU-ADD] crm_mail_plugin: Nothing to do
[19.0][MIG] website_livechat
[19.0][MIG] website_sale_stock: nothing to do
[19.0][MIG] website_sale_slides: nothing to do
[19.0][OU-ADD] theme_default: Nothing to do
[19.0][OU-ADD] crm_sms: Nothing to do
…lrelay [19.0][OU-ADD] delivery_mondialrelay: Nothing to do
…list [19.0][MIG] website_sale_wishlist: nothing to do
…_forum [19.0][OU-ADD] website_slides_forum: Nothing to do
…ation on PostgreSQL 13
stock_move_value() in stock_account/19.0.1.1/post-migration.py builds an
UPDATE ... FROM (SELECT ... sum(value) value ...) aggregate subquery with
a bare-word column alias (no AS) immediately after the aggregate call.
PostgreSQL 13 rejects this as a syntax error:
ERROR: syntax error at or near "value"
LINE 5: move_id, sum(value) value
^
PostgreSQL 16 accepts the same statement, which is why this is easy to
miss when re-testing on a newer engine — it is PostgreSQL-version
dependent, not data-dependent. Any 18.0 -> 19.0 migration of a database
with stock_account installed, run against a PostgreSQL 13 backend, hits
this unconditionally partway through the post-migration step.
Fix: alias the aggregate column explicitly (agg_value) and reference the
aliased name in the outer UPDATE ... SET, instead of relying on the bare
column name colliding with the outer table's own value column.
Found and reproduced during a real 15.0 -> 19.0 OpenUpgrade migration
(PostgreSQL 13 source engine). Confirmed the exact failing statement
against a live PostgreSQL 13.23 database inside a BEGIN;...ROLLBACK; and
confirmed the patched statement runs clean against the same database.
…t-migration-value-alias [19.0][FIX] stock_account: fix syntax error in stock_move_value() post-migration on PostgreSQL 13
[19.0][OU-ADD] payment_paypal: Nothing to do
Doing it by ORM is not advised due to performance, but also because some business constraints can be triggered, like in this case `_check_can_approve`, provoking a crash in the migration. There's also a problem in executing it in post-migration instead of end-migration: if the extra modules changing `_get_invoice_in_payment_state` are not yet loaded, you won't get `in_payment` state, so the logic has been converted to SQL, and move to end-migration. TT61992
[19.0][OU-FIX] hr_expense: Compute expense state by SQL
In odoo/odoo@72fffca, Odoo has changed the preference of the routes to warehouse level, but on migrated DBs, there may be more than one warehouse, and the check is not set for all the warehouses right now. Although this can be done in migration scripts, it's safer to simply keep it as it was, because when you have both Buy/Manufacture, there will be a change of behavior, selecting by priority the incorrect route. TT61992
…ner_assign [MIG] website_crm_partner_assign
[19.0][OU-FIX] mrp/purchase_stock: Don't change routes configuration
hbrunn
force-pushed
the
19.0-stock_account-fix-product.value
branch
2 times, most recently
from
August 18, 2026 17:19
ad5ba2c to
86e52c4
Compare
hbrunn
marked this pull request as ready for review
August 18, 2026 17:21
Contributor
|
BTW, is this PR ready to review and merge? |
| """ | ||
| Set stock.move#value to sum of product.value#value for this move | ||
| """ | ||
| env.cr.execute( |
| Set stock.location#valuation_account_id from valuation_in_account_id and | ||
| valuation_out_account_id if they are the same | ||
| """ | ||
| env.cr.execute( |
| (=manual valuations) | ||
| """ | ||
| # simple case: the valuation layer has unit_cost set | ||
| openupgrade.logged_query( |
Contributor
There was a problem hiding this comment.
yeah, better env.cr.execute here, sorry
Member
Author
|
I forgot some details like lifting constraints on the svl table and linking product_value records to the svl they come from, but by and large, that's what I think should happen |
Contributor
|
@hbrunn please, rebase. I made an error when force pushing to 19.0 (it's already amended) |
Member
Author
|
why is anyone allowed to force push in the first place? |
Contributor
|
I have just removed the force push permissions. |
Member
Author
|
https://github.com/OCA/OpenUpgrade/settings/branch_protection_rules/5942394 looked like this: 
I've changed that to 
|
Contributor
|
The option was marked in "Specify who can force push". I only removed the people there. So I suppose that when the list of people there is empty, github changes it to Everyone. |
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
12 participants
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.
this deals with the issue hinted at in #5855