Daily updates from Odoo
Navigate
Branch
Friday, October 3, 2025
253 changes
7 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
11 changes
New functionality added to Odoo
Odoo can now synchronize Romanian e-Factura messages with ANAF to update invoice and bill statuses and retrieve official documents. It can also automatically create or validate vendor bills from ANAF data, reducing manual entry and duplicate processing.
Original PR description
Backport of the odoo/odoo#208082, adding the possibility to synchronize invoice and bill status at once. The endpoint `ListaMesajeFactura` returns a list of messages to process. Those messages can: -…
Backport of the odoo/odoo#208082, adding the possibility to synchronize invoice and bill status at once. The endpoint `ListaMesajeFactura` returns a list of messages to process. Those messages can: - Return an invoice status update with a success or an error; - Return a new bill from another vendor already validated by the authority. The messages contain a message ID to recover and download the official data from the ANAF server: the invoice/bill XML and the signature. (documentation)[https://mfinante.gov.ro/static/10/eFactura/prezentare%20api%20efactura.pdf] When synchronizing, we retrieve the new messages from the last 24 hours and update the database content accordingly: - in case of invoice status update, update the relevant invoice/bill status and download the signature in case of success (note that this was already done before, we only call the relevant methods to do so); - in case of a new vendor bill, we download the bill XML and signature, create a new in_invoice move and fill it up with the XML content. In case a bill with the same index is already in the database, we do nothing to avoid duplicate. If a similar bill (same date and amount) is found but not yet validated, we only validate it. The synchronization can be triggered manually through the option in the list view and it is automatically triggered every 4 hours with a CRON. Lastly, the created bill journal can be set up in the Accounting settings so that users can specify their favorite journals for automated ANAF bills. task-4891081 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229450 Forward-Port-Of: odoo/odoo#221324
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
11 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
37 changes
Security fixes and vulnerability patches
Sensitive Saudi payroll fields are now only visible to authorized payroll users. This helps protect employee compensation-related information and restores the expected access controls.
Original PR description
Some payroll-related fields in the Saudi HR localization (hr.version form view) were missing group restrictions. As a result, non-payroll users could see sensitive fields such as: - l10n_sa_iqama_annual_amount - l10n_sa_medical_insurance_annual_amount - l10n_sa_work_permit_annual_amount This broke the payroll access test (test_payroll_fields_access), which ensures sensitive payroll information is only visible to users in the Payroll group. We add the missing groups="hr_payroll.group_hr_payroll_user" restriction on these fields in the form view so that only authorized users can access them. build_error-231290
Enhancements to existing features
Equity notice and UBO request emails now use a more consistent Odoo-style layout and keep important action buttons fixed so links are not accidentally changed. Users can also send equity transaction emails to both subscribers and sellers at the same time, reducing manual work.
Original PR description
This commit improves the emails sent for equity notice and UBO form request. The following improvements are applied: 1. Make the equity/UBO button fixed at the top of the email without being editable for the user (to not mess up the token) 2. Make the rendered email look more odooish (used mail_notification_light) 3. Allow for sending to subscriber and seller at the same time in an equity transaction task-5123366
Updates the Uruguay electronic invoicing flow to provide clearer notifications when sending invoices. This helps users better understand the status of their electronic documents and any follow-up actions needed.
Original PR description
see https://github.com/odoo/odoo/pull/224267 Forward-Port-Of: odoo/enterprise#95366
Odoo now skips creating a return when an existing return already covers the full reporting period. This reduces duplicate filings and unnecessary work across accounting and localization reports.
Original PR description
Now, we dont generate returns if they already cover the entire period task-5066017
The signing app's automated checks were updated to match a refreshed error dialog design. This helps ensure the signing flow continues to be reliably tested after the interface change, with no direct change for end users.
Original PR description
The look and feel inspired by commit [1]. Task-5049469 [1]: https://github.com/odoo/odoo/commit/3916020e131008f3d529df61ad88f603874fd7d0
Product categories generated for the website can now include their available cover images. This helps create richer, more visually appealing online shop pages with better category presentation.
Original PR description
Also add the cover_image for the product category if available Forward-Port-Of: odoo/enterprise#96135
The trial balance audit PDF now uses its own dedicated layout instead of modifying a shared reporting template. This keeps standard reports stable while ensuring audit exports include the required account status and last comment details.
Original PR description
Refactor trial balance audit export to use a custom PDF template. Previously, this [commit](https://github.com/odoo/enterprise/commit/7a240345088942773b5b81937dca8275ee0a2d07) introduced audit export in PDF by writing directly into the generic report template. This approach is problematic, as the generic template should remain untouched. This change introduces a dedicated PDF template for the trial balance audit, overriding the generic one and adding the audit-specific requirements (account statuses and a “last comment” column). task-5114211
This update improves the generic chart of accounts by clarifying account names, correcting small wording issues, and making key financial report sections easier to understand. It also improves reporting accuracy by adding credit card liabilities to the balance sheet and ensuring other expenses are properly included in profit and loss reporting.
Original PR description
Improvements:
- Add a space before parentheses in the "Accounting Import" block in settings.
- Change the domain of the Accounting Setting "Deferred expense" to accept not only
type = Current Assets but also type = asset_prepayment.
- Fix typos in 101300, 121000, and 211000 Accounts Receivable and Payable
(add missing "s").
- Rename accounts for clarity:
- "101701 Liquidity Transfer" → "101701 Funds in Transit"
- "110100 Stock Valuation" → "110100 Inventory Valuation"
- "151000 Fixed Asset" → "151000 Fixed Assets"
- Remove "Plus" and "Less" from the P&L and Balance Sheet section titles.
- Add a "Credit Card" section (type = liability_credit_card) inside the
"Current Liabilities" section in the Balance Sheet.
- In the Generic Profit and Loss report, ensure the "Other Expenses" section
includes accounts of type "Other Expenses" and "Depreciation"
(currently only includes "Depreciation").
task: 5048333This update improves Belgian Dimona payroll declarations by adding better status handling, automation support, and compatibility with updated government API requirements. It reduces manual follow-up and helps HR teams submit more accurate employee declarations based on contract dates and required employee data.
Original PR description
Forward-Port-Of: odoo/enterprise#95533
Messaging features in AI, WhatsApp, live chat, and helpdesk now rely on the channel information already provided by the conversation model. This makes behavior more consistent across chat windows, message actions, thread controls, and composer tools, reducing the risk of mismatched chat behavior for users.
When bills are created from multiple employee expenses, every related receipt is now synchronized with Documents. This makes expense records more complete and avoids missing receipts that could make the workflow appear unreliable.
Original PR description
When several expenses are posted, one bill is created per employee. Previously, only the main bill attachment was synchronized with Documents, leaving many expense receipts unsynced and making the feature look buggy. With this change, all relevant expense attachments are now synchronized when the bill is created from expenses, ensuring that receipts appear properly in Documents. task-4954622
This update makes service-related documentation text compatible with the new documentation page, so it can be shown clearly and consistently. It also removes an unused internal method, reducing maintenance overhead without changing day-to-day user workflows.
Original PR description
With the introduction of the /doc endpoint, we should ensure that our docstrings are ReST (ReStructuredText) compliant, so that they can be displayed properly in the documentation. Task-5139767
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
Code cleanup and technical improvements
The organizational chart functionality is being folded into the main HR app, simplifying how employee hierarchy features are delivered and maintained. This is an internal restructuring, so users should see the same capabilities with a more consolidated HR setup.
Original PR description
This commit merges the hr_org_chart module into hr. task-4925995
The Planning app’s contract-related Gantt chart code has been moved into the main Planning Gantt area. This keeps related scheduling code together, making future maintenance easier without changing the user-facing planning experience.
Original PR description
After the HR refactoring, `planning_hr_contract` was merged into the `planning` module. However, its JS customizations remained in a separate `planning_contract_gantt` folder. This commit moves that code into the `planning_gantt` folder to centralize all Gantt logic. task-4926655
27 changes
Enhancements to existing features
Point of Sale now blocks keyboard-based order line changes while a popup is open, such as customer selection, notes, or coupon dialogs. This reduces accidental order changes and makes checkout interactions safer and more predictable for staff.
Original PR description
Before this commit: - Even when a popup (e.g., customer selection, note, coupon) was open, unfocused keyboard inputs could still update orderline values. After this commit: - Orderline editing via keyboard is disabled whenever a popup is active. - Prevents unintended changes and ensures a safer user flow in POS. Task-5033716 Forward-Port-Of: odoo/odoo#229479 Forward-Port-Of: odoo/odoo#226300
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
4 changes
Security fixes and vulnerability patches
This fix prevents Helpdesk tickets from being linked to a customer belonging to a different company. It protects multi-company data visibility so users only see and access tickets appropriate to their company.
Original PR description
**Issue**: It is possible to associate a partner that belongs to a different company than the ticket’s company. As a result, some users could see tickets in the list view that they should not have access to. When attempting to open those tickets, an error was raised. Even worse, in some cases (see the associated ticket), certain users were still able to access them. **Steps to reproduce**: - Create two companies (A and B) - Switch to company A - Open the Helpdesk application - Create and open a ticket - Select both companies A and B - Assign a partner linked to company B to the ticket - Save it opw-4926497 Forward-Port-Of: odoo/enterprise#93201
New functionality added to Odoo
Adds a dedicated warranty module to help businesses track warranties for delivered products by serial or lot number. This gives customer-facing teams a centralized view of warranty history, related maintenance tasks, and product serial information.
Original PR description
In Odoo, there is not enough to help users managing the warranties, maintenance and tracked serial numbers. This commit adds a new product warranty module to track the warranty of delivered lots. This will centralize the link with Tasks and serial numbers for history overview by adding a specific view on the customer. task-4100027
Enhancements to existing features
The Brazilian Avatax setup now shows the correct LC116 Code label when configuring services, instead of the product-focused Mercosul NCM Code label. This reduces confusion for users entering fiscal information for services while keeping product setup unchanged.
Original PR description
Purpose:- - In Brazil, NCM is a code that has an acronym to specify the Mercosul Common Name for products, and for services, the right name is LC116 (Complementary Law 116), which specifies the federal code for a service. - But we have the same field `l10n_br_ncm_code_id` to configure both NCM for goods and LC116 for services and the same table can be used for both the cases. - So while configuring fiscal information for a service, user don't understand why it still shows the NCM label instead of LC116. Before this commit:- - Label `Mercosul NCM Code` was displayed for services confusing users. After this commit:- - Label `Mercosul NCM Code` is replaced with `LC116 Code` only for services. - Tooltip is also improved for better understanding. task-5096435 Forward-Port-Of: odoo/enterprise#95404
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#960263 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