Daily updates from Odoo
Friday, October 3, 2025
221 changes
11 changes
Resolved issues and error corrections
The Helpdesk “Ask the community” button now sends users to the correct forum page instead of a missing page. This prevents a 404 error for teams using community forums and keeps customers on the intended support path.
Original PR description
Scenario:
- create a helpdesk team
- enable community forum on it
- go to the team and click on "Ask the community"
Result: 404 error, this page does not exist
Cause: we are using helpdesk.team ID in route needing a forum.forum ID
Fix: uses /helpdesk/{team ID}/forums route instead of /forum/{team ID}
opw-5027193
Forward-Port-Of: odoo/enterprise#96026Field service sales orders now recalculate line prices when a task’s warranty status is changed. This prevents prices from incorrectly staying at zero after warranty is removed, helping ensure customers are billed accurately.
Original PR description
### Steps to reproduce:
- Create a sales order linked to the customer
- Assign a customer (partner) to the task and link the task to the sales order
- Create a sales order line for a product and link it to the task
- Verify the price unit matches the product's list price by default
- Set the task as under warranty
- Add or remove an item from SOL
- Verify the price unit is set to 0.0 in the sales order line
- Unset the warranty status
- Add an item to the SOL
### Cause:
When setting the task as under warranty we modify the price of each SOL to 0.0 but when unset the warranty option we try to fetch the prices from the SOL which we already set it to 0.0
### Fix:
Backporting https://github.com/odoo/enterprise/pull/85492/commits/8615fad5b75d32483b25cf9b1525883e7a730fac to check when writing on the under_warranty value we recompute the SOL prices
opw-4579404
Forward-Port-Of: odoo/enterprise#96045Pasting over selected link text in the editor now respects protected and non-editable content. This prevents website menus or other protected links from being accidentally removed and replaced with plain text.
Original PR description
When the label of a link is fully selected and the user pastes some text, the link is removed. It was removed even if the link was in a `contenteditable=false` or was unremovable. This commit only…
When the label of a link is fully selected and the user pastes some text, the link is removed. It was removed even if the link was in a `contenteditable=false` or was unremovable. This commit only attempts to remove the link element after checking these conditions. It also only selects the link in the `before_paste` handler, and lets the normal paste logic remove it. Steps to reproduce (after 18.4, where it was noticed): - Copy some simple text - Open website builder - Select completely the label of a menu in the header - Paste - Bug: the menu item is removed, and replaced with simple text Steps to reproduce (in 18.0 and later): - Open "To-Do" app - Add a link in the middle of a line of text - With inspector, edit html to put `contenteditable="false"` on the container of the line, and `contenteditable="true"` on the link - Select completely the label of the link in the document - Paste some text - Bug: the link is removed, and the clipboard content is inserted after the non editable element task-5110141 Forward-Port-Of: odoo/odoo#229558 Forward-Port-Of: odoo/odoo#228223
This update adds automated checks for formatting shortcuts such as bold, italic, underline, and strikethrough when no text is selected. It helps ensure the editor handles these actions cleanly without creating unnecessary undo steps, improving reliability for users writing or editing content.
Original PR description
Description of the issue this PR addresses: This PR adds test cases for formatting shortcuts (e.g., Ctrl+B) on a collapsed selection. An empty inline tag is inserted temporarily and auto-cleaned if unused, so no individual history step are created. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229429 Forward-Port-Of: odoo/odoo#229233
This update adds extra logging to a background notification test that has been failing unpredictably. The added diagnostics should help developers identify the root cause faster, with no expected impact on everyday users.
Original PR description
The `test_postcommit` test ensures that the creation of several bus records result in a single postgres notify after commit. This test have been failing in a non deterministic fashion for some time. Theorical fixes have been try, but fails still persist. This commit adds some logs to this test to better understand what's happening. runbot-232798 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228996
This change removes an unnecessary database rule from the Mail discussion channel setup. It helps prevent failures when creating or migrating future databases on PostgreSQL 18, with no expected change for everyday users.
Original PR description
The field is `required=True`, which automatically sets it `NOT NULL` (if possible). The constraint does not do anything useful. Furthermore, pg18 promoted `NOT NULL` to "real" named constraints[1],…
The field is `required=True`, which automatically sets it `NOT NULL` (if possible). The constraint does not do anything useful.
Furthermore, pg18 promoted `NOT NULL` to "real" named constraints[1], and the constraint was created following the pattern pg uses, so trying to migrate a database to pg18 (either upgrading a cluster from 17 to 18 or restoring a db on a pg18) the restoration fails with
duplicate key value violates unique constraint "pg_constraint_conrelid_contypid_conname_index"
The easiest fix is to delete the constraint in the upstream DB if possible (I didn't find a way to filter out constraints from pg_dump or pg_restore, though it should be possible to filter it out from a "plain" dump by hand).
AFAIK Odoo does not generally drop constraints so I don't think this will fix existing databases, but it at least makes future databases compatible with pg18.
[1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a379061a22a8fdf421e1a457cc6af8503def6252
Forward-Port-Of: odoo/odoo#229539
Forward-Port-Of: odoo/odoo#229274The click-and-collect checkout test was adjusted to focus on confirming public access behavior instead of recreating a timing-sensitive shopping flow. This reduces inconsistent automated test results and helps keep checkout validation dependable without changing customer-facing functionality.
Original PR description
Tours are too fast for imitating the user actions that led to sometimes creating 2 orders in parallel instead of reusing the first created. The test was added for b395f984b13eb83310024b9fa94d7822211ef8c1 fix, so with this commit, we keep the test more specific to the fix and avoid inconsistent behavior. Forward-Port-Of: odoo/odoo#229630 Forward-Port-Of: odoo/odoo#218417
This fix restores tooltip text when users hover over custom text fields added to sale order lines through Studio. It helps users see full cell contents again in the sales order line list, improving usability without changing business workflows.
Original PR description
## Versions 18.0+ ## Issue No tooltip can be displayed on Sale Order Lines. ## Steps to reproduce *Install Studio* - Open any SO; - Open Studio: - Click "Edit List view" on the Order Lines table; - Add a "Text" field in the columns; - Close Studio. - Add a product line if none: - Write something in the new column added with Studio; - Hover that cell and see no tooltip appear ## Cause https://github.com/odoo/odoo/blob/4daf4824a70ef679f65d5cbb15d71bc55c1e760e/addons/web/static/src/views/list/list_renderer.xml#L250 The template calls `getCellTitle` which returns a formatted text but has been overridden. These methods call the original `getCellTitle` method but don't return the formatted value. opw-4921113 Forward-Port-Of: odoo/odoo#229390 Forward-Port-Of: odoo/odoo#225550
This update corrects a reporting query in Timesheets and Attendance so employee records are matched properly during processing. It prevents certain database errors that blocked upgrade requests, helping upgrades complete more reliably.
Original PR description
In the affected query, the variable "employee_id" is undefined in the scope where it is used. This leads postgres to interpret it as a variable with default type VARCHAR and to the impossibility to compare it against an integer. We just qualify the variable name so it now works as expected. Failing upgrade requests: [3103245](https://upgrade.odoo.com/odoo/request/3103245) [3121291](https://upgrade.odoo.com/odoo/request/3121291) Fixes https://github.com/odoo/odoo/pull/192434/commits/c97ecfa7fc091f763329af589b69db2292931163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225401
The French accounting FEC export now excludes invoice note and section lines that do not belong to an accounting account. This prevents non-accounting content from appearing in statutory export files, improving accuracy and compliance of reports.
Original PR description
Step to reproduce: - for l10n_fr Localization - Create a customer invoice and add a note or Add a section . - Go to accounting > reporting > FEC - Export FEC (don't exclude 0 lines) Obseravtion: - The journal items with note and section will be included in the FEC Cause: - for Fec report, we consider move_line which do not have account_id linked to it, due to left_join, hence lines with display_type line_note or line_section are included Fix: - use `join` instead of `left_join` - **v17.0, when the behaviour was as expected** https://github.com/odoo/odoo/blob/3d3898b442379d7416da0ee7e363b6587c725218/addons/l10n_fr_fec/wizard/account_fr_fec.py#L194-L196 opw-5079457 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227817
This fixes an issue where increasing a sale order quantity could create the wrong additional delivery quantity when custom warehouse routes were used. Businesses using multi-step deliveries and personalized routes will now get more accurate picking quantities, reducing manual corrections and fulfillment mistakes.
Original PR description
**Steps to reproduce:** - enable multi-step routes setting. - navigate to warehouse management/locations create a new location (the "test location"). - select "internal location" for the location…
**Steps to reproduce:** - enable multi-step routes setting. - navigate to warehouse management/locations create a new location (the "test location"). - select "internal location" for the location type. - select WH for the parent location - navigate to warehouse management/warehouses and select the warehouse corresponding to WH. - set the warehouse in 3 steps delivery. - click on the routes smart button. - click on the "deliver in 3 steps (pick+pack+ship)" route. - add a rule, for the action select "push to", for the operation type select "internal transfers", for the source location select the "test location" you just created and for destination location select "WH/Output". - save. - create a storable product and set an on-hand quantity - create a new sale order for 1 quantity of this product and confirm it - click on the picking smart button, change the destination location to the test location and validate - open the sale order and change the quantity to 3 **Current behavior:** A new picking is created from stock to packing zone (which is the expected behavior) but the quantity is 1 **Expected behavior:** The quantity should be 2. If we only increase the quantity by 1 on the sale order it does not even create the new picking **Cause of the issue:** The warehouse_id field is invisible in stock.rule form view when the action is push. Therefore, the rule is created without a warehouse_id. Also, moves created from a rule have the same warehouse_id as the rule. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/models/stock_rule.py#L275 So, when we validated our first move (from stock to the test location), this created a second move (from test location to output) that does not have a warehouse id (because it was created from our own push rule that we created). When we update the quantity of the sale ordre line, _action_launch_stock_rule calls _get_quantity_procurement to compute the current quantity on the moves. This method then calls _get_outgoing_incoming_moves to get the initial move created from the rule. In this case this should return only the first move created. But because the second move does not have a warehouse_id, it's rule.id is added to triggering_rule_ids. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L315-L317 And the move is later added to the outgoing moves that will be returned. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L322-L329 So the two moves are returned and the sum of the quantities of the moves is 2 instead of 1. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L292-L294 So the product quantity for the procurement will be 1 (3-2) instead of 2 (3-1). https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L386 opw-5039249 Forward-Port-Of: odoo/odoo#229332 Forward-Port-Of: odoo/odoo#227421
13 changes
Resolved issues and error corrections
The Ask the Community button now opens the correct forum page for a helpdesk team instead of showing a page-not-found error. This helps customers and support users reach the community forum smoothly when forum support is enabled.
Original PR description
Scenario:
- create a helpdesk team
- enable community forum on it
- go to the team and click on "Ask the community"
Result: 404 error, this page does not exist
Cause: we are using helpdesk.team ID in route needing a forum.forum ID
Fix: uses /helpdesk/{team ID}/forums route instead of /forum/{team ID}
opw-5027193
Forward-Port-Of: odoo/enterprise#96026Changing a field service task’s warranty status now recalculates related sales order line prices instead of reusing a zero warranty price. This prevents newly added or updated items from staying free after warranty is removed, helping keep invoices and sales orders accurate.
Original PR description
### Steps to reproduce:
- Create a sales order linked to the customer
- Assign a customer (partner) to the task and link the task to the sales order
- Create a sales order line for a product and link it to the task
- Verify the price unit matches the product's list price by default
- Set the task as under warranty
- Add or remove an item from SOL
- Verify the price unit is set to 0.0 in the sales order line
- Unset the warranty status
- Add an item to the SOL
### Cause:
When setting the task as under warranty we modify the price of each SOL to 0.0 but when unset the warranty option we try to fetch the prices from the SOL which we already set it to 0.0
### Fix:
Backporting https://github.com/odoo/enterprise/pull/85492/commits/8615fad5b75d32483b25cf9b1525883e7a730fac to check when writing on the under_warranty value we recompute the SOL prices
opw-4579404
Forward-Port-Of: odoo/enterprise#96045This change adds extra diagnostic logging to an internal bus notification test that has been failing unpredictably. It helps developers understand and resolve the intermittent test issue without changing business functionality.
Original PR description
The `test_postcommit` test ensures that the creation of several bus records result in a single postgres notify after commit. This test have been failing in a non deterministic fashion for some time. Theorical fixes have been try, but fails still persist. This commit adds some logs to this test to better understand what's happening. runbot-232798 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228996
This removes an unnecessary database rule from Odoo's mail discussion channels. The change helps prevent failures when creating or restoring future databases on PostgreSQL 18, without changing how users interact with the mail app.
Original PR description
The field is `required=True`, which automatically sets it `NOT NULL` (if possible). The constraint does not do anything useful. Furthermore, pg18 promoted `NOT NULL` to "real" named constraints[1],…
The field is `required=True`, which automatically sets it `NOT NULL` (if possible). The constraint does not do anything useful.
Furthermore, pg18 promoted `NOT NULL` to "real" named constraints[1], and the constraint was created following the pattern pg uses, so trying to migrate a database to pg18 (either upgrading a cluster from 17 to 18 or restoring a db on a pg18) the restoration fails with
duplicate key value violates unique constraint "pg_constraint_conrelid_contypid_conname_index"
The easiest fix is to delete the constraint in the upstream DB if possible (I didn't find a way to filter out constraints from pg_dump or pg_restore, though it should be possible to filter it out from a "plain" dump by hand).
AFAIK Odoo does not generally drop constraints so I don't think this will fix existing databases, but it at least makes future databases compatible with pg18.
[1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a379061a22a8fdf421e1a457cc6af8503def6252
Forward-Port-Of: odoo/odoo#229539
Forward-Port-Of: odoo/odoo#229274This fix prevents an error when users validate Register Production/Serial in the Shop Floor after duplicate or multiple quality checks exist. Manufacturing teams can continue production recording without being blocked by a traceback.
Original PR description
When user tries to validate Register Production/Serial in shop floor, A traceback will appear. Steps to reproduce the error: - Install ``mrp_workorder`` and ``quality_control`` modules with demo data…
When user tries to validate Register Production/Serial in shop floor, A traceback will appear. Steps to reproduce the error: - Install ``mrp_workorder`` and ``quality_control`` modules with demo data - Go to Quality > Create a new Control point > Product: Table Top > Operations: Manufacturing > Save - Create a new MO > Product: Table Top > Confirm > Shop Floor > Click on Assembly 1 > Click on 3 dots > Update Instructions > Improvement Suggestion > Add a step > Propose Change > Validate - Click on 3 dots > Register Production/Serial > Validate - Go back to MO > Quality Checks > Duplicate the newly created quality check > Shop Floor > Click on Assembly 1 > Click on 3 dots > Register Production/Serial > Validate Traceback: ``ValueError: Expected singleton: quality.check(1, 5)`` https://github.com/odoo/enterprise/blob/5103383df3ddf23503e2c7817c5129a742a7800f/mrp_workorder/models/mrp_workorder.py#L846-L848 When User clicks on the validate, ``current_check`` may include several quality checks without a ``previous_check_id``. The code expects only one record, which causes a traceback. sentry-6839419788
This fixes an inventory calculation issue where outgoing stock moves could be missed when quantities were computed for a specific location in strict mode. Businesses using location-specific stock views should now see more accurate available quantities, reducing the risk of incorrect inventory decisions.
Original PR description
### Issue: Commit ba54310a11d2b702753d4b9b028a62dd00a91467 has altered the location domain for quantities computations. However, the `dest_loc_domain_out` has not been correctly replaced: https://github.com/odoo/odoo/blob/f173c738b1adcf85a80eb641ad307b7cccf17294/addons/stock/models/product.py#L319 Since the returned value used to be negated and is not anymore. This results in out moves being ignored by the `_compute_quantities` in `strict` mode. opw-4997982 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229304
Website pricelist snippets now keep the correct spacing and text size when descriptions are regenerated in the page builder. This prevents product descriptions from appearing too large or too close to titles, keeping website layouts polished and consistent.
Original PR description
New description paragraphs generated by the builder for the "pricelist" snippets were missing two expected classes. - "mt-2" was never applied, so all pricelist variants lacked the vertical spacing below product titles. - The boxed and cafe snippets also needed the `o_small` class to keep their text size consistent. Steps to see the missing "o_small": 1. Drop an "s_pricelist_boxed" or "Pricelist Cafe" snippet on a page. 2. Use Backspace to delete the text already present in one of the descriptions. 3. Toggle the "Descriptions" option off and on; the regenerated paragraph appears larger than expected because `o_small` is absent. task-5117864 Forward-Port-Of: odoo/odoo#229464
Discarding a quality worksheet wizard no longer creates a worksheet record or marks the quality check as completed. This prevents users from seeing false completion statuses when they cancel worksheet entry.
Original PR description
**Problem:** Opening the worksheet wizard and discarding it makes the worksheet "completed" **Steps to reproduce:** - create a quality check - set a product - in type select worksheet - select the "quality issues" template - select a team - click on the worksheet smart button - discard **Current behavior:** the worksheet is marked has completed **Cause of the issue:** when discarding, this line causes the creation of an instance of worksheet.template linked to the quality.check via its worksheet_template_id https://github.com/odoo/enterprise/blob/a1dd58f2b59ecd2d22efd29eb0aace7bdca64f66/quality_control_worksheet/static/src/views/quality_worksheet_fromview.js#L35 which will make the worksheet_count field of the quality check worth 1 after discarding https://github.com/odoo/enterprise/blob/1c5e547b59a57c840ef72b2e76c6a6a627f1f18e/quality_control_worksheet/models/quality.py#L37-L39 opw-4980945 Forward-Port-Of: odoo/enterprise#95219
This update corrects an automated test step for the bank reconciliation interface so it waits for the right screen element. This helps prevent false test failures and improves confidence that the accounting workflow remains stable.
Original PR description
The step checks the non presence of `o_bank_rec_quick_create`. But this element does not exist, as it should be `o_bank_reconciliation_quick_create`. This causes the tour to sometimes fail as we click on unfold before the interface updates from the creation of the line. runbot-error-230727
The French FEC accounting export now skips invoice note and section lines that are not real accounting entries. This prevents non-accounting information from appearing in the official export, improving compliance and report accuracy.
Original PR description
Step to reproduce: - for l10n_fr Localization - Create a customer invoice and add a note or Add a section . - Go to accounting > reporting > FEC - Export FEC (don't exclude 0 lines) Obseravtion: - The journal items with note and section will be included in the FEC Cause: - for Fec report, we consider move_line which do not have account_id linked to it, due to left_join, hence lines with display_type line_note or line_section are included Fix: - use `join` instead of `left_join` - **v17.0, when the behaviour was as expected** https://github.com/odoo/odoo/blob/3d3898b442379d7416da0ee7e363b6587c725218/addons/l10n_fr_fec/wizard/account_fr_fec.py#L194-L196 opw-5079457 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227817
Rental subscriptions using products made from kits now keep the correct delivered quantity when they are closed or reopened. This prevents incorrect return errors after deliveries have already been validated, making rental subscription processing more reliable.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable rental transfers; 2. have a rental product with a kit BoM; 3. create a subscription order in the Rental app; 4. add the rental product; 5. confirm…
Versions -------- - 18.0+ Steps ----- 1. Enable rental transfers; 2. have a rental product with a kit BoM; 3. create a subscription order in the Rental app; 4. add the rental product; 5. confirm order; 6. validate deliveries; 7. close the subscription. Issue ----- Invalid SQL command, cannot return more than was delivered. Cause ----- When closing or reopening a subscription, the `_compute_qty_delivered` method gets triggered. By default, these methods required the relevant moves to have the same `product_id` as the sale order line. For products with kit BoMs, the move's `product_id` is tied to the BoM instead of the final product, leading to `qty_delivered` getting reset reset to 0 on recompute. This causes an error, as `qty_returned` is non-zero. Solution -------- The `qty_delivered` for these lines was set in the `_action_done` method of `stock.move`. By instead moving this logic into a `_compute_qty_delivered` override, any recompute should have the same result, instead of getting reset to 0. opw-4833280 Forward-Port-Of: odoo/enterprise#96179 Forward-Port-Of: odoo/enterprise#88691
Point of Sale preparation screens now display any free-text custom attribute entered for a product, matching what already appears on receipts. This helps staff see complete order details and reduces the risk of preparing items incorrectly.
Original PR description
Steps to reproduce: ------------------- 1. Create a PoS product with an attribute of type "Radio", name it "X", and add a value to it, name it "Y", with the "Free text" option selected. 2. From PoS, click the product, for the attribute "X", select the value "Y", and enter some text in the text input area "blabla". 3. Order the product. Observation: On the preparation display, only the attribute name and value are display, but not the entered text, i.e. "X: Y" instead of "X: Y: blabla". Fix: ---- We now show the custom value (free text) if any. This matches what's been shown on the receipt in PoS. opw-5111768
The ESG demo data was adjusted so it no longer depends on accounting records tied to a specific country setup. This prevents errors when loading demo data in fresh databases using India or other fiscal localizations, making setup more reliable.
Original PR description
**Note: issue not reproducible in runbot, but in fresh database** **Step to reproduce:** - in fresh database, install esg module - go to setting > invoicing > add india as Fiscal Localization -…
**Note: issue not reproducible in runbot, but in fresh database**
**Step to reproduce:**
- in fresh database, install esg module
- go to setting > invoicing > add india as Fiscal Localization
- change company name, ex "test"
- goto setting > load demo data
**Observation:**
- You will receive traceback
```
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/codebase/enterprise/saas-18.4/esg/demo/demo_data.xml:567, somewhere inside
<record id="esg_emission_factor_line_assignation_4" model="esg.assignation.line">
<field name="esg_emission_factor_id" ref="esg_zero_emission_factor"/>
<field name="account_id" model="account.account" search="[('code', '=', '630000')]"/>
</record>
2025-09-11 08:45:07,458 82617 INFO esg184 odoo.addons.base.models.ir_module: module esg: no translation for language en_IN
2025-09-11 08:45:07,479 82617 ERROR esg184 odoo.sql_db: bad query: b'INSERT INTO "esg_activity_type_esg_emission_factor_rel" ("esg_emission_factor_id", "esg_activity_type_id") VALUES (1, 2) ON CONFLICT DO NOTHING'
ERROR: insert or update on table "esg_activity_type_esg_emission_factor_rel" violates foreign key constraint "esg_activity_type_esg_emission_fact_esg_emission_factor_id_fkey"
DETAIL: Key (esg_emission_factor_id)=(1) is not present in table "esg_emission_factor".
```
**Cause:**
- The demo data relies on few account.account record which belong to [USA company](https://github.com/odoo/odoo/blob/9805d09dff64de835de0c764da8c6e213d6b88aa/addons/account/data/template/account.account-generic_coa.csv#L38)
https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L569
https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L620-L628
- when we installed `india` Localization and changed the company name, USA company could not be created when loading demo data and hence the account records were not created, causing traceback
**Fix:**
- make demo data independent of any localization
opw-504841711 changes
Resolved issues and error corrections
Uploaded file fields added to field service worksheet templates are now shown when customers or workers view the worksheet report in the portal. This ensures signed worksheet reports include all entered information, avoiding missing attachments or incomplete documentation.
Original PR description
Steps to reproduce: ------- - Install industry_fsm_report module - Open FSM app - Select worksheets from settings in the configuration - Go to worksheet templates in the configuration - Create a worksheet template - Click the design template button. You arrive in the studio - Add file field and close it - Create a new task and select a newly created template in the worksheet template - Click the worksheet button in the control panel - Upload a file and save it - Click on the sign report button - Here file field is not visible Issue: ------- The file field is not visible in the worksheet portal. Cause: ------ The view of the file field is not created for the worksheet portal. Solution: ------- Created the view of the file field to display in the worksheet portal. task-3691529 Forward-Port-Of: odoo/enterprise#95754 Forward-Port-Of: odoo/enterprise#56035
Rental product prices on the website now display using the currency's configured decimal precision. This prevents customers from seeing unnecessary decimal places when a business uses whole-number pricing, improving consistency and trust at checkout.
Original PR description
Versions -------- - 17.0 Steps ----- 1. Set currency precision to 0 decimals; 2. check prices in eCommerce as public user. Issue ----- Prices are displayed with 2 decimals Cause ----- The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element. Solution -------- Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`. opw-4996878 Community PR: https://github.com/odoo/odoo/pull/224429 Forward-Port-Of: odoo/enterprise#95914 Forward-Port-Of: odoo/enterprise#95634
The Indian GST reporting tests now cover sales involving reverse charge tax and SEZ supplies with LUT. This helps reduce the risk of incorrect GSTR-1 reporting for businesses using these tax scenarios.
Original PR description
Adding GSTR1 test case with RCM tax and SEZ (with LUT) see https://github.com/odoo/odoo/pull/213931 Forward-Port-Of: odoo/enterprise#87486
Tests were updated to match a recent change in how suggested email recipients are returned. This keeps automated checks reliable across Helpdesk, HR Contract Salary, and Studio without changing end-user behavior.
Original PR description
From the related community commit, the _message_add_suggested_recipient method is modified to also return display name under certain condition. This commit adapts the test inside web_studio to align with the method's change. Task-4812554 Forward-Port-Of: odoo/enterprise#91003
This update adjusts an automated test for SEPA credit transfers so it follows the current rules for bank account data handling. It helps keep payment-related quality checks reliable without changing day-to-day user workflows.
Original PR description
Direct update sanitized_acc_number is not allowed. Forward-Port-Of: odoo/enterprise#95477 Forward-Port-Of: odoo/enterprise#72508
This fix stops Mexican PoS orders with different required e-invoicing fields from being combined into one invoice. Instead of causing a system error, users now receive a clear validation message explaining that the orders cannot be consolidated.
Original PR description
Issue: Currently when we consolidate billing for PoS orders we receive an error because some l10n fields expect a single record and not a recordset. This can be solved by looping over the PoS orders instead and preparing the invoice values per order (this is how the sale orders handles consolidated billing) however, we run into an issue if not all PoS orders have the same l10n fields. Ideally PoS orders with different l10n fields should not be consolidated. Purpose of this PR: check to make sure that the three l10n_mx_edi fields are the same among PoS orders before creating consolidated invoice. raise a validation error if the fields are not the same. Steps to reproduce on Runbot: install pos and l10n_mx* create pos orders for same contact try to create invoices with consolidated billing enabled singleton error is raised Note: main discussion about consolidated billing with l10n_mx localization: #86255 opw-4802180
Rental subscriptions using kit products now keep the correct delivered quantity when they are closed or reopened. This prevents return errors that incorrectly claimed more items were being returned than had been delivered.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable rental transfers; 2. have a rental product with a kit BoM; 3. create a subscription order in the Rental app; 4. add the rental product; 5. confirm…
Versions -------- - 18.0+ Steps ----- 1. Enable rental transfers; 2. have a rental product with a kit BoM; 3. create a subscription order in the Rental app; 4. add the rental product; 5. confirm order; 6. validate deliveries; 7. close the subscription. Issue ----- Invalid SQL command, cannot return more than was delivered. Cause ----- When closing or reopening a subscription, the `_compute_qty_delivered` method gets triggered. By default, these methods required the relevant moves to have the same `product_id` as the sale order line. For products with kit BoMs, the move's `product_id` is tied to the BoM instead of the final product, leading to `qty_delivered` getting reset reset to 0 on recompute. This causes an error, as `qty_returned` is non-zero. Solution -------- The `qty_delivered` for these lines was set in the `_action_done` method of `stock.move`. By instead moving this logic into a `_compute_qty_delivered` override, any recompute should have the same result, instead of getting reset to 0. opw-4833280 Forward-Port-Of: odoo/enterprise#88691
The Helpdesk customer portal link for asking the community now sends users to the correct forum page instead of a missing page. This prevents customers from hitting a 404 error when a helpdesk team has community forum support enabled.
Original PR description
Scenario:
- create a helpdesk team
- enable community forum on it
- go to the team and click on "Ask the community"
Result: 404 error, this page does not exist
Cause: we are using helpdesk.team ID in route needing a forum.forum ID
Fix: uses /helpdesk/{team ID}/forums route instead of /forum/{team ID}
opw-5027193
Forward-Port-Of: odoo/enterprise#96026This fix ensures sales order line prices are recalculated correctly when a field service task is moved out of warranty. It prevents billable items from incorrectly staying at zero after warranty status changes, helping keep customer invoices accurate.
Original PR description
### Steps to reproduce:
- Create a sales order linked to the customer
- Assign a customer (partner) to the task and link the task to the sales order
- Create a sales order line for a product and link it to the task
- Verify the price unit matches the product's list price by default
- Set the task as under warranty
- Add or remove an item from SOL
- Verify the price unit is set to 0.0 in the sales order line
- Unset the warranty status
- Add an item to the SOL
### Cause:
When setting the task as under warranty we modify the price of each SOL to 0.0 but when unset the warranty option we try to fetch the prices from the SOL which we already set it to 0.0
### Fix:
Backporting https://github.com/odoo/enterprise/pull/85492/commits/8615fad5b75d32483b25cf9b1525883e7a730fac to check when writing on the under_warranty value we recompute the SOL prices
opw-4579404
Forward-Port-Of: odoo/enterprise#96045Payroll PDF generation now skips document creation when an employee is missing the required contact record. This prevents scheduled payroll document generation from failing and helps payroll teams continue processing payslips smoothly.
Original PR description
Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner.…
Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner. **Prerequisites:** - Ensure HR is enabled in `settings>Documents` **Steps to Reproduce:** 1) Install `documents_hr_payroll` module.(with Demo) 2) Navigate to the Employees App. 3) Select any Employee(e.g Abigail Peterson) and open form view. >- click on **contacts** smart button. >- Delete that Record 4) Create a confirmed Payslip for the selected Employee(e.g Abigail Peterson). 5) Activate Developer mode and navigate to schedule Actions. >- Search for 'Payroll: Generate pdfs'. >- Run Manually. Error: `NotNullViolation: null value in column 'partner_id' of relation 'documents_access' violates not-null constraint` Root Cause: When the partner is deleted, the value received from `_get_document_partner` at [1] is `False`, which later on tries to create the `documents.access` record for the new document, it fails because no partner is available to assign access rights, resulting in the error. Solution: This commit prevent Error by ensuring `_check_create_documents` method doesn't allow document creation without valid partner. [1]: https://github.com/odoo/enterprise/blob/99a8d83edb42f172d0dd35c91743fa0c9653dcbb/documents_hr_payroll/models/hr_payslip.py#L20C1-L21 sentry-6814524392 Forward-Port-Of: odoo/enterprise#92865
Fixes an issue where changing custom date ranges while editing budget report amounts could cause an error and block the user. The budget report now matches monthly budget items consistently, preventing duplicate incomplete entries and keeping budget editing reliable.
Original PR description
Currently, an error occurs when user editing the budget report items. Steps to Reproduce [Video](https://drive.google.com/file/d/1bz0GEQjwxQrckzcEHdYPfvaA5M43lmFF/view): - Install the `Accounting`…
Currently, an error occurs when user editing the budget report items. Steps to Reproduce [Video](https://drive.google.com/file/d/1bz0GEQjwxQrckzcEHdYPfvaA5M43lmFF/view): - Install the `Accounting` module. - Go to `Profit and Loss` > `Budget` and `create a budget`. - Select `custom dates (e.g., start: 01/01/2025, end: 12/10/2025)` and change the amount of a budget line. - Change the `date range (e.g., start: 01/10/2025, end: 12/10/2025)` and change the amount again. - `Switch back to the first date range` (start: 01/01/2025, end: 12/10/2025) and try changing the amount once more. `TypeError: unsupported operand type(s) for +: 'float' and 'NoneType'` This error occurs when a user editing the budget report items. When user enters a date period, the system creates budget items for the first date of every month within that range. If the user then changes the date period to the next date of the same month, the system attempts to fetch the existing budget item `[1]` for that range. However, due to the start date alignment, it fails to fetch the correct budget item and instead creates an extra one `[2]`. Later, when the system checks again from the first date of the same month as the start date, it finds this extra budget item, for that the amount is None, which raises the error `[3]`. This commit ensures that when fetching existing items and generating the start month dates `[4]`, the system always uses the first day of the month as the `start date` so that the flow is maintained.. [1]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L44-L49 [2]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L75-L79 [3]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L72 [4]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L58-L61 sentry-6883207225 Forward-Port-Of: odoo/enterprise#95090
23 changes
Resolved issues and error corrections
When warehouse staff split a reserved package into multiple destination packages in the Barcode app, the new split line now retains the original source package. This prevents package information from being lost during partial deliveries, reducing picking errors and improving traceability.
Original PR description
### Before this PR: - Put a package in WH/Stock with quantity 100 - Create delivery for partial quantity for example 50 - Go to app barcode - Try to split the package into two different packages scanning another destination Package - The splitted line will be created with empty package instead of the package already reserved before ### After this PR: Scanning another destination package , the new line created splitting the old one will have the package_id Forward-Port-Of: odoo/enterprise#96071 Forward-Port-Of: odoo/enterprise#81170
The ESG app now retrieves the correct IPCC database table information before downloading data, preventing intermittent empty downloads. It also handles measurement units correctly, avoiding server errors during the download process.
Original PR description
## [FIX] esg: fetch ipcc database Before this commit, sometimes the download button for IPCC database does not work because the request made to IPCC database to fetch data, does not return any data. The reason is because the table name used in parameter changed after a certain time. This commit gathers the table_name when we do extra rpc to fetch all parameters to use to correctly export the data. ## [FIX] esg: check unit fetched to correctly process data gathered Before this commit, when the user downloads the IPCC database, an error is raised in server log because an uom recordset is compared to a string instead of checking the unit gathered with the expected string. This commit alters the check to correctly check the right things. Forward-Port-Of: odoo/enterprise#95879
The Turkish localization reports had a bug that could produce blank General Ledger CSV exports after a recent report change. This fix restores the missing data retrieval so exported files contain the expected accounting lines.
Original PR description
## Before this commit: After the refactor of the General Ledger in the referenced commit, `l10n_tr_reports` no longer able to fetch the `aml_ids`. This caused the CSV export of the General Ledger to be generated as blank. Ref commit: https://github.com/odoo/enterprise/commit/235a5160d13296328b79e4092a8b88a733628268 ## After this commit: Ensured that `aml_ids` are properly retrieved, so that the General Ledger CSV export contains the expected data. Forward-Port-Of: odoo/enterprise#95577
This fix prevents crashes in the Belgian POS certification flow when several employees are clocked in on the same point of sale. Sales and session closing can now proceed reliably in that scenario, reducing disruption for store staff.
Original PR description
- Fix traceback when trying to sell a product with multiple employees clocked in on the same POS. - Fix traceback when trying to close a session with multiple employees clocked in. task-id: 4902090 Forward-Port-Of: odoo/enterprise#95966 Forward-Port-Of: odoo/enterprise#93273
The Helpdesk community support link now sends customers to the correct forum page instead of showing a page-not-found error. This ensures users can reach community help from a Helpdesk team when the forum option is enabled.
Original PR description
Scenario:
- create a helpdesk team
- enable community forum on it
- go to the team and click on "Ask the community"
Result: 404 error, this page does not exist
Cause: we are using helpdesk.team ID in route needing a forum.forum ID
Fix: uses /helpdesk/{team ID}/forums route instead of /forum/{team ID}
opw-5027193
Forward-Port-Of: odoo/enterprise#96026Report exports now retrieve account annotations in the correct date order, reducing extra processing and improving consistency. Audit balance views also now show the latest message only when it belongs to the audit period, preventing out-of-period notes from appearing in the wrong audit context.
Original PR description
Previously when exporting a report, we would sort the annotation based on their create_date or to get the last annotation we would need to use max to find the latest one. Now, when exporting the report we order them directly so we dont need to bother with it. It's not needed to sort them when simply viewing the report as they are displayed in the chatter already in the right order Also fix a bug where the last_message displayed on the balance view of the audits isn't filtered on the period of the audit. To replicate: - Create an Audit for any year. - Post an annotation on an account on a period outside of the period of the audit. - Go to the balance view and check the account, it now has the new message even though it's outside the audit period. Forward-Port-Of: odoo/enterprise#95307
Payslip correction guidance now appears in the payslip issues area instead of as a banner at the top of the form. This keeps the form cleaner while still helping payroll users review corrections and choose to keep a payslip unchanged from the correction wizard.
Original PR description
Move the correction banner from the top of the payslip form view to issues. Add a `keep as it is` button inside the wizard to keep a single button. task-5074163
Customers can no longer accidentally combine one-time purchases with subscription products in the same cart. The checkout flow now warns shoppers and blocks the conflicting item, helping avoid confusion about whether an order is recurring or one-off.
Original PR description
**Version:** - saas-18.4 **Steps to reproduce:** - Create a one-time product. - Add the one-time product to the cart. - Add a subscription (recurring) product. - The one-time product is incorrectly shown as a subscription. **Issue:** - When a customer adds a one-time product to the cart and then adds a subscription product, the one-time product incorrectly gets treated as a subscription. **Solution:** - If the cart already contains a one-time product, the system will show a warning and block adding subscription products (and vice versa). **Impact:** - Customers can clearly understand whether they are buying a one-time product or a recurring subscription, without mixing them by mistake. Task-5046146 Forward-Port-Of: odoo/enterprise#93282
Helpdesk ticket lists now sort ticket references in a more natural order, even after ticket numbers pass 100. This helps users quickly find the oldest or newest tickets without confusing text-based ordering.
Original PR description
**Issue** With the default `helpdesk.ticket` sequence, once users reach 100 tickets, ordering tickets by `ticket_ref` in the list view is unintuitive as it is a Char field (so '11' > '100') and the results are not useful if the user wants to see the oldest/newest tickets. opw-4891916 Forward-Port-Of: odoo/enterprise#95971 Forward-Port-Of: odoo/enterprise#93058
Barcode scanning now correctly converts quantities when a package uses a different unit of measure than the delivery line. This prevents warehouse users from seeing incorrect picked quantities, such as 10 g instead of 10,000 g, and helps ensure deliveries are processed accurately.
Original PR description
Manual forward port of https://github.com/odoo/enterprise/pull/90878 **Problem:** When scanning a package with a different UoM than the barcode line, the conversion is not made. **Steps to…
Manual forward port of https://github.com/odoo/enterprise/pull/90878 **Problem:** When scanning a package with a different UoM than the barcode line, the conversion is not made. **Steps to reproduce:** - Enable the "Packages" setting; - Create a new storable product and set kg as its UoM; - In the inventory tab, add "g" in the packagings - Click on the on hand smart button and select update quantity - Add a new line; - In the package column create a new package; - Set a quantity of 10 kg; - Create a delivery and select your product; - Set a demand on 10000 and select g as the UoM; - Mark as todo; - Open the delivery in the Barcode app; - Scan the package. **Current behavior:** The quantity on the line is now 10 / 10000 g **Expected behavior:** It should be 10000 / 10000 g **Cause of the issue:** https://github.com/odoo/enterprise/blob/4c9fa9dc010958710d848fbcb3241b17ea7205ca/stock_barcode/static/src/models/barcode_picking_model.js#L1500-L1505 remaining_qty is expressed in the uom of the quant so it will be 10 but qty_needed is expressed in the uom of the line is it will be 10000. qty_used beeing the minimum of those two it will be 10. **Fix:** To define how much quantity to take from the package, we convert the line's quantity by using the package's UoM. Then, when we add this quantity to the line's quantity, we re-convert it by using the line's UoM. opw-4860064 Forward-Port-Of: odoo/enterprise#95892 Forward-Port-Of: odoo/enterprise#93693
Creating a new payroll run now opens the employee selection correctly by avoiding an empty reference that was being passed unnecessarily. This helps payroll users start new payruns more reliably without being blocked by a technical form issue.
Original PR description
When creating a new payrun, we were passing the res_id as an argument for self, but it was always falsy. This commit removes the argument such that it uses an empty recordset. task-5130462
Fixed an issue where some action buttons in the payslip list were hidden unless their action was defined in a specific controller. Payroll users can now see the correct available actions, reducing confusion and helping them complete payslip tasks without workarounds.
Original PR description
This commit fixes the display of conditional buttons in the payslips list view. The issue was that only buttons with actions defined in the list controller were displayed. This commit fixes the issue by displaying any button if the action is not specified in the list controller. Forward-Port-Of: odoo/enterprise#96050 Forward-Port-Of: odoo/enterprise#95527
This update prevents completed signature requests from being deleted after they have been signed. It helps preserve important signed records and reduces the risk of losing legally or operationally significant documents.
Original PR description
backport of https://github.com/odoo/enterprise/commit/b2d32811877cdf1649095435ce16274ae96421f3 opw-5111568 Forward-Port-Of: odoo/enterprise#96081 Forward-Port-Of: odoo/enterprise#95922
This fix adjusts an accounting test so it no longer fails when account merging takes longer than expected in databases with many companies. It improves test stability without changing how users work with accounting features.
Original PR description
In test_account_merge_wizard_tour, the actual merging of the accounts can take more than 10 seconds if there are a lot of companies. It causes sometimes timeout of the step and so a fail of the tour. runbot-error-233162
This fix corrects the visual styling of the Belgian payroll holiday attest after a recent user experience update used the wrong layout classes. Employees and payroll teams will see the intended presentation, reducing confusion when viewing this document.
Original PR description
We recently fixed the UX of holiday attest but the classes used in xml were wrong. We fix this in this task. Task: 5109176 Forward-Port-Of: odoo/enterprise#95430
The Sign app guided tour was updated so it no longer fails when users drag signature fields onto documents or when an existing saved signature changes the signing flow. This helps teams and testers complete the guided workflow consistently without duplicate signature fields or stalled steps.
Original PR description
Fix `sign_tour`. How to reproduce: 1. Go to tours in Odoo 2. Look up sign_tour 3. Click testing ( If testing stops at Sign App, change search filters or archive sign all .request records so that the…
Fix `sign_tour`.
How to reproduce:
1. Go to tours in Odoo
2. Look up sign_tour
3. Click testing ( If testing stops at Sign App, change search filters or archive sign all .request records so that the following screen displays )
<img width="780" height="591" alt="image" src="https://github.com/user-attachments/assets/b164c224-0e3e-4dce-97e6-89848263e59e" />
4. tour fails!
---
First commit
The `sign_tour` was failing after the conversion of the `sign.Template` client action to OWL. The standard `drag_and_drop` tour helper can no longer be used for automatic tour testing because the drop target is inside an iframe whose content is managed by PDF.js.
This commit fixes the tour by utilizing the custom helper function, `dragAndDropSignItemAtHeight`, to programmatically simulate the drag and drop action.
---
Second commit
The step "footer.modal-footer button.btn-primary:enabled" assumes that the Signature Dialog opened from its previous step ("Sign It" navigation button).
However, the "Sign It" navigation button does not always open the dialog.
If signing user (res.users) already has "sign_signature" data, the data will be automatically filled in to the Signature input.
Otherwise, the navigation button will open the Signature Dialog.
Luckily, we can see whether user has "sign_signature" data or not by checking if the <input data-item_type='signature'/> node has "data-auto_value" attribute or not.
We now skip the step if data-auto_value is set for signature.
---
Third commit
If `sign.template_sign_tour` has sign request, it means that the template might have a sign item because the `sign_tour` tour adds the Signature sign item to the template. (If user followed the tour)
When we're copying the sign template to trigger the template tour, we should not copy the sign item. User will be guided to add the sign item during the tour.
---
Note:
ci/security needs to be overriden as it was done for https://github.com/odoo/odoo/pull/134793#issuecomment-1711440188
---
opw-4752794
Forward-Port-Of: odoo/enterprise#93601
Forward-Port-Of: odoo/enterprise#91565Fixes an issue where closing or reopening a rental subscription for a kit product could incorrectly reset delivered quantities to zero. This prevents false return errors and helps rental subscriptions with bundled products close reliably after delivery.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable rental transfers; 2. have a rental product with a kit BoM; 3. create a subscription order in the Rental app; 4. add the rental product; 5. confirm…
Versions -------- - 18.0+ Steps ----- 1. Enable rental transfers; 2. have a rental product with a kit BoM; 3. create a subscription order in the Rental app; 4. add the rental product; 5. confirm order; 6. validate deliveries; 7. close the subscription. Issue ----- Invalid SQL command, cannot return more than was delivered. Cause ----- When closing or reopening a subscription, the `_compute_qty_delivered` method gets triggered. By default, these methods required the relevant moves to have the same `product_id` as the sale order line. For products with kit BoMs, the move's `product_id` is tied to the BoM instead of the final product, leading to `qty_delivered` getting reset reset to 0 on recompute. This causes an error, as `qty_returned` is non-zero. Solution -------- The `qty_delivered` for these lines was set in the `_action_done` method of `stock.move`. By instead moving this logic into a `_compute_qty_delivered` override, any recompute should have the same result, instead of getting reset to 0. opw-4833280 Forward-Port-Of: odoo/enterprise#96179 Forward-Port-Of: odoo/enterprise#88691
Consolidated billing for Mexican Point of Sale orders now checks that required localization invoice fields match before creating an invoice. If orders are incompatible, users receive a clear validation error instead of an unexpected system error, helping avoid incorrect consolidated invoices.
Original PR description
Issue: Currently when we consolidate billing for PoS orders we receive an error because some l10n fields expect a single record and not a recordset. This can be solved by looping over the PoS orders instead and preparing the invoice values per order (this is how the sale orders handles consolidated billing) however, we run into an issue if not all PoS orders have the same l10n fields. Ideally PoS orders with different l10n fields should not be consolidated. Purpose of this PR: check to make sure that the three l10n_mx_edi fields are the same among PoS orders before creating consolidated invoice. raise a validation error if the fields are not the same. Steps to reproduce on Runbot: install pos and l10n_mx* create pos orders for same contact try to create invoices with consolidated billing enabled singleton error is raised Note: main discussion about consolidated billing with l10n_mx localization: #86255 opw-4802180 Forward-Port-Of: odoo/enterprise#86579
Discarding a quality worksheet wizard no longer creates a worksheet record or makes the quality check appear completed. This prevents incorrect completion status when users open a worksheet and cancel without entering results.
Original PR description
**Problem:** Opening the worksheet wizard and discarding it makes the worksheet "completed" **Steps to reproduce:** - create a quality check - set a product - in type select worksheet - select the "quality issues" template - select a team - click on the worksheet smart button - discard **Current behavior:** the worksheet is marked has completed **Cause of the issue:** when discarding, this line causes the creation of an instance of worksheet.template linked to the quality.check via its worksheet_template_id https://github.com/odoo/enterprise/blob/a1dd58f2b59ecd2d22efd29eb0aace7bdca64f66/quality_control_worksheet/static/src/views/quality_worksheet_fromview.js#L35 which will make the worksheet_count field of the quality check worth 1 after discarding https://github.com/odoo/enterprise/blob/1c5e547b59a57c840ef72b2e76c6a6a627f1f18e/quality_control_worksheet/models/quality.py#L37-L39 opw-4980945 Forward-Port-Of: odoo/enterprise#95219
DHL delivery quotes and shipments now include insurance when an insurance percentage is configured. This helps businesses charge accurate shipping rates and ensures eligible DHL shipments are actually insured.
Original PR description
**PROBLEM** Insuring a delivery using the dhl carrier don't work. It doesn't affect the estimated rate of the delivery, and the shipment created when validating the delivery order isn't insured.…
**PROBLEM** Insuring a delivery using the dhl carrier don't work. It doesn't affect the estimated rate of the delivery, and the shipment created when validating the delivery order isn't insured. **STEP TO REPRODUCE** 1. Install the `delivery_dhl_rest` and the `l10n_be` modules (we will use the be demo company). 2. Set the insurance percentage of the dhl be delivery method to 100%, and set the region to Europe (the demo data is incorrect), and activate the debug (click the "No Debug" smart button to activate the log of requests). 3. Switch to the be company. 5. Create a sale order, with a customer located in Belgium, and add shipping using the dhl method. 6. Go to the delivery order, and validate it. 7. Go to settings/Technical/Logging and look at the rating_request and shipment_request, notice there is no information about insurance. **CAUSE** We don't send any info about insurance in the api requests. **FIX** Computing and sending the insured amount, only if the insurance percentage is not null. If the package can't be insured between the origin and the destination, a error message will be displayed when updating the delivery price. **TESTS PROBLEM/FIX** The localization of `your_company` was not recognized by DHL, leading to the DHL api returning a 0 delivery price. Switching the localization to Eghezee, Rue du Laid Burniat 5 fixes this. Assertion regarding the delivery price were restored. The picking date could sometimes be refused by DHL (stop working after arround 4/5 PM). Changing the picking date to, two day after, at noon works. `test_01_dhl_basic_be_domestic_flow` was modified to also test domestic shipment insurance in addition of the basic flow. Some code in it was refactor into inner function to avoid boilerplate. Adding `INSURED_RATE_MOCK_RESPONSE` to mock response in test_01. opw-4989281 Forward-Port-Of: odoo/enterprise#93105
Bank account selection fields now show clearer visual indicators for trusted and untrusted accounts. Trusted accounts display a green shield, while untrusted accounts show a red warning icon, helping users identify payment account status more confidently.
Original PR description
This commit fixes the UI indicator of trusted/untrusted bank accounts in many2one widget. For trusted bank accounts, they are indicated with a green shield. Untrusted bank accounts are indicated with a red exclamation circle. This is a followup of the work done in this PR: https://github.com/odoo/odoo/pull/229298 task-5117800
This change updates an automated test for SEPA payment processing so it follows the current rules for bank account data handling. It helps keep the accounting payment flow reliably tested without changing day-to-day user functionality.
Original PR description
Direct update sanitized_acc_number is not allowed. Forward-Port-Of: odoo/enterprise#95477 Forward-Port-Of: odoo/enterprise#72508
This fixes an automated walkthrough used to verify the bank reconciliation screen. The correction helps avoid occasional false failures during testing, improving release confidence without changing user-facing functionality.
Original PR description
The step checks the non presence of `o_bank_rec_quick_create`. But this element does not exist, as it should be `o_bank_reconciliation_quick_create`. This causes the tour to sometimes fail as we click on unfold before the interface updates from the creation of the line. runbot-error-230727 Forward-Port-Of: odoo/enterprise#95359
33 changes
Resolved issues and error corrections
Fixed a broken helpdesk link so customers using “Ask the community” are sent to the correct forum page instead of seeing a 404 error. This helps users reach community support reliably from helpdesk teams with forums enabled.
Original PR description
Scenario:
- create a helpdesk team
- enable community forum on it
- go to the team and click on "Ask the community"
Result: 404 error, this page does not exist
Cause: we are using helpdesk.team ID in route needing a forum.forum ID
Fix: uses /helpdesk/{team ID}/forums route instead of /forum/{team ID}
opw-5027193
Forward-Port-Of: odoo/enterprise#96026The Australian payroll API tests were updated so they no longer depend on demo data, and the cleanup script was corrected. This helps prevent build failures and improves confidence that payroll-related checks run reliably in different environments.
Original PR description
Remove test dependency on demo data and fix the neutralize script. Build Error: 231619, 231643
This update improves several business workflows: safer e-invoicing setup, new Danish Nemhandel invoicing support, Stripe checkout language matching, and corrected loyalty coupon handling. It also fixes editor table issues, Indonesian e-Faktur validation, point-of-sale performance, and adds updated translations.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents protected or non-editable links from being deleted when users paste text over their label. It helps preserve website menu items and other locked content, reducing accidental content loss while editing.
Original PR description
When the label of a link is fully selected and the user pastes some text, the link is removed. It was removed even if the link was in a `contenteditable=false` or was unremovable. This commit only…
When the label of a link is fully selected and the user pastes some text, the link is removed. It was removed even if the link was in a `contenteditable=false` or was unremovable. This commit only attempts to remove the link element after checking these conditions. It also only selects the link in the `before_paste` handler, and lets the normal paste logic remove it. Steps to reproduce (after 18.4, where it was noticed): - Copy some simple text - Open website builder - Select completely the label of a menu in the header - Paste - Bug: the menu item is removed, and replaced with simple text Steps to reproduce (in 18.0 and later): - Open "To-Do" app - Add a link in the middle of a line of text - With inspector, edit html to put `contenteditable="false"` on the container of the line, and `contenteditable="true"` on the link - Select completely the label of the link in the document - Paste some text - Bug: the link is removed, and the clipboard content is inserted after the non editable element task-5110141 Forward-Port-Of: odoo/odoo#229558 Forward-Port-Of: odoo/odoo#228223
This update adds safeguards to verify that text formatting shortcuts, such as bold or underline, behave correctly when no text is selected. It helps ensure the editor stays clean and avoids unnecessary undo history entries, improving editing reliability without changing visible features.
Original PR description
Description of the issue this PR addresses: This PR adds test cases for formatting shortcuts (e.g., Ctrl+B) on a collapsed selection. An empty inline tag is inserted temporarily and auto-cleaned if unused, so no individual history step are created. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229429 Forward-Port-Of: odoo/odoo#229233
This update adds extra logging to an internal bus notification test that has been failing unpredictably. The added detail should help developers identify the root cause faster, with no direct change to customer-facing behavior.
Original PR description
The `test_postcommit` test ensures that the creation of several bus records result in a single postgres notify after commit. This test have been failing in a non deterministic fashion for some time. Theorical fixes have been try, but fails still persist. This commit adds some logs to this test to better understand what's happening. runbot-232798 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228996
This removes a redundant database rule in Odoo's mail discussion channels. The change helps prevent failures when creating or migrating future databases on PostgreSQL 18, without changing how users work with mail channels.
Original PR description
The field is `required=True`, which automatically sets it `NOT NULL` (if possible). The constraint does not do anything useful. Furthermore, pg18 promoted `NOT NULL` to "real" named constraints[1],…
The field is `required=True`, which automatically sets it `NOT NULL` (if possible). The constraint does not do anything useful.
Furthermore, pg18 promoted `NOT NULL` to "real" named constraints[1], and the constraint was created following the pattern pg uses, so trying to migrate a database to pg18 (either upgrading a cluster from 17 to 18 or restoring a db on a pg18) the restoration fails with
duplicate key value violates unique constraint "pg_constraint_conrelid_contypid_conname_index"
The easiest fix is to delete the constraint in the upstream DB if possible (I didn't find a way to filter out constraints from pg_dump or pg_restore, though it should be possible to filter it out from a "plain" dump by hand).
AFAIK Odoo does not generally drop constraints so I don't think this will fix existing databases, but it at least makes future databases compatible with pg18.
[1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a379061a22a8fdf421e1a457cc6af8503def6252
Forward-Port-Of: odoo/odoo#229539
Forward-Port-Of: odoo/odoo#229274The checkout now blocks carts from combining one-time purchases with subscription products and shows a warning when customers try. This prevents confusion where one-time items could appear as recurring subscriptions, helping customers better understand what they are buying.
Original PR description
**Version:** - saas-18.4 **Steps to reproduce:** - Create a one-time product. - Add the one-time product to the cart. - Add a subscription (recurring) product. - The one-time product is incorrectly shown as a subscription. **Issue:** - When a customer adds a one-time product to the cart and then adds a subscription product, the one-time product incorrectly gets treated as a subscription. **Solution:** - If the cart already contains a one-time product, the system will show a warning and block adding subscription products (and vice versa). **Impact:** - Customers can clearly understand whether they are buying a one-time product or a recurring subscription, without mixing them by mistake. Task-5046146 Forward-Port-Of: odoo/enterprise#93282
Italian ENASARCO taxes are now correctly treated as both withholding and pension fund contributions. This ensures invoices generate compliant electronic XML data and that the correct withholding setup is available immediately after installing the Italian localization modules.
Original PR description
* = l10n_it, l10n_it_edi, l10n_it_edi_withholding The ENASARCO tax works both as a Withholding (negative) tax and as a Pension Fund tax. It must appear in the XML in both sections DatiRitenuta and CassaPrevidenziale. - We modified the master data to amend this error. Now the correct Withholding type appears right after installing the module. - Since there was an explicit check on taxes being both, we removed it. - Removed an exception where ENASARCO taxes were allowed to have positive values Forward-Port-Of: odoo/odoo#228322 Forward-Port-Of: odoo/odoo#226357
RFQs created from Blanket Orders now keep the original unit of measure and price on each product line. This prevents incorrect or confusing values when the same product appears with different units or prices, improving purchasing accuracy.
Original PR description
## **Purpose:** When creating an RFQ from a Blanket Order, the product lines did not retain the UoM and price from the Blanket Order. This caused RFQs to display incorrect values, which could confuse users, especially when same product had multiple lines with different UoMs and prices. ## **With This Commit:** RFQs generated from Blanket Orders now correctly preserve the UoM and price from the original Blanket Order. This ensures consistency and accuracy, giving users the expected values in the RFQ lines. task - 5075869
This update narrows an automated checkout test so it focuses on verifying public access rather than trying to mimic very fast user actions. It helps avoid inconsistent test results where two orders could be created at once, improving confidence in click-and-collect stability without changing customer-facing behavior.
Original PR description
Tours are too fast for imitating the user actions that led to sometimes creating 2 orders in parallel instead of reusing the first created. The test was added for b395f984b13eb83310024b9fa94d7822211ef8c1 fix, so with this commit, we keep the test more specific to the fix and avoid inconsistent behavior. Forward-Port-Of: odoo/odoo#229630 Forward-Port-Of: odoo/odoo#218417
Fixed an issue where previewing the portal user invitation email could fail because the template used user details that were missing for portal users. The invitation preview now uses the related contact information, so staff can review portal invite emails reliably before sending them.
Original PR description
[FIX] portal: display template for portal invite Steps to reproduce: ---- - Install portal module - Grant a portal access to a contact - Go to the email template (Portal: User Invite) for the contact - Click on Preview -> Traceback Issue: --- The display was based on the user itself referencing to a partner. And there was no name for the portal users. Fix: --- Changed the view so now the different values are based on the partner.Also added the name to this function based on the partner name. opw-4444729 Forward-Port-Of: odoo/odoo#217791 Forward-Port-Of: odoo/odoo#194322
This fixes an issue in the website editor where deleting text in pricelist snippets could accidentally merge a description with its price. Website editors can now adjust pricelist content more safely without breaking the layout or confusing customers.
Original PR description
**[FIX] website: keep pricelist blocks intact** Build the unsplittable selector from the three pricelist snippet base classes so that the HTML editor no longer splits or merges their item, price, or description elements when users delete content with Backspace. Steps to reproduce: - Drag and drop a pricelist snippet (e.g., Pricelist Cafe). - Place the cursor before the first letter of one of the descriptions. - Press Backspace. - Bug: the description content is merged with the price. task-5117864 Forward-Port-Of: odoo/odoo#229227
This fixes an issue where increasing a sales order quantity after using a custom warehouse route could create an additional delivery for the wrong amount, or fail to create one at all. Businesses using multi-step deliveries and personalized routes will now get accurate replenishment and delivery quantities when sales orders are updated.
Original PR description
**Steps to reproduce:** - enable multi-step routes setting. - navigate to warehouse management/locations create a new location (the "test location"). - select "internal location" for the location…
**Steps to reproduce:** - enable multi-step routes setting. - navigate to warehouse management/locations create a new location (the "test location"). - select "internal location" for the location type. - select WH for the parent location - navigate to warehouse management/warehouses and select the warehouse corresponding to WH. - set the warehouse in 3 steps delivery. - click on the routes smart button. - click on the "deliver in 3 steps (pick+pack+ship)" route. - add a rule, for the action select "push to", for the operation type select "internal transfers", for the source location select the "test location" you just created and for destination location select "WH/Output". - save. - create a storable product and set an on-hand quantity - create a new sale order for 1 quantity of this product and confirm it - click on the picking smart button, change the destination location to the test location and validate - open the sale order and change the quantity to 3 **Current behavior:** A new picking is created from stock to packing zone (which is the expected behavior) but the quantity is 1 **Expected behavior:** The quantity should be 2. If we only increase the quantity by 1 on the sale order it does not even create the new picking **Cause of the issue:** The warehouse_id field is invisible in stock.rule form view when the action is push. Therefore, the rule is created without a warehouse_id. Also, moves created from a rule have the same warehouse_id as the rule. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/models/stock_rule.py#L275 So, when we validated our first move (from stock to the test location), this created a second move (from test location to output) that does not have a warehouse id (because it was created from our own push rule that we created). When we update the quantity of the sale ordre line, _action_launch_stock_rule calls _get_quantity_procurement to compute the current quantity on the moves. This method then calls _get_outgoing_incoming_moves to get the initial move created from the rule. In this case this should return only the first move created. But because the second move does not have a warehouse_id, it's rule.id is added to triggering_rule_ids. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L315-L317 And the move is later added to the outgoing moves that will be returned. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L322-L329 So the two moves are returned and the sum of the quantities of the moves is 2 instead of 1. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L292-L294 So the product quantity for the procurement will be 1 (3-2) instead of 2 (3-1). https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L386 opw-5039249 Forward-Port-Of: odoo/odoo#229332 Forward-Port-Of: odoo/odoo#227421
The Google Calendar integration was updated to use Odoo's current internal context handling. This keeps the integration aligned with recent platform changes and helps avoid future compatibility issues, with no expected change to everyday user workflows.
Original PR description
after this PR: https://github.com/odoo/odoo/pull/193636 self._context usage has been deprecated in favor of self.env.context. This commit updates google_calendar accordingly. <img width="1916" height="447" alt="image" src="https://github.com/user-attachments/assets/622de21e-7c4c-4efc-8cff-045704934f04" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The payslip list now displays relevant action buttons even when those actions are not preconfigured in the list controller. This helps payroll users access the expected options directly from the list view and avoids missing workflow actions.
Original PR description
This commit fixes the display of conditional buttons in the payslips list view. The issue was that only buttons with actions defined in the list controller were displayed. This commit fixes the issue by displaying any button if the action is not specified in the list controller. Forward-Port-Of: odoo/enterprise#95527
Invoice PDFs now correctly include both the product name and any manually added or edited description. This prevents missing product information on customer-facing invoices and helps keep printed documents clear and complete.
Original PR description
Before this commit, When printing an invoice for a product with a manually added or edited description, only the description appeared in the PDF. Technical Reason: In commit https://github.com/odoo/odoo/commit/4f839fad0fb20688a740282e4172dbffa095fc51, the `updateLabel` function was added, which was used everywhere until version 18.4. From version 19 onward, it was replaced by `parseLabel` in https://github.com/odoo/odoo/commit/bc6592a8514d6557037868a0f42265070fa02263. As a result, the previous function no longer works. After this commit, Both product name and description will be displayed properly in the invoice PDF. task-5109497
The German POS certification integration now sends payment amounts in the format required by Fiskaly, preventing payment validation errors. It also avoids creating unnecessary zero-value payment lines caused by rounding when similar payments are combined.
Original PR description
This ticket fixes two bugs: ### Problem 1 Fiskaly requires `amounts_per_payment_type` values to be strings with 2 to 5 decimal places. After this PR: https://github.com/odoo/enterprise/pull/83300, amounts started being sent as numbers, which caused bad request error when paying a PoS order in version 19.0. ### Solution 1: Restore the use of `.toFixed(2)` to ensure amounts are sent as strings. ### Problem 2 When adding two payment lines with decimal amounts using the same payment method, the system merges both payments into a single line by adding the second amount to the first. This can cause a rounding difference and may trigger sending an additional payment line to Fiskaly with a 0.00 amount. ### Solution 2: Check if rounded change is zero before creating the change line. opw-5115157
Closing or reopening rental subscriptions for products sold as kits now keeps the delivered quantity accurate. This prevents incorrect return errors that could block users from closing subscriptions after validating deliveries.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable rental transfers; 2. have a rental product with a kit BoM; 3. create a subscription order in the Rental app; 4. add the rental product; 5. confirm…
Versions -------- - 18.0+ Steps ----- 1. Enable rental transfers; 2. have a rental product with a kit BoM; 3. create a subscription order in the Rental app; 4. add the rental product; 5. confirm order; 6. validate deliveries; 7. close the subscription. Issue ----- Invalid SQL command, cannot return more than was delivered. Cause ----- When closing or reopening a subscription, the `_compute_qty_delivered` method gets triggered. By default, these methods required the relevant moves to have the same `product_id` as the sale order line. For products with kit BoMs, the move's `product_id` is tied to the BoM instead of the final product, leading to `qty_delivered` getting reset reset to 0 on recompute. This causes an error, as `qty_returned` is non-zero. Solution -------- The `qty_delivered` for these lines was set in the `_action_done` method of `stock.move`. By instead moving this logic into a `_compute_qty_delivered` override, any recompute should have the same result, instead of getting reset to 0. opw-4833280 Forward-Port-Of: odoo/enterprise#96179 Forward-Port-Of: odoo/enterprise#88691
Fixed an issue that could cause website-generated product imports to fail when adding multiple images to a product variant. This helps teams import product catalogs more reliably without interruptions from image handling errors.
Original PR description
Fixed a typo that leads to a crash when importing multiple images for a product variant Forward-Port-Of: odoo/enterprise#96134
French FEC exports now skip invoice note and section rows that are not linked to an accounting account. This prevents non-accounting lines from appearing in official accounting export files, improving accuracy and compliance for French localization users.
Original PR description
Step to reproduce: - for l10n_fr Localization - Create a customer invoice and add a note or Add a section . - Go to accounting > reporting > FEC - Export FEC (don't exclude 0 lines) Obseravtion: - The journal items with note and section will be included in the FEC Cause: - for Fec report, we consider move_line which do not have account_id linked to it, due to left_join, hence lines with display_type line_note or line_section are included Fix: - use `join` instead of `left_join` - **v17.0, when the behaviour was as expected** https://github.com/odoo/odoo/blob/3d3898b442379d7416da0ee7e363b6587c725218/addons/l10n_fr_fec/wizard/account_fr_fec.py#L194-L196 opw-5079457 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227817
This fixes an issue that prevented users from deleting an employee version from the versions list. HR teams can now manage employee history records without seeing an incorrect warning that the record no longer exists.
Original PR description
Issue/Current Behavior: It is not possible to delete a version of an employee. Steps to Reproduce: 1. Create an employee. 2. Create a new version of the employee. 3. Click on the smart button of versions and delete a record from the list view. 4. It gives warning that the record doesn't exist or might be deleted. Solution: Fixed the issue by checking that the context version exists or else the empty recordset. task - 5002995 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224585
Discarding a quality worksheet wizard no longer creates a worksheet record or makes the quality check appear completed. This prevents incorrect quality status updates when users open a worksheet by mistake and cancel out.
Original PR description
**Problem:** Opening the worksheet wizard and discarding it makes the worksheet "completed" **Steps to reproduce:** - create a quality check - set a product - in type select worksheet - select the "quality issues" template - select a team - click on the worksheet smart button - discard **Current behavior:** the worksheet is marked has completed **Cause of the issue:** when discarding, this line causes the creation of an instance of worksheet.template linked to the quality.check via its worksheet_template_id https://github.com/odoo/enterprise/blob/a1dd58f2b59ecd2d22efd29eb0aace7bdca64f66/quality_control_worksheet/static/src/views/quality_worksheet_fromview.js#L35 which will make the worksheet_count field of the quality check worth 1 after discarding https://github.com/odoo/enterprise/blob/1c5e547b59a57c840ef72b2e76c6a6a627f1f18e/quality_control_worksheet/models/quality.py#L37-L39 opw-4980945 Forward-Port-Of: odoo/enterprise#95219
Invoices using the UAE localization now print with properly aligned columns even when invoice lines have no taxes. This prevents confusing or unprofessional invoice layouts for businesses issuing tax-free invoices.
Original PR description
**Steps to reproduce:** 1- Install UAE localization (l10n_ae). 2- Create an invoice without adding any taxes in the invoice lines. 3- Print the invoice → column alignment is broken. **Issue:** In UAE…
**Steps to reproduce:** 1- Install UAE localization (l10n_ae). 2- Create an invoice without adding any taxes in the invoice lines. 3- Print the invoice → column alignment is broken. **Issue:** In UAE localization, the invoice report shows misaligned columns when the tax field is empty. **Cause:** Since Odoo 18.4, the core report logic hides the tax column when no taxes are applied. However, l10n_ae does not handle this scenario properly while replacing columns, which results in broken alignment. **Solution:** Added a condition in l10n_ae to correctly handle the case when the tax field is empty, ensuring column alignment is maintained in the invoice report. **Before Fix:** <img width="777" height="326" alt="image" src="https://github.com/user-attachments/assets/1416c03a-9da5-45fe-8ade-2a9037f70812" /> **After Fix:** <img width="767" height="341" alt="image" src="https://github.com/user-attachments/assets/9d418945-45e2-409e-b00e-b4f8272ea013" /> opw-4965240 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224034
Restores access to individual account reports and monthly payroll menu entries in the Swiss payroll module. This ensures payroll teams can again find and use these reporting options as expected.
Original PR description
… menuitems Forward-Port-Of: odoo/enterprise#95929
This update fixes a failing automated test in the Mexican electronic stock localization by creating the needed vehicle record with the correct permissions. It helps keep validation checks reliable after vehicles moved under fleet management, with no expected change for end users.
Original PR description
Since the latest changes to the model, vehicles are now managed from the fleet app. However, there is an error in the tests because the default test user does not have the necessary permissions to create fleet.vehicle model records, as the module flow does not include adding logic to fleet or new permissions. To fix this, the fleet vehicle record is created with superuser permissions. See: https://runbot.odoo.com/odoo/error/232645 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves how manufacturing by-products are shown and handled in Shop Floor. Users now see the right by-products in the right place, clearer quantities, fewer irrelevant location details, and a more direct way to create tracked by-product quantities.
Original PR description
Shop Floor by-products fixes: - show by-products not linked to a workorder only on mo card - do not show locations for by-products - always show quantity done / to consume quantity - clicking (+) on tracked by-products now opens the create quant dialog rather than the quants list view task: 4781451 Forward-Port-Of: odoo/enterprise#96059 Forward-Port-Of: odoo/enterprise#91341
Selecting table cells in the HTML editor now correctly disables the link button, preventing users from trying to add links where that action is not supported. The change also improves single-cell selection behavior so a cell is selected only when its full content is selected, making table editing more predictable.
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Create a 3 x 3 table. - Select first column. The link button in toolbar is enabled and it should not. This happens because after merging this commit [1], `isLinkAllowedOnSelection` method returns true if selected cells are not adjacent. **Desired behaviour after PR is merged:** Now, selecting cells open toolbar with disabled link button. [1]: https://github.com/odoo/odoo/commit/c0d07fdcf4cc139177524eb4ea22ab341b3da7fb task-4965270 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221033
Fixed an issue that could cause the Sales dashboard to crash when opened without the subscription module installed. The dashboard no longer relies on a subscription-only field, improving reliability for Sales users.
Original PR description
The system will crash when the user opens the dashboard module.
**Steps to produce:**
- Install the `Sales` module with demo data.
- Open the dashboard module.
**Error:**
```py
KeyError: 'recurring_invoice'
ValueError: Invalid field product.template.recurring_invoice in condition ('recurring_invoice', '!=', True)
```
**Cause:**
- From this [PR], the field `recurring_invoice` is being used in the `spreadsheet_dashboard_sale` module. However, this field is actually defined in the `sale_subscription` module. Since `spreadsheet_dashboard_sale` does not currently listed `sale_subscription`in its `depends`.
**Solution:**
- In this PR, I have removed the reference from the domain from `spreadsheet_dashboard_sale` module.
[PR]: https://github.com/odoo/odoo/pull/225542
**sentry-6912254481**This fix updates Chilean bank reference data to use a stable country identifier instead of relying on the country name. This prevents module installation or upgrade failures when country names have been customized or corrupted in a database.
Original PR description
`res.country` records are `noupdate` by default, which means that changes such as the following are not reverted: ```SQL pied@(none):pied_3131231> SELECT c.name->>'en_US' FROM res_country c JOIN…
`res.country` records are `noupdate` by default, which means that changes such as the following are not reverted:
```SQL
pied@(none):pied_3131231> SELECT c.name->>'en_US' FROM res_country c JOIN ir_model_data d ON d.res_id = c.id AND d.model = 'res.country' AND d.module = 'base' AND d.name IN ('cl', 'co')
+----------+
| ?column? |
|----------|
| COLOMBIA |
| Colombia |
+----------+
```
Note: in this specific, the change is clearly an error introduced in the data. Still, the error it produces (which follows) can be avoided by referring to the xmlid, instead of the record name.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-18.4/odoo/service/server.py", line 1410, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'])
File "<decorator-gen-6>", line 2, in new
File "/home/odoo/src/odoo/saas-18.4/odoo/tools/func.py", line 89, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/registry.py", line 175, in new
load_modules(
File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 455, in load_modules
load_module_graph(
File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 226, in load_module_graph
load_data(env, idref, 'update', kind='data', package=package)
File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 79, in load_data
tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/src/odoo/saas-18.4/odoo/tools/convert.py", line 624, in convert_file
convert_csv_import(env, module, pathname, fp.read(), idref, mode, noupdate)
File "/home/odoo/src/odoo/saas-18.4/odoo/tools/convert.py", line 680, in convert_csv_import
raise Exception(env._(
Exception: Module loading l10n_cl failed: file l10n_cl/data/res.bank.csv could not be processed:
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
```
upg-3131231
Forward-Port-Of: odoo/odoo#229435
Forward-Port-Of: odoo/odoo#229218The user form now keeps the login editable after a user is created while avoiding duplicate-looking email and login fields when they match. In HR, the same behavior applies using the employee work email, making account updates clearer without adding unnecessary clutter.
Original PR description
We want to allow users to edit the login even after the user is created. However as the email is usually the same as the login we don't want to be too noisy by having duplicate values. If the email and login field are the same: only show the login field If the user goes to the user form and modifies the "email" (actually login) both fields will appear and they will be able to modify each independently. Same logic is applied to hr with user.work_email replacing user.email task-5130854
Field service sales order lines now recalculate their prices when a task's warranty status is turned on or off. This prevents items from incorrectly staying at zero price after warranty is removed, helping ensure accurate customer billing.
Original PR description
### Steps to reproduce:
- Create a sales order linked to the customer
- Assign a customer (partner) to the task and link the task to the sales order
- Create a sales order line for a product and link it to the task
- Verify the price unit matches the product's list price by default
- Set the task as under warranty
- Add or remove an item from SOL
- Verify the price unit is set to 0.0 in the sales order line
- Unset the warranty status
- Add an item to the SOL
### Cause:
When setting the task as under warranty we modify the price of each SOL to 0.0 but when unset the warranty option we try to fetch the prices from the SOL which we already set it to 0.0
### Fix:
Backporting https://github.com/odoo/enterprise/pull/85492/commits/8615fad5b75d32483b25cf9b1525883e7a730fac to check when writing on the under_warranty value we recompute the SOL prices
opw-4579404
Forward-Port-Of: odoo/enterprise#96045DHL delivery insurance settings are now applied when estimating shipping costs and creating shipments. This helps businesses charge correctly for insured deliveries and alerts users when insurance is not available for a route.
Original PR description
**PROBLEM** Insuring a delivery using the dhl carrier don't work. It doesn't affect the estimated rate of the delivery, and the shipment created when validating the delivery order isn't insured.…
**PROBLEM** Insuring a delivery using the dhl carrier don't work. It doesn't affect the estimated rate of the delivery, and the shipment created when validating the delivery order isn't insured. **STEP TO REPRODUCE** 1. Install the `delivery_dhl_rest` and the `l10n_be` modules (we will use the be demo company). 2. Set the insurance percentage of the dhl be delivery method to 100%, and set the region to Europe (the demo data is incorrect), and activate the debug (click the "No Debug" smart button to activate the log of requests). 3. Switch to the be company. 5. Create a sale order, with a customer located in Belgium, and add shipping using the dhl method. 6. Go to the delivery order, and validate it. 7. Go to settings/Technical/Logging and look at the rating_request and shipment_request, notice there is no information about insurance. **CAUSE** We don't send any info about insurance in the api requests. **FIX** Computing and sending the insured amount, only if the insurance percentage is not null. If the package can't be insured between the origin and the destination, a error message will be displayed when updating the delivery price. **TESTS PROBLEM/FIX** The localization of `your_company` was not recognized by DHL, leading to the DHL api returning a 0 delivery price. Switching the localization to Eghezee, Rue du Laid Burniat 5 fixes this. Assertion regarding the delivery price were restored. The picking date could sometimes be refused by DHL (stop working after arround 4/5 PM). Changing the picking date to, two day after, at noon works. `test_01_dhl_basic_be_domestic_flow` was modified to also test domestic shipment insurance in addition of the basic flow. Some code in it was refactor into inner function to avoid boilerplate. Adding `INSURED_RATE_MOCK_RESPONSE` to mock response in test_01. opw-4989281 Forward-Port-Of: odoo/enterprise#93105
1 change
Resolved issues and error corrections
The Ask the Community button now opens the correct forum page for helpdesk teams with community forums enabled. This prevents customers or agents from hitting a 404 error when trying to access community support.
Original PR description
Scenario:
- create a helpdesk team
- enable community forum on it
- go to the team and click on "Ask the community"
Result: 404 error, this page does not exist
Cause: we are using helpdesk.team ID in route needing a forum.forum ID
Fix: uses /helpdesk/{team ID}/forums route instead of /forum/{team ID}
opw-5027193
Forward-Port-Of: odoo/enterprise#960268 changes
Resolved issues and error corrections
Point of Sale loyalty discounts now calculate product-specific rewards without being reduced by separate order-level discounts. This ensures customers receive the full intended discount when multiple loyalty programs or coupons apply in the same sale.
Original PR description
**Steps to reproduce:** - Have two products, A (150$) and B (50$) - Make a loyalty program for A, 10$ reduction on the order when bought - Make another one for B, 100% reduction on B when bought.…
**Steps to reproduce:** - Have two products, A (150$) and B (50$) - Make a loyalty program for A, 10$ reduction on the order when bought - Make another one for B, 100% reduction on B when bought. Make it a coupon with a code - Open the PoS, click on A, then B, then enter the coupon code **Problem:** After those steps, the reward for buying be should be 100% of B, meaning 50$, but it is only 40$. **Why the fix:** This happens because the reward line for A was taken into account when computing B's reward value. Meaning that the original 50$ was taking the -10$ into account, thus making it 40$. We now check if the current product is in all_discount_product_ids, and do not go through the next step if it is. This attribute represents all the products that the current reward applies to. So this means that if the current product is in the products the reward applies to, we do not add it to the lines to discount. With this condition, we prevent a reward from discounting a product it already applies to again. With this fix, we exclude the reward lines that target one of the products the reward targets. This ensures that any line directly associated with a discounted product are not considered. opw-4970441
Very small negative amounts that round to zero now display as 0.00 instead of -0.00. This avoids confusing signs in Luxembourg reports and keeps rounded monetary values clearer for users.
Original PR description
float_repr(-0.00000001, 2)
formatFloat(-0.00000001, { digits: [16, 2] })
Before: "-0.00"
After: "0.00"
opw-4685953
closes odoo/enterprise#90992
Related: odoo/odoo#219913Point of Sale loyalty rewards now only grant points when an order meets the program's item quantity rules. This prevents customers from receiving undeserved points or losing too many points when redeeming rewards such as free products.
Original PR description
Loyalty points were not being awarded correctly for some orders. The system granted points even when the minimum required quantity of items was not reached. In some cases, it also added negative…
Loyalty points were not being awarded correctly for some orders. The system granted points even when the minimum required quantity of items was not reached. In some cases, it also added negative loyalty points, which led to an excessive deduction for the customer —sometimes just for claiming a single free product. > Setup of the Loyalty Program (Discount & Loyalty): Program Type : Loyalty Card Rule : minimum 5 items => 10 Loyalty Points per $ Reward : Free product (Simple Pen) => in exchange of 5 Loyalty Points Steps to reproduce: ------------------- * Open the pos Shop * Select a customer with loyalty points * Add a Simple Pen * Click on * Reward > Free Product - Loyalty Program > Observation: Customer shouldn't 'win' points here New Total is mathematically correct but not logic Why the fix: ------------ We need to verify that the order is eligible to generate reward points based on the configured rules, before adding the won points. opw-4914774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where a manually adjusted delivery date on an invoice could be reset after changing product quantities and confirming the invoice. This helps preserve user-entered delivery information and avoids confusion in sales and invoicing workflows.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a sale order with deliverable products & no payment terms; 2. confirm order & validate delivery; 3. create an invoice; 4. modify the delivery date; 5.…
Versions -------- - 17.0+ Steps ----- 1. Have a sale order with deliverable products & no payment terms; 2. confirm order & validate delivery; 3. create an invoice; 4. modify the delivery date; 5. save changes; 6. change product quantity of a line & confirm invoice. Issue ----- The delivery date got reset. Cause ----- The `_compute_show_delivery_date` method gets called, which triggers the recomputation of the `_compute_delivery_date` due it the latter having `line_ids.sale_line_ids.order_id` as its `depends`. Due to the way how `depends` works, if any of the fields in the record chain gets modified, the compute gets triggered. In this case, because we modified a `line_ids` record by changing the quantity, it will therefore recompute the delivery date, overwriting the custom value. Solution -------- As we only want the delivery date to be recomputed when the `effective_date` on the order changes, we should add it to the `depends` to trigger the compute in that scenario. In other scenarios, e.g. modifying the move or one of its lines, we don't want to trigger a recompute, which we can achieve by always including `delivery_date` via `_get_protected_vals` on create/write. opw-4996654
This update fixes an internal test issue that occurred only when an optional file-detection library was installed. It helps keep automated checks stable, reducing noise for developers without changing customer-facing behavior.
Original PR description
This tests are failing when python-magic is installed. Leftover of #223609 Runbot error 231171
Odoo now correctly recognizes incoming non-bounce emails from existing contacts and clears their previous bounce status. This helps prevent valid contacts from remaining marked as unreachable and avoids related discussion channel membership issues when replying by email.
Original PR description
Incoming bounce email linked to a partner in the db is incrementing (in `message_receive_bounce`) the message_bounce value during the handling of the bounces (in `_routing_handle_bounce`) If later, an email linked to a partner existing in the db (and having a message_bounce > 0) is received (and not bounce). The `_routing_reset_bounce` is called to reset the message_bounce. However, prior to this fix, due to not normalizing the `email_from` contained in the `msg_dict`, well, the record having this value was never found and thus, not reset to 0. In 4935208, some of the user were unlinked for mail.discuss.channel when replying to one of the received email. opw-4935208 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
SEPA direct debit payments now correctly verify whether a customer mandate is still valid before using it for token payments. This prevents valid future-expiring mandates from being wrongly rejected and helps avoid unnecessary payment failures.
Original PR description
The check to ensure that the mandate used in a token payment is still valid had two issues: - It was comparing a date (the mandate's end date) with a datetime. - It was incorrectly rejecting mandates expiring in the future, while it should have done the opposite.
Users who close the email validation banner will no longer see it return unexpectedly. This reduces confusion after email validation and makes the profile experience behave as expected.
Original PR description
### Issue 1: The validated email success banner wasn’t triggering the RPC call because Bootstrap’s `data-bs-dismiss="alert"` removed the element from the DOM before the handler could run. ### Issue 2 Closing the banner previously triggered `/profile/validate_email/close` RPC, which reset `validation_email_done` to false. This mistakenly caused the “email sent” banner to reappear, confusing users. ### Solution - Overwrite Bootstrap’s `close.bs.alert` event to trigger the RPC when the success banner is dismissed. - Set `validation_email_sent = False` so the banner stays hidden after being closed. Task-5049533