Daily updates from Odoo
Wednesday, September 24, 2025
211 changes
1 change
Resolved issues and error corrections
Customers who add items without choosing a pickup point will now have the checkout page's default pickup location properly applied. This prevents confusing checkout failures where a visible pickup location appeared selected but the order could not proceed to payment.
Original PR description
Description of the issue/feature this PR addresses: This commit fixes the issue where the pickup location does not get set even though it is present on the checkout page. This happens when the user…
Description of the issue/feature this PR addresses: This commit fixes the issue where the pickup location does not get set even though it is present on the checkout page. This happens when the user directly adds an item to cart without specifying the pick up location before adding to cart. This results in the location not being set but at the checkout page, the default pick up location appears as one of the warehouses given the way the default pickup location is set when loading the checkout page values. This makes the user think that the pickup location is set, but when they try to go to the pay page, an error is thrown saying the pick up location was not specified. This commit sets the pickup location data in such a case. [This commit] refactored the way in which the default location would be set on the checkout page but did not take into account the possbility that the customer might not select the pickup location when they are adding to cart, thus only rendering the value at the checkout page but not actually setting it. Refactored the test cases to avoid the redundancy in the setup process. Steps to reproduce on runbot: 1. Set the pick up in store as the default delivery method by updating the sequence 2. Go the shop on the website and add any item to cart which has stock in the specified pickup location, but don't select the pickup location here 3. Go to the cart and click checkout 4. The default pickup location will be set here 5. Click on Confirm 6. An error will appear saying the location was not set opw-4954187 [This commit]: https://github.com/odoo/odoo/commit/1d3942c75e59ac9538d112df43b4e39f2462fee4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227826
10 changes
Resolved issues and error corrections
Czech VAT return entries without a partner VAT number are now placed in section A5 regardless of invoice amount. Entries under special VAT regimes for travel services and margin schemes are also consistently reported in A5, helping businesses produce compliant Czech VAT filings.
Original PR description
Before this commit, the l10n_cz VAT return report classified entries in section A4 if their total amount exceeded 10,000 CZK, and in section A5 if the amount was 10,000 CZK or less. - In l10n_cz, create an invoice with a cz partner without vat, over 10000. - In tax return the entry will be in section A4. With this commit: - Entries with no partner VAT number are now always classified under A5, regardless of the total amount. - Entries using a special VAT regime (l10n_cz_scheme_code), corresponding to Section 89 – travel services and Section 90 – margin scheme) are also always classified under A5, regardless of the amount. opw-4953787 Forward-Port-Of: odoo/enterprise#92833
The website shop sitemap now avoids a memory-heavy loading behavior when handling very large product catalogs. This helps prevent server crashes caused by search engines or other crawlers requesting the sitemap, improving availability for online stores.
Original PR description
### Issue Server crashes with MemoryErrors when a database has a large product catalogs. ### Solution This commit disables the prefetcher to avoid MemoryErrors when generating the sitemap for large product catalogs as web crawlers would continously crash the server when requesting the sitemap. ### References opw-5001680 opw-4955333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228078 Forward-Port-Of: odoo/odoo#223054
This fixes a display issue in surveys where the progress indicator in the bottom-right corner only showed part of its text. Users filling out surveys will now see the full progress message, making completion status clearer.
Original PR description
Issue: When filling in a survey, the progress in the bottom right of the page does not show progress correctly. Only part of the text appears. Cause: Part of the text is not encompassed by any tag, so they are a loose node. Because this javascript code has migrated to the OWL framework these loose nodes are not rendered directly anymore. Solution: Encapsulate all the text in spans Task-5062196
This fix prevents an error when users open sale order line details with invoice lines from a product form dialog. It keeps the accounting-related view working reliably in customized Studio layouts where the usual search context is not available.
Original PR description
…in a dialog Steps to reproduce ================== Prerequisites: Having a product with an SO and an Invoice confirmed. Steps: - Open Product Variant Form - Open Studio - Add new O2M to SOL: Product (Sale Order Line) - Edit subview form - Add invoice_lines - Quit Studio - Click on SOL on Product view → It crashes => TypeError: can't access property "context", ctx.env.searchModel is undefined Cause of the issue ================== In form view dialogs, we don't have a search model Solution ======== We should use the context from the current record opw-4921186 Forward-Port-Of: odoo/enterprise#95259
Journal entry numbers can no longer be edited directly from the list view once entries are no longer in draft. This helps protect accounting records from accidental changes and keeps posted journal entries consistent.
Original PR description
**Issue** It was possible to edit the journal entry number in the list view even when the entry state was not 'draft'. **Steps to Reproduce** 1. Go to Accounting > Accounting > Journal Entries. 2. Select any journal entry. 3. Double-click on the Journal Number field and attempt to edit it. **Root Cause** The 'name' field in the list view did not have a readonly attribute, allowing inline editing regardless of the journal entry's state. Opw-5009421 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226064 Forward-Port-Of: odoo/odoo#224475
A styling file was renamed so it is correctly loaded in the website editor. This restores the intended behavior where section content is hidden while positioning a background image, making the editing experience clearer and less confusing.
Original PR description
__Current behavior before commit:__ [A PR] renamed the `.inside.*` files to `.edit.*`. However [the forward-port] of another PR introduced a new `.inside.*` file (i.e. `background_position_overlay.inside.scss`) but it was merged after the former one. This SCSS file is used to make the content of the section invisible when positioning its background image. But it is currently not included in the asset. __Description of the fix:__ Rename `background_position_overlay.inside.scss` to `background_position_overlay.edit.scss` to include it in `html_builder.assets_inside_builder_iframe` [A PR]: https://github.com/odoo/odoo/pull/224094 [the forward-port]: https://github.com/odoo/odoo/pull/226901 task-5111606
Customers can now change product options on website product pages even when some option combinations are excluded. The unavailable choices still look unavailable, but they no longer block shoppers from switching to another valid variant.
Original PR description
Versions -------- - saas-18.4+ Steps ----- 1. Create a product with attributes A & B; 2. for attribute A, create values A1 & A2; 3. for attribute B, create values B1 & B2; 4. add an attribute exclusion on A1 for B2; 5. add an attribute exclusion on A2 for B1; 6. open the product's website page. Issue ----- It's impossible to change attributes. Cause ----- Commit bbb2d98d9ab97 prevents selecting impossible combinations, as a consequence, it's impossible change product variants whose attributes exclude each other. Solution -------- Do not add the `disabled` attribute for excluded attributes, but maintaining the visual cues. Suggestion for future [IMP]: disable attributes as they were defined, without also disabling their inverse, e.g. if A1 is selected, disable B2, but don't disable A2 because B1 is selected. opw-5019677 opw-5050472 Forward-Port-Of: odoo/odoo#226612
This update adds test coverage to ensure quantity-based pricelist discounts continue to appear correctly on eCommerce product pages. It helps prevent regressions where shoppers might not see discounted prices when changing quantities.
Original PR description
Manual forward-port of the test added in f9c4001d7df3, to prevent regression of pricelist discounts price not getting displayed in eCommerce. opw-5037669
Sales orders now exclude section and note lines when calculating invoiced amounts. This keeps sales invoice totals aligned with accounting behavior and avoids display-only text affecting business figures.
Original PR description
When computing the invoiced amount for a SO, ignore the invoice's lines of `display_type` equal to `line_note` and `line_section` This matches the accounting features which always ignore such lines. **Current behavior before PR** Method `_get_sale_order_invoiced_amount` includes display lines. **Desired behavior after PR is merged** Method `_get_sale_order_invoiced_amount` ignores display lines. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228146
Code cleanup and technical improvements
The editor’s color features were reorganized so color application and color selection are handled separately. This makes it easier for Odoo apps to offer editing tools with or without user-facing color controls, while preserving icon-related editing where needed.
Original PR description
task-5043928