Daily updates from Odoo
Navigate
Branch
Monday, November 24, 2025
250 changes
9 changes
Enhancements to existing features
This update brings back the ability to mark specific invoice lines as "No Follow-Up," so they will not trigger payment reminders. It also improves follow-up reports and customer statements so excluded items are handled consistently in views, exports, and reminder emails, while overdue status is not changed when only excluded items remain.
Original PR description
During the rework of the follow-up report, we removed the "No Follow-Up" field from journal items, making it impossible to exclude individual journal items from triggering a follow-up. In this commit…
During the rework of the follow-up report, we removed the "No Follow-Up" field from journal items, making it impossible to exclude individual journal items from triggering a follow-up. In this commit we do the following: - Re-introduce a field for that, since it is a common requirement to be able to exclude individual items from the follow-up reports. The field is stored on the journal item, but can also be toggled from the journal entry. In case of multiple installments on the invoice, toggling the field on one installment will toggle it for all installments. - Adapt the Follow-Up Report and Customer Statement variants of the Partner Ledger to add a toggle for the "No Follow-Up" field on each report line, that toggles the field on the corresponding journal item(s). - Prevent the follow-up status on the partner to change when all of the overdue journal items are marked as "No Follow-Up". - Make sure users can toggle the "No Follow-Up" setting on the invoice level when opening the "Overdue Invoices" view from the partner's "Accounting" tab. - Make sure all receivable/payable lines without a due date (either from a manual miscellaneous entry or a PoS entry) are put under the "Due" section in the Follow-Up Report instead of the "Overdue" section. Since there is no due date, they can't be overdue. - Make sure the PDF and XLSX exports of the Follow-Up Report don't include the "No Follow-Up" lines, and the customer follow up email only includes the amount of the other lines. Backport of https://github.com/odoo/enterprise/commit/74b9d2ef17e4f9a217db8432d886de2eca4baef9 and https://github.com/odoo/odoo/commit/2789a0fbfa358c5c164e44380c2a4a10e5679615 Task: 5138378 Upgrade PR → https://github.com/odoo/upgrade/pull/8864 Forward-Port-Of: odoo/enterprise#99743 Forward-Port-Of: odoo/enterprise#96627
The customer subscription portal no longer relies on a fixed list of billing periods. It now reads the available billing options directly from the system, so custom periods like daily billing can be displayed without causing errors.
Original PR description
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the…
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the billing_period_unit selection field via inheritance. However, this customization causes an error (a KeyError) when accessing the customer portal at /my/subscriptions/<int:order_id>. This is because the controller logic relies on a hardcoded list of periods and does not account for the new custom "day" value. - Screenshot Order with plan Daily: <img width="1246" height="483" alt="image" src="https://github.com/user-attachments/assets/5dc5ca0d-a2f2-434d-8183-15a0424d9f34" /> - Screenshot when trying to get in order on the website: <img width="1250" height="776" alt="image" src="https://github.com/user-attachments/assets/5b10504e-71e2-4c13-8611-39e8a41e05d1" /> Proposed Solution -------- This PR improves the subscription portal by dynamically retrieving billing periods instead of using a hardcoded list. The portal now reads the available options directly from the billing_period_unit field's selection (i.e., self.env['sale.subscription.plan']._fields['billing_period_unit'].selection). This improves maintainability, as future changes to the field's selection will be automatically reflected without requiring code modifications. This makes the portal robust and automatically compatible with any custom periods added via inheritance. - <img width="1331" height="752" alt="image" src="https://github.com/user-attachments/assets/4f7be6c3-d96b-4525-8e23-6e1323adabde" /> Forward-Port-Of: odoo/enterprise#100084 Forward-Port-Of: odoo/enterprise#99207
Resolved issues and error corrections
This fix ensures subscription deliveries are properly counted even when a product is returned. As a result, the delivered quantity on the sales order stays accurate, which improves billing and subscription tracking.
Original PR description
**Steps to reproduce** - Create a new subscription using a subscription product. Confirm it. - Run the "Sale Subscription: generate recurring invoices and payments" scheduled action to generate the delivery. Validate the delivery. - Return the delivery and validate the return. - Issue: the delivered quantity of the sale order line is not updated. **Cause** Currently, we consider a move as related to a subscription period based on the `date_deadline` field (see _get_outgoing_incoming_moves). Since `_prepare_procurement_values` is not called when creating a return, the `date_deadline` is not set on the return moves. **Change** The returns linked to a move in a subcription period will be conisdered for the computation of the delivered quantities. opw-5136406 Forward-Port-Of: odoo/enterprise#99734 Forward-Port-Of: odoo/enterprise#98690
This update stops Gantt rows grouped by read-only fields from being moved in a way that would change those protected values. It reduces the risk of users accidentally modifying important data while dragging items in planning views.
Original PR description
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping…
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO. Steps to reproduce ----- - Have 2 products - Create a MO for product 1 with a WO at work center 1, plan it - Create a MO for product 2 with a WO at work center 2, plan it - Got to Manufacturing, Planning, Planning by Work Center - Add a custom group (by product) - Drag the WO of WC2 and drop it on top of the other WO > Both the WC and the product of the second WO change Cause ----- The example problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is both readonly and stored. https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34 While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by passing it to `write` since the field is stored. This does not pose any problem for related fields that are not stored. More broadly, gantt views should not ignore the `readonly` attribute of fields. Solution ----- Add a new `o_gantt_readonly` class to all cells of rows grouped by a readonly field - and their "child" rows. For example, if the grouping is done by "Work Center > Product > Quality Check" and "Product" is readonly, rows grouped by either "Product" or "Quality Check" will be marked as readonly. When the user drags a pill, dynamically remove the class from cells of the same "child group". The class will then be added back upon pill drop. ----- Ticket: opw-4875366 Forward-Port-Of: odoo/enterprise#100088 Forward-Port-Of: odoo/enterprise#94166
This update fixes how Swiss Federal Tax Administration exchange rates are dated when imported. Rates will now be stored with the correct publication date, which prevents them from appearing a day off and keeps exchange rate records more accurate for users.
Original PR description
Steps to reproduce: - Select exchange service: [CH] Federal Tax Administration (FTA). - Add USD (or other currencies). - Fetch the new rates (click on the reload icon). Issue: Rates are returned for yesterday but stored with today’s date. Cause: The request fetches yesterday’s rates and we store the date using `gueltigkeit` (valid-until). FTA rates are typically valid until the next morning (around 7 AM) or until the next business day on weekends. Example (fetch on Fri 14.11.2025): <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> For example, if we fetch on the 14th (Friday), we get this value: <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> Solution: Query the FTA endpoint using today’s date and store the rate date from `datum` (publication date) instead of `gueltigkeit`. opw-5189127 Forward-Port-Of: odoo/enterprise#100046
This fix restores the expected payment instruction used for standard ISO 20022 payments. As a result, non-SEPA transfers will again be processed with the correct service level by default, reducing the risk of rejected or mishandled payments.
Original PR description
Since commit [[1]], the Service Level is set to NURG only when using the specific `iso20022_se` payment method. However, the previous expected behavior was to set the Service Level to NURG automatically whenever a payment was in a non-EUR currency or targeted a non-EU IBAN, regardless of the specific ISO20022 variant. This commit restores the logic to set the Service Level to NURG for all standard ISO20022 payments. This fix doesn't check anymore if a payment is in non-EUR currency or target a non-EU IBAN. Using iso_20022 activate it by default. opw-5095483 [1]: https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e Forward-Port-Of: odoo/enterprise#100061
This update prevents an error that could appear when opening a partner record after uninstalling certain e-invoicing modules. It now safely clears the related e-invoice format so users can continue working without encountering a traceback.
Original PR description
Before this fix, if you uninstalled this module and navigated to any partner that had a e-invoice format defined by this module, you'd have a traceback. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @moduon MT-12168 OPW-5172861 Forward-Port-Of: odoo/odoo#235301 Forward-Port-Of: odoo/odoo#232297
This fixes an error that could appear when opening the Accounts Coverage Report for Spain balance sheet reports. The report data is now loaded correctly, preventing the traceback and allowing users to view the report without interruption.
Original PR description
Step to reproduce: - for Spain localization, in developer mode: - Go to Balance sheet - Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES) - Click on the parameters button…
Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"
Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```
Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback
https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680
Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.
opw-5224114
Forward-Port-Of: odoo/enterprise#99865
Forward-Port-Of: odoo/enterprise#98745The web test runner now logs a warning instead of raising an error when no tests are found, which avoids unnecessary failures. It also records the results of all top-level test suites at the end of each run in headless mode, making automated test runs easier to review.
Original PR description
[FIX] web: Hoot - remove error if no tests This commit replaces the error thrown if there is no test found by a log. --- [IMP] web: Hoot - log root suites at end of run This commit makes the unit test runner log all root suites results after each test run, only in headless mode. Forward-Port-Of: odoo/odoo#236647
9 changes
Resolved issues and error corrections
This fix ensures that when a delivered subscription product is returned, the system updates the subscription’s delivered quantity correctly. This matters because billing and service tracking stay accurate after product returns.
Original PR description
**Steps to reproduce** - Create a new subscription using a subscription product. Confirm it. - Run the "Sale Subscription: generate recurring invoices and payments" scheduled action to generate the delivery. Validate the delivery. - Return the delivery and validate the return. - Issue: the delivered quantity of the sale order line is not updated. **Cause** Currently, we consider a move as related to a subscription period based on the `date_deadline` field (see _get_outgoing_incoming_moves). Since `_prepare_procurement_values` is not called when creating a return, the `date_deadline` is not set on the return moves. **Change** The returns linked to a move in a subcription period will be conisdered for the computation of the delivered quantities. opw-5136406 Forward-Port-Of: odoo/enterprise#99734 Forward-Port-Of: odoo/enterprise#98690
This update fixes an error that could appear when opening the Accounts Coverage Report for Spanish balance sheet reports. It ensures the report data is stored correctly and loaded in the right order, so users can view the report without encountering a traceback.
Original PR description
Step to reproduce: - for Spain localization, in developer mode: - Go to Balance sheet - Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES) - Click on the parameters button…
Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"
Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```
Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback
https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680
Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.
opw-5224114
Forward-Port-Of: odoo/enterprise#98745This update lets Canadian users choose a different start date for annual reporting when their fiscal year does not end on December 31. It helps ensure year-end filings and closings are calculated on the correct dates, aligning with allowed government rules.
Original PR description
If a user from CA has a fiscal year on something other than the 31/12 and needs to return annually, he can't do his closing on the right bounds. We now allow CA to show the field to be able to shift it, as government allow it. Later, we will change the heuristic to be smarter to show it as soon as it may cause issue. opw-5193999 Forward-Port-Of: odoo/enterprise#100006
This update restores the correct payment message setting for standard ISO 20022 payments, so non-SEPA transfers are handled as expected again. It ensures payments that need the NURG service level are marked correctly by default, helping avoid processing issues with international payments.
Original PR description
Since commit [[1]], the Service Level is set to NURG only when using the specific `iso20022_se` payment method. However, the previous expected behavior was to set the Service Level to NURG automatically whenever a payment was in a non-EUR currency or targeted a non-EU IBAN, regardless of the specific ISO20022 variant. This commit restores the logic to set the Service Level to NURG for all standard ISO20022 payments. This fix doesn't check anymore if a payment is in non-EUR currency or target a non-EU IBAN. Using iso_20022 activate it by default. opw-5095483 [1]: https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e Forward-Port-Of: odoo/enterprise#100061
This update stops users from accidentally changing locked information when they drag and drop items in Gantt views. It is especially important in planning screens, where moving a task could previously alter a read-only field such as the product on a work order.
Original PR description
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping…
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO. Steps to reproduce ----- - Have 2 products - Create a MO for product 1 with a WO at work center 1, plan it - Create a MO for product 2 with a WO at work center 2, plan it - Got to Manufacturing, Planning, Planning by Work Center - Add a custom group (by product) - Drag the WO of WC2 and drop it on top of the other WO > Both the WC and the product of the second WO change Cause ----- The example problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is both readonly and stored. https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34 While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by passing it to `write` since the field is stored. This does not pose any problem for related fields that are not stored. More broadly, gantt views should not ignore the `readonly` attribute of fields. Solution ----- Add a new `o_gantt_readonly` class to all cells of rows grouped by a readonly field - and their "child" rows. For example, if the grouping is done by "Work Center > Product > Quality Check" and "Product" is readonly, rows grouped by either "Product" or "Quality Check" will be marked as readonly. When the user drags a pill, dynamically remove the class from cells of the same "child group". The class will then be added back upon pill drop. ----- Ticket: opw-4875366 Forward-Port-Of: odoo/enterprise#100088 Forward-Port-Of: odoo/enterprise#94166
This update makes the testing tool less disruptive when no tests are found by logging a message instead of raising an error. It also improves test run reporting in headless mode by logging root suite results at the end of each run, making automated test output easier to review.
Original PR description
[FIX] web: Hoot - remove error if no tests This commit replaces the error thrown if there is no test found by a log. --- [IMP] web: Hoot - log root suites at end of run This commit makes the unit test runner log all root suites results after each test run, only in headless mode. Forward-Port-Of: odoo/odoo#236647
This update fixes several issues in Uruguay’s vendor bill synchronization, including correctly handling multiple documents in one XML file and improving how imported bills are identified. It also keeps a copy of the uploaded XML with the bill and makes automatic processing more stable by running in smaller batches.
Original PR description
1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was…
1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was processed. Now all the CFEs are processed. 3) Add suffix '-manual' for new vendor edi documents uuid that are created by drag and drop xml file. 4) Create xml attachment in the edi document if it is created by drag and drop xml file. 5) Add suffix '-notification' for new vendor edi documents uuid that are created by 'UY: Create vendor bills (sync from Uruware)'. 6) Cron is run by batches (size=10). 7) Add tests. The suffixes -manual and -notification are used to differentiate between EDI documents generated manually and those generated automatically. This is useful to determine whether the document was created by a user or by an automated process, also helps users identify its origin more easily and also it is useful for debugging and tracking purposes. Task Adhoc side: 43467 Task latam side: 1355 Forward-Port-Of: odoo/enterprise#99308 Forward-Port-Of: odoo/enterprise#86829
Exchange rates imported from the Swiss Federal Tax Administration now use the correct publication date. This prevents rates from appearing to belong to the wrong day, improving the accuracy and reliability of currency conversions.
Original PR description
Steps to reproduce: - Select exchange service: [CH] Federal Tax Administration (FTA). - Add USD (or other currencies). - Fetch the new rates (click on the reload icon). Issue: Rates are returned for yesterday but stored with today’s date. Cause: The request fetches yesterday’s rates and we store the date using `gueltigkeit` (valid-until). FTA rates are typically valid until the next morning (around 7 AM) or until the next business day on weekends. Example (fetch on Fri 14.11.2025): <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> For example, if we fetch on the 14th (Friday), we get this value: <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> Solution: Query the FTA endpoint using today’s date and store the rate date from `datum` (publication date) instead of `gueltigkeit`. opw-5189127 Forward-Port-Of: odoo/enterprise#100046
This change updates the recorded state code for Odisha in India from "OR" to "OD". It helps ensure customer addresses and related documents, such as sales orders, use the correct official code.
Original PR description
**Steps to reproduce:** 1. Install the `Contacts` module. 2. Go to Contacts > Create a new contact. 3. Select country India, and state Odisha. 4. Create a sales order using the newly created contact. **Issue:** As per [Government of India](https://www.iso.org/obp/ui/#iso:code:3166:IN), the state code was officially changed from "OR" to "OD" in 2023. However, Odoo still uses the outdated code. <img width="407" height="163" alt="image" src="https://github.com/user-attachments/assets/1631a831-f455-4a51-886f-7e4ed691add0" /> **Solution:** Update the name of the state from "OR" to "OD" in state records. **opw-4935633** Forward-Port-Of: odoo/odoo#234697
5 changes
Enhancements to existing features
This update improves how GSTR-2B issues are handled by recognizing an additional return code and classifying it as a warning instead of leaving it unhandled. It also stops background processing from retrying records that are already in an error state, which reduces unnecessary processing and helps keep the workflow cleaner.
Original PR description
Before this commit: - `RET2B1017` error code was not handled. - Cron methods `_cron_get_gstr2b_data` and `_cron_gstr2b_match_data` processed all records with status: - `"waiting_reception"` - `"being_processed"` - Records with blocking level `"error"` were still being processed by cron. After this commit: - Added handling for `RET2B1017` and mapped it to `"warning"` level. - Updated cron domain filters to exclude records where `gstr2b_blocking_level = "error"`. - Cron jobs now skip invalid/error-state return periods, preventing unnecessary processing. Forward-Port-Of: odoo/enterprise#100070 Forward-Port-Of: odoo/enterprise#99378
Resolved issues and error corrections
This fix ensures that when a delivered subscription item is returned, the subscription’s delivered quantity is updated correctly. It prevents billing and delivery figures from staying out of sync after a return, which helps keep subscription records accurate.
Original PR description
**Steps to reproduce** - Create a new subscription using a subscription product. Confirm it. - Run the "Sale Subscription: generate recurring invoices and payments" scheduled action to generate the delivery. Validate the delivery. - Return the delivery and validate the return. - Issue: the delivered quantity of the sale order line is not updated. **Cause** Currently, we consider a move as related to a subscription period based on the `date_deadline` field (see _get_outgoing_incoming_moves). Since `_prepare_procurement_values` is not called when creating a return, the `date_deadline` is not set on the return moves. **Change** The returns linked to a move in a subcription period will be conisdered for the computation of the delivered quantities. opw-5136406 Forward-Port-Of: odoo/enterprise#99734 Forward-Port-Of: odoo/enterprise#98690
This update fixes how ISO 20022 payments are labeled so they follow the expected non-SEPA handling again. As a result, international or non-standard payments are prepared correctly without requiring a specific payment variant.
Original PR description
Since commit [[1]], the Service Level is set to NURG only when using the specific `iso20022_se` payment method. However, the previous expected behavior was to set the Service Level to NURG automatically whenever a payment was in a non-EUR currency or targeted a non-EU IBAN, regardless of the specific ISO20022 variant. This commit restores the logic to set the Service Level to NURG for all standard ISO20022 payments. This fix doesn't check anymore if a payment is in non-EUR currency or target a non-EU IBAN. Using iso_20022 activate it by default. opw-5095483 [1]: https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e Forward-Port-Of: odoo/enterprise#100061
This fix ensures exchange rates imported from the Swiss Federal Tax Administration are saved with the correct publication date. It prevents rates from appearing one day off, which helps keep accounting and currency conversions accurate.
Original PR description
Steps to reproduce: - Select exchange service: [CH] Federal Tax Administration (FTA). - Add USD (or other currencies). - Fetch the new rates (click on the reload icon). Issue: Rates are returned for yesterday but stored with today’s date. Cause: The request fetches yesterday’s rates and we store the date using `gueltigkeit` (valid-until). FTA rates are typically valid until the next morning (around 7 AM) or until the next business day on weekends. Example (fetch on Fri 14.11.2025): <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> For example, if we fetch on the 14th (Friday), we get this value: <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> Solution: Query the FTA endpoint using today’s date and store the rate date from `datum` (publication date) instead of `gueltigkeit`. opw-5189127 Forward-Port-Of: odoo/enterprise#100046
The Canadian reporting settings now let users choose a start date other than December 31 when their fiscal year does not match the calendar year. This helps businesses file annual reports using the correct date range and avoid closing-period errors.
Original PR description
If a user from CA has a fiscal year on something other than the 31/12 and needs to return annually, he can't do his closing on the right bounds. We now allow CA to show the field to be able to shift it, as government allow it. Later, we will change the heuristic to be smarter to show it as soon as it may cause issue. opw-5193999 Forward-Port-Of: odoo/enterprise#100006
47 changes
Enhancements to existing features
Signing templates now organize their field definitions in a dedicated extension point, making future adaptations easier to maintain. This mainly helps teams and partners customize signing workflows with less risk when applying updates.
Original PR description
Introduced a dedicated _getTemplateFields() method to make easier to override or extend the fields in patches. Forward-Port-Of: odoo/enterprise#100096 Forward-Port-Of: odoo/enterprise#95722
The spreadsheet version history panel now uses tile colors with better contrast in dark mode. This makes previous versions easier to read and reduces visual strain for users working with dark mode enabled.
Original PR description
Change the color of the tiles of the version history to have a better contrast in dark mode. Task: [5265478](https://www.odoo.com/web#id=5265478&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Sent email records now keep the exact address used when contacting a recipient. This prevents past notification details from changing if the recipient's partner email is updated later, improving auditability and clarity.
Original PR description
Purpose ======= When we send an email to a partner, we don't store the email used. So if we change the email of the partner, then the email shown in the mail notification won't be accurate anymore. Now, we store that email in `mail_email_address`. Task-5215602
Toolbar buttons in Web Studio now display their matching keyboard shortcuts in their tooltips. This helps users discover faster ways to work and makes common editing actions easier to learn.
Original PR description
This PR updates toolbar button tooltips to display their corresponding keyboard shortcuts. Community PR: https://github.com/odoo/odoo/pull/233741 task-5160025
Field service products no longer carry a separate worksheet template setting when task templates can already provide the worksheet. This reduces duplicate configuration and helps ensure generated tasks consistently use the worksheet defined on the selected task template.
Original PR description
…om product Before this commit, since the adding of a task template in the product settings when the service product will generate a task in a project selected a project with worksheet feature. The user can set a worksheet template and a task template in that product form view. The task template can actually have a worksheet template set to give it to the task that will be generated once a sale order contains that product and is confirmed. And thus, the worksheet_template_id field in the product form view is a bit redundant with the task template. This commit removes the worksheet_template_id field from the product model to let the task template doing the job. task-5213862
Users can now start an AI chat directly while viewing an attachment, with the selected file automatically included as context. This makes it easier to ask questions about documents without manually adding or moving files, while keeping those temporary context files out of the permanent message attachments.
Original PR description
## Summary - Introduced a new AI composer `file_viewer_ai_button` to allow launching AI chat directly from the file viewer. - The selected file is sent as a context attachment along with the message to the LLM. - Context attachments are linked to the message temporarily for AI processing but not stored in `message.attachment_ids`. task-id-5125822
Shop floor users can now adjust the production quantity or split a manufacturing order directly from the Shopfloor interface. This helps teams react faster to changes in demand without leaving their operational workflow.
Original PR description
Add a new menu in Shopfloor to allow changing product_qty and splitting MOs. Task: 5153835
Internal users can now write and edit messages with a richer HTML editor in chatter, Discuss, and live chat. This improves day-to-day communication by making formatting and suggestions more consistent across messaging areas.
Original PR description
This commit enables the html composer for internal users.
This allows internal users to use the html composer to write/edit
messages in the chatter, discuss, and livechat.
1. Uses wysiwyg for internal composer;
2. Adds composer plugin to bind the handlers so that we don't need to
redo it for textarea composer;
3. Adds suggestion plugin to replace the navigable suggestion list;
4. Uses the suggestion plugin in full composer;
task-4454078
https://github.com/odoo/odoo/pull/199806The message composer is being updated to support a richer writing experience, making it easier for users to format and prepare messages. Related tests were adjusted across Documents, Mail, and Helpdesk Live Chat to ensure the improved composer works reliably in key communication flows.
Original PR description
task-2593397
VOIP calls now keep their duration as a stored value, making it easier to filter, group, and total call activity in reports. The call end time is calculated from the start time and duration, helping keep call records consistent and reducing duplicate stored data.
Original PR description
Persist call duration to enable filtering, grouping, and aggregation, and compute end_date on the fly from start_date + duration instead of storing it explicitly. Add a regression test ensuring the stored duration and computed end date stay in sync. upgrade: https://github.com/odoo/upgrade/pull/8891 task-5187543
The return workflow has been streamlined by removing the separate “Validate” step before submission. This reduces extra clicks and makes tax and payroll return processing faster while keeping related submission and locking flows aligned across affected localizations.
Original PR description
task-5155703
Manufacturing orders that require a lot or serial number can now complete without users manually entering one first. This reduces interruptions on the shop floor and ensures related print actions include the newly generated lot or serial information.
Original PR description
Marking a manufacturing order as done without a provided/generated lot/serial number raises with the message "You need to supply a Lot/Serial number for product ...". We want this information to be populated automatically. The automatic report printing actions had to be reworked to include these generated lots/serials, as well as the mrp.batch.produce which previously did not handle them. task: 4595752 See odoo/odoo#209659
Quality checks for repair orders are now generated when the order is confirmed, rather than at initial creation. This avoids unnecessary checks for repairs that are never processed and keeps product or lot-related checks aligned with confirmed work.
Original PR description
- Generate quality checks when a repair order is confirmed rather than when it is created. This ensures that quality checks are only created for repair orders that are actually being processed. - Product and lot updates quality checks only after confirmation. Task [5227065](https://www.odoo.com/odoo/project/966/tasks/5227065) Forward-Port-Of: odoo/enterprise#98815
GSTR-2B processing now recognizes an additional recoverable warning condition and avoids reprocessing return periods already marked with blocking errors. This reduces unnecessary automated retries and helps keep India GST reporting workflows focused on records that can still be processed.
Original PR description
Before this commit: - `RET2B1017` error code was not handled. - Cron methods `_cron_get_gstr2b_data` and `_cron_gstr2b_match_data` processed all records with status: - `"waiting_reception"` - `"being_processed"` - Records with blocking level `"error"` were still being processed by cron. After this commit: - Added handling for `RET2B1017` and mapped it to `"warning"` level. - Updated cron domain filters to exclude records where `gstr2b_blocking_level = "error"`. - Cron jobs now skip invalid/error-state return periods, preventing unnecessary processing. Forward-Port-Of: odoo/enterprise#100281 Forward-Port-Of: odoo/enterprise#99378
Signature blocks are now registered in a shared editor category so they can work reliably across different editing experiences. This ensures signatures remain available in Mass Mailing and simple editors, reducing disruption when preparing communications.
Original PR description
### Description of the issue/feature this PR addresses: - The Signature Plugin was defined in the sign module by extending the html_editor plugin under the basic_block category. - The mass_mailing builder removed config.plugins, preventing the Signature Plugin from working. ### Desired behavior after PR is merged: - The category is now defined in html_editor and renamed to modules so other modules can also use it. - Mass Mailing: - Signature Plugin is registered in `mass_mailing-plugins` for mass_mailing. - For simple editor, Signature Plugin is registered in `basic-editor-plugins`. **community: https://github.com/odoo/odoo/pull/190616** task-4224624 Forward-Port-Of: odoo/enterprise#75612
Resolved issues and error corrections
Returned deliveries for subscription products are now correctly counted when calculating delivered quantities. This prevents subscription sale orders from showing inaccurate delivery status after a customer return is processed.
Original PR description
**Steps to reproduce** - Create a new subscription using a subscription product. Confirm it. - Run the "Sale Subscription: generate recurring invoices and payments" scheduled action to generate the delivery. Validate the delivery. - Return the delivery and validate the return. - Issue: the delivered quantity of the sale order line is not updated. **Cause** Currently, we consider a move as related to a subscription period based on the `date_deadline` field (see _get_outgoing_incoming_moves). Since `_prepare_procurement_values` is not called when creating a return, the `date_deadline` is not set on the return moves. **Change** The returns linked to a move in a subcription period will be conisdered for the computation of the delivered quantities. opw-5136406 Forward-Port-Of: odoo/enterprise#99734 Forward-Port-Of: odoo/enterprise#98690
Uninstalling the Databases module no longer leaves behind a project access rule that refers to removed database fields. This prevents an error during uninstall and helps keep the system stable when customers remove the module.
Original PR description
Currently an error occurs when user uninstalls the `databases` module. **Steps to replicate:** * Install and uninstall databases **Error:** `ValueError: Invalid field project.project.database_hosting…
Currently an error occurs when user uninstalls the `databases` module.
**Steps to replicate:**
* Install and uninstall databases
**Error:**
`ValueError: Invalid field project.project.database_hosting in condition ('database_hosting', '=', False)`
**Root cause:**
* This error happens because when the user installs `databases`, record rule [1] is created by the module and it overrides rule [2]. Later, when databases is uninstalled, rule [1] is still there, but it tries to access the field 'database_hosting' [3], which was removed during the uninstall. Since that field no longer exists, it causes an error.
**Solution:**
* Revert the domain back to the one defined in project module.
[1]:
https://github.com/odoo/enterprise/blob/437f724c182ddf22bd3df9a7e1582ffa4b29e33b/databases/security/databases_security.xml#L43-L46
[2]:
https://github.com/odoo/odoo/blob/9333df06e15134df92efed765cf95db38c0dfede/addons/project/security/project_security.xml#L57-L62
[3]:
https://github.com/odoo/enterprise/blob/437f724c182ddf22bd3df9a7e1582ffa4b29e33b/databases/models/project_project.py#L17-L26
sentry-7035410943
Forward-Port-Of: odoo/enterprise#99987The subscription customer portal now uses the billing periods configured in the system instead of relying on a fixed list. This prevents errors when businesses add custom billing options, such as daily subscriptions, and makes future changes easier to support.
Original PR description
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the…
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the billing_period_unit selection field via inheritance. However, this customization causes an error (a KeyError) when accessing the customer portal at /my/subscriptions/<int:order_id>. This is because the controller logic relies on a hardcoded list of periods and does not account for the new custom "day" value. - Screenshot Order with plan Daily: <img width="1246" height="483" alt="image" src="https://github.com/user-attachments/assets/5dc5ca0d-a2f2-434d-8183-15a0424d9f34" /> - Screenshot when trying to get in order on the website: <img width="1250" height="776" alt="image" src="https://github.com/user-attachments/assets/5b10504e-71e2-4c13-8611-39e8a41e05d1" /> Proposed Solution -------- This PR improves the subscription portal by dynamically retrieving billing periods instead of using a hardcoded list. The portal now reads the available options directly from the billing_period_unit field's selection (i.e., self.env['sale.subscription.plan']._fields['billing_period_unit'].selection). This improves maintainability, as future changes to the field's selection will be automatically reflected without requiring code modifications. This makes the portal robust and automatically compatible with any custom periods added via inheritance. - <img width="1331" height="752" alt="image" src="https://github.com/user-attachments/assets/4f7be6c3-d96b-4525-8e23-6e1323adabde" /> Forward-Port-Of: odoo/enterprise#100084 Forward-Port-Of: odoo/enterprise#99207
Budget values in accounting reports now show the same rounded amount when viewed and edited. This prevents confusing extra decimal digits from appearing in budget input fields, making report updates clearer for users.
Original PR description
**Issue:** When editing budget values in the Profit & Loss report, users see floating-point precision errors (e.g., 0.999999 instead of 1.00) in the input field, even though the display shows the…
**Issue:** When editing budget values in the Profit & Loss report, users see floating-point precision errors (e.g., 0.999999 instead of 1.00) in the input field, even though the display shows the correct rounded value. **Steps to Reproduce:** 1. Go to Accounting → Reporting → Profit and Loss Report 2. Enable Column Budget 3. Enter budget value: 5.00 4. Save → Value displays correctly as: 5.00 ✓ 5. Click to edit the same cell 6. Input field shows: 5.000000000174602 ✗ (instead of 5.00) 7. Save without changes → Display shows: 5.00 ✓ 8. Edit again → Still shows: 5.000000000174602 ✗ **Root Cause:** The frontend reads from cell['no_format'] when populating the edit input field. This field receives the raw column_value which contains floating-point precision errors accumulated during aggregation operations. While the display formatting applies rounding, the edit mode receives the unrounded value. **Solution:** Round column_value using float_round() immediately after detecting an editable budget column, before the value is used anywhere. This ensures both the display path and edit path receive the same properly rounded value based on the company's currency decimal places. opw-5158862 Forward-Port-Of: odoo/enterprise#98478
DHL shipments and return labels now use the field names and date-time format expected by DHL. This prevents failed label creation when customer references or return shipments are involved, improving reliability for DHL deliveries.
Original PR description
Currently, when creating a DHL shipment with an export declaration that includes a customer reference, there is a misspelling of the field 'recipientReference' as 'recepientReference'. This causes…
Currently, when creating a DHL shipment with an export declaration that includes a customer reference, there is a misspelling of the field 'recipientReference' as 'recepientReference'. This causes validation errors when communicating with the DHL API. In addition, the datetime format used for the planned shipping date and time does not conform to the expected format specified by DHL. Steps to reproduce spelling issue: 1. Create a Sales Order with a customer reference and a deliverable product. 2. Validate the SO. 3. Go to the delivery, select DHL as carrier, and confirm. → Error: Validation error #/content/exportDeclaration: extraneous key [recepientReference] is not permitted. Steps to reproduce datetime issue: 1. Create a delivery using the DHL carrier. 2. Confirm the delivery. 3. Return the delivery. 4. Click "Print Return Label". → Error: Bad request #/plannedShippingDateAndTime is not well formatted (expected format: '2010-02-11T17:10:09 GMT+01:00'). Official DHL documentation: https://developer.dhl.com/sites/default/files/2025-11/dpdhl-express-api-3.1.1_swagger.yaml opw-5024363 Forward-Port-Of: odoo/enterprise#98981
Invoice reports now keep section amounts aligned correctly when the Country of Origin column is displayed. This prevents confusing invoice layouts and helps users read totals accurately.
Original PR description
Before this commit when having section and the country of origin column, the amount was is the wrong place. The solution is to add 1 to the line colspan when display origin is set. opw-5333624 Forward-Port-Of: odoo/enterprise#100012
This update removes duplicate internal methods identified by automated code checks. It helps keep the affected HR payroll, salary contract, and expense processing areas easier to maintain, with no expected change for day-to-day users.
Original PR description
found by pylint 4 Forward-Port-Of: odoo/enterprise#100078 Forward-Port-Of: odoo/enterprise#99809
The fix ensures the Italian “Libro Giornale” PDF layout only applies to the intended Italian journal report. This prevents regular journal report exports from losing journal names when the Italian reporting module is installed, improving report reliability for affected companies.
Original PR description
The custom template for the report "Libro Giornale" was neither inheriting with primary neither using conditions on the country code. Therefore, the xpaths applied were for all the journal reports, whatever the company. For example, when exporting the regular journal report, the names of the journals no longer appeared once the module l10n_it_reports was installed on a database. opw-5217520 Forward-Port-Of: odoo/enterprise#100045
Swiss Federal Tax Administration exchange rates are now saved with the correct publication date instead of a later validity date. This prevents rates from appearing under the wrong day, improving accuracy for companies using Swiss currency rate updates.
Original PR description
Steps to reproduce: - Select exchange service: [CH] Federal Tax Administration (FTA). - Add USD (or other currencies). - Fetch the new rates (click on the reload icon). Issue: Rates are returned for yesterday but stored with today’s date. Cause: The request fetches yesterday’s rates and we store the date using `gueltigkeit` (valid-until). FTA rates are typically valid until the next morning (around 7 AM) or until the next business day on weekends. Example (fetch on Fri 14.11.2025): <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> For example, if we fetch on the 14th (Friday), we get this value: <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> Solution: Query the FTA endpoint using today’s date and store the rate date from `datum` (publication date) instead of `gueltigkeit`. opw-5189127 Forward-Port-Of: odoo/enterprise#100046
Quality checks in the barcode app now only appear for items that were actually picked or scanned, including the correct serial or lot-tracked unit. This prevents staff from being asked to complete checks for products that are not being received yet, reducing confusion and avoiding blocked validations.
Original PR description
*: {stock_barcode_,}quality_control #### There are two issues addressed in this PR: 1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.…
*: {stock_barcode_,}quality_control
#### There are two issues addressed in this PR:
1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.
2) Quality check related to product without set lots are triggered.
### Steps to reproduce:
- Create a storable products product A tracked by SN
- Create a control points of type pass/fail on receipts control by
quantity on product A
- Create and confirm a receipt with a move 2 x product A
- Open the receipt in the barcode app
- Scan product A > Scan SN001
- Click on Quality Check
#### > Both QC's are displayed to be processed
### Expected behavior:
Only the QC related to the scanned SN should be processed as it is the only unit that will be moved at validation.
### Cause of the issue:
Only picked move lines are considered to be processed in the barcode app. However, the `check_quality` triggered by clicking on the quality check button only check if the move related to the move line is picked:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L64-L72
### Fix:
Relying the `barcode_trigger` context key will ensure a uniform behavior between the QC's displayed to be processed directly from the QC button and from these displayed at validation since this context key is already used at validation:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/stock_barcode/static/src/models/barcode_model.js#L581-L590
Note we all changed the default return value of the `check_quality` from `False` to `True` here:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L71-L73
because this method is called in the `pre_action_done_hook` during the `button_validate` of the picking:
https://github.com/odoo/odoo/blob/a97d3c772001f4f0b9df66d28c1c8f19358898e0/addons/stock/models/stock_picking.py#L1415-L1421
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L91-L96
and since a result that is not `True` is expected to be an action that should be processed prior to validation, returning `False` would make it impossible to proceed with a validation in case the `check_quality` is called and there is no check to process.
Task: 4716252
opw-5010764
Forward-Port-Of: odoo/enterprise#99799
Forward-Port-Of: odoo/enterprise#99565Hong Kong payroll now respects manually entered Average Daily Wage amounts instead of replacing them with an automatic calculation. This prevents incorrect payslip results when payroll teams need to use a specific manually provided value.
Original PR description
The current logic is incorrect and while it does pick the ADW from the input line, it then proceeds to override that amount with the calculated one. In cases where the manual input is needed, this is a big issue. Forward-Port-Of: odoo/enterprise#100262
German Datev exports now use the manually adjusted tax totals from vendor bills instead of the original calculated amount. This helps ensure exported accounting files match what users see in the ledger and reduces reconciliation errors.
Original PR description
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting /…
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting / Audit Reports / General Ledger" => The tax amount is the one that has been edited manually - Download `Datev DATA (zip)` - Open `EXTF_accounting_entries.csv` file The total amount in the file is the one before the edition of the tax amount. The Datev data depends on `price_total` field of the invoice lines, but this field is not updated when the tax amount is edited manually. We now check the total by adding `price_total` of each invoice line and the total amount defined in `tax_totals` field. If there is a difference, compute the delta for each tax group and split it between all the lines where a tax of that group is used. Ticket [link](https://www.odoo.com/odoo/project.task/4951488) opw-4951488 Forward-Port-Of: odoo/enterprise#100244 Forward-Port-Of: odoo/enterprise#98684
Spanish balance sheet users can now open the Accounts Coverage Report without encountering an error. The underlying report data is loaded in the correct order and stored properly, improving reliability for Spain localization reporting.
Original PR description
Step to reproduce: - for Spain localization, in developer mode: - Go to Balance sheet - Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES) - Click on the parameters button…
Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"
Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```
Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback
https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680
Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.
opw-5224114
Forward-Port-Of: odoo/enterprise#99865
Forward-Port-Of: odoo/enterprise#98745Swiss payroll test coverage was adjusted so it no longer depends on accounting configuration being present. This helps ensure payroll validation and related declarations can be tested more reliably without unnecessary accounting setup requirements.
Original PR description
Forward-Port-Of: odoo/enterprise#99853 Forward-Port-Of: odoo/enterprise#98672
This update fixes how default filing deadlines are configured for multiple country-specific Intrastat and tax return reports. It helps ensure each company uses the correct return deadline settings, reducing configuration errors in localized reporting.
Original PR description
The fields default_deadline_periodicity and default_deadline_days_delay have been added on the return type model because they handle the company dependant property of their associated field, and they are the ones that should be used in the xml. Forward-Port-Of: odoo/enterprise#99793
This fix restores the expected handling of ISO20022 bank payments by applying the normal service level to standard non-SEPA payment flows. It helps ensure international or non-standard currency payments are generated in the format banks expect, reducing the risk of payment processing issues.
Original PR description
Since commit [[1]], the Service Level is set to NURG only when using the specific `iso20022_se` payment method. However, the previous expected behavior was to set the Service Level to NURG automatically whenever a payment was in a non-EUR currency or targeted a non-EU IBAN, regardless of the specific ISO20022 variant. This commit restores the logic to set the Service Level to NURG for all standard ISO20022 payments. This fix doesn't check anymore if a payment is in non-EUR currency or target a non-EU IBAN. Using iso_20022 activate it by default. opw-5095483 [1]: https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e Forward-Port-Of: odoo/enterprise#100061
Fixes an issue where edited or deleted partners on multi-line bank statements could be recalculated unexpectedly during reconciliation. This helps accounting users keep their intended partner assignments and reduces incorrect reconciliation changes.
Original PR description
Before this commit, when having multiple lines in a statement line. By default, all the lines have a partner since we compute the partner depending of other lines. But in the case of an edit or a delete we don't want to recompute. What was happening is that the partner keep getting recomputed on the other lines even the one that was previously edited. This commit will add a context key when using the reconcile button to recompute the partners. opw-5179670 Forward-Port-Of: odoo/enterprise#99999
Fixed an issue that caused point-of-sale scales using fallback connectivity to send rapidly multiplying requests after each weight change. This prevents request failures and keeps scale weighing reliable during checkout.
Original PR description
Steps to reproduce: 1. Setup a scale in a POS. 2. Disable the WebRTC connection so that longpolling is used. 3. Try to weigh with the scale in the POS. Expected behaviour: - There is one HTTP call per weight event, and the scale continues to work no matter how many times the weight changes. Actual behaviour: - The amount of HTTP calls doubles every time the weight changes. Before long, a limit is reached and the requests start to fail. This behaviour was due to the `addListener` method being called again inside the listener callback, calling the poll method. The original poll call would also start to poll again, leading to two polling requests. The fix is to check in the poll method that listening has not restarted during the handling of the callback. If so, we don't try to poll again.
Spreadsheet version history tiles now use colors with better contrast in dark mode, making past versions easier to read. Related spreadsheet document tests were also updated to match the latest resizing behavior, helping keep the feature reliable after the spreadsheet engine update.
The update corrects an internal test for Belgian SODA accounting imports by ensuring the needed analytic setup is created during the test. This helps keep automated quality checks reliable and prevents false failures in development pipelines.
Original PR description
This https://github.com/odoo/enterprise/commit/e01d865d922d47d8ba1638a48e6d481363fc1f04 introduced an error while running the test without enough analytic accounts. We instead manually create the analytic plan and accounts required for the test. runbot-234353
The VoIP keypad input now uses a better font size when it is empty, so its placeholder text displays correctly. This makes the calling interface clearer and avoids confusing clipped guidance for users entering a number.
Original PR description
In https://github.com/odoo/enterprise/pull/99877, the font size for the Keypad input was fixed to a value suitable for most cases. Still it is problematic when the input is empty: the placeholder is not fully displayed. Here we set an appropriate value for the font size in that later case.
This fixes an issue in the Sign app where a signer could see date placeholders meant for later signers. The change helps keep the signing experience clearer and avoids confusion during multi-signer document workflows.
Original PR description
Version: - saas-18.3 Steps to reproduce: - Add date fields for multiple signers. - When the first signer signs, the date placeholder for the next signer becomes visible to the first signer. Issue: - Date fields for next signers were showing placeholders to the current signer. Fix: - Added a condition to only set the placeholder when it has a valid value. Impact: - Ensures date placeholders are visible only to the correct signer. task-5218970 Forward-Port-Of: odoo/enterprise#100252 Forward-Port-Of: odoo/enterprise#98256
French financial reports now include balances from deprecated income and expense accounts when calculating retained earnings. This prevents balance sheets from becoming unbalanced for companies moving from the 2024 French chart of accounts to the legally required 2025 version.
Original PR description
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA,…
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA, legally mandatory starting in 2025. Doing so, it also adapted the P&L and BS reports accordingly. However, it did not take into account the fact that some deprecated account codes would disappear from the P&L, causing the BS to be unbalanced when computing the retained earnings (by calling the P&L with a forced date_scope to run it on the full history). We fix that by reinjecting the balance of the missing Income and Expense accounts in the computation of the BS's Retained Earnings line. opw-5212801 =============================================================== [FIX] l10n_fr_reports : add new accounts in P&L Backport from https://github.com/odoo/enterprise/commit/eb35916f4f5a45e0c11919e0ee1a16e0caee010f , which was done in master for 18.2, but should have targetted older versions as well. Forward-Port-Of: odoo/enterprise#100116 Forward-Port-Of: odoo/enterprise#100077
Opening the translation widget for invoice terms and conditions no longer triggers an error when those terms are made translatable by GCC invoice localization. This helps users edit translated invoice text without interruption.
Original PR description
With l10n_gcc_invoice, the narration field on invoice (the Terms & Condition part) becomes translatable. However, when opening the translation widget, a traceback happens as the "fields" (the text-to-fill part) to load don't have a specified name. opw-5269869 Forward-Port-Of: odoo/enterprise#100003
Composite financial reports now apply the analytic grouping filter consistently to their underlying sections. This ensures the filter appears in the interface when enabled, giving users the expected reporting options without extra setup.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. Forward-Port-Of: odoo/enterprise#100135
This fixes an internal payroll accounting test so it uses the right company when checking account-related partner settings. It helps ensure Belgian payroll accounting remains reliable in multi-company situations, reducing the risk of incorrect accounting configuration going unnoticed.
Original PR description
We are now testing for consistency between the company properties set on partners related to accounting values. opw-5127901 Forward-Port-Of: odoo/enterprise#100192
This update prevents an error when Stripe webhook events include virtual cards with no shipping details. It helps expense card events process reliably instead of failing on missing shipping information.
Original PR description
Add a fix to a pattern of error found in webhook events where virtual cards whose shipping value is "None" would be accessed as dict Forward-Port-Of: odoo/enterprise#100291
Code cleanup and technical improvements
The WhatsApp integration was updated to stay aligned with recent internal changes to how conversation member lists are handled. This keeps WhatsApp-related discussions working consistently after the underlying platform refactor, with no expected change for end users.
Original PR description
This commit adapts the whatsapp code to account for the refactoring of `hasMemberList`. Pr community: https://github.com/odoo/odoo/pull/236510
This update standardizes how XML files are checked and refreshed in electronic invoicing tests for Guatemala and Mexico. It helps developers maintain these compliance-related tests more reliably, reducing the risk of errors when invoice formats or rules change.
Original PR description
This commit adds helpers and improves on the way we assert XML files in `AccountTestInvoicingCommon` and all accounting test that extend from it. From now on, all accounting test code that assert an…
This commit adds helpers and improves on the way we assert XML files in `AccountTestInvoicingCommon` and all accounting test that extend from it. From now on, all accounting test code that assert an XML tree/string to an XML file should call the `assert_xml` helper, and design their test file name/location/etc. around this framework. This approach has a few major benefits: ### Assert / Save XML When testing XML files, we often need to perform create/read/update operations on the asserted XML to make sure it corresponds to the most updated/intended data. Previously, to save something to an XML, a developer would need to write their own local helpers to save the XML in the right directory. This was cumbersome and error-prone, so we decided to design a helper that allows developer to immediately save AND/OR update the asserted XML: to save/update an XML, we can simply add `SAVE_XML` as an additional test tags. ### Better test naming and optional subfolder management To better organize test files, the `assert_xml` method allows us to write just the test key name (without `.xml`), and the framework will automatically get the XML to assert/save from the `test_files` directory. An optional `subfolder` parameter is also added to allow writing to specific subfolder within `test_files`. ### Better `___ignore___` management in assertion XMLs Sometimes, we want to ignore a few XML node that are not relevant, or have content that are not deterministic (changes on every test run). To handle this, previously, developers would need to modify the assertion XML content by hand or write their own local script to do so. With this new framework, we just need to add an `ignore_schema.xml` file somewhere in the `test_files` directory. If put inside a subfolder, it will be applied with more priority towards the XML that are put on that specific subfolder. ### Save "pure" XML (before applying `___ignore___`) in temporary folder When calling `SAVE_XML`, before applying the ignore patches, the XML will be saved in a temporary folder (same folder as the screenshots for tours), so that developers can use them in external tests in the future, and for any other saving reasons. In addition, this commit also: - add `edi_tags` helper to save all the common tags for EDIs, which also enables `EXTERNAL_MODE` testing inspired by `l10n_mx_edi` - convert some non-assert XML test helpers into a class method - add `XmlCollector` exception to be used to stop a method and collect an XML data for tests in EDIs. (see `l10n_gt_edi`) - refactor `l10n_mx_edi*` modules to use these helpers related-community-PR: https://github.com/odoo/odoo/pull/235565 task-4891206
This update removes an outdated internal messaging function from WhatsApp and Mexican e-invoicing areas. It aligns Enterprise code with the main Odoo platform cleanup, reducing maintenance overhead without expected changes for end users.
Original PR description
\* = whatsapp, l10n_mx_edi Enterprise counter-part. task-5347566 https://github.com/odoo/odoo/pull/236778
This change reorganizes how WhatsApp conversation member online and offline status information is stored in the messaging system. It should not change day-to-day behavior for users, but it helps keep the codebase cleaner and easier to maintain for future improvements.
Original PR description
PR community: https://github.com/odoo/odoo/pull/235248
The option for preparation printers connected through IoT has been moved into the dedicated POS IoT module. This keeps point-of-sale IoT features organized in the right place, making configuration and maintenance more consistent without changing the overall business workflow.
Original PR description
In order to improve consistency between modules, we moved the IoT preparation printer option to the `pos_iot` bridge module. see odoo/odoo#234883 Task: 4954046
21 changes
New functionality added to Odoo
This change adds the Finnish EC Sales List report and its export file. It helps businesses operating in Finland produce the required cross-border sales reporting more easily and in the correct format.
Original PR description
The aim of this commit is adding the Finnish EC Sales List report. task-5126664 Forward-Port-Of: odoo/enterprise#99854 Forward-Port-Of: odoo/enterprise#95901
Enhancements to existing features
This update corrects how values are calculated in the Coretax e-Faktur XML so they are based on tax group rules instead of invoice type in certain cases. It also adds a safeguard to prevent invalid tax combinations when downloading the XML, helping avoid incorrect reports and making the setup more reliable.
Original PR description
Update Coretax XML file to compute the values for nodes in the correct way. Currently the computation is based on the invoice type for some of the nodes + STLG is based on wrong tax group. This leads to wrong computation of values + inflexibility. - Update the VAT calculation inside the E-faktur XML based on tax group - Add new tax group and modify existing tax - Add restriction when downloading E-faktur Coretax XML Task [#4948267](https://www.odoo.com/odoo/project.task/4948267) Forward-Port-Of: odoo/odoo#236821 Forward-Port-Of: odoo/odoo#233347
When a mass email is also logged in the chatter, its attachments are now linked directly to the related record. This makes them easier for users to find later in the record’s attachments list, improving day-to-day visibility and follow-up.
Original PR description
In [1] the argument to link attachments to messages was that it would automatically clean up the attachments when the message is deleted (typically right after sending). As it originally was kept forever, as we wanted to guarantee that it still exists by the time the email is sent. However in modern ODOO mass emails can, and often are, logged in the chatter. In that case it is relevant to link the attachments to the record directly so that users can see the attachments in the attachments menu of the chatter. [1]: https://github.com/odoo/odoo/commit/cf214ed7244207f1fd5d377ab69d85a6441ff665 task-4829625
The customer portal now reads subscription billing periods dynamically instead of relying on a fixed list. This prevents errors for subscriptions that use custom periods, such as daily billing, and makes future customizations work without extra code changes.
Original PR description
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the…
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the billing_period_unit selection field via inheritance. However, this customization causes an error (a KeyError) when accessing the customer portal at /my/subscriptions/<int:order_id>. This is because the controller logic relies on a hardcoded list of periods and does not account for the new custom "day" value. - Screenshot Order with plan Daily: <img width="1246" height="483" alt="image" src="https://github.com/user-attachments/assets/5dc5ca0d-a2f2-434d-8183-15a0424d9f34" /> - Screenshot when trying to get in order on the website: <img width="1250" height="776" alt="image" src="https://github.com/user-attachments/assets/5b10504e-71e2-4c13-8611-39e8a41e05d1" /> Proposed Solution -------- This PR improves the subscription portal by dynamically retrieving billing periods instead of using a hardcoded list. The portal now reads the available options directly from the billing_period_unit field's selection (i.e., self.env['sale.subscription.plan']._fields['billing_period_unit'].selection). This improves maintainability, as future changes to the field's selection will be automatically reflected without requiring code modifications. This makes the portal robust and automatically compatible with any custom periods added via inheritance. - <img width="1331" height="752" alt="image" src="https://github.com/user-attachments/assets/4f7be6c3-d96b-4525-8e23-6e1323adabde" /> Forward-Port-Of: odoo/enterprise#100084 Forward-Port-Of: odoo/enterprise#99207
This change adds triangular tax handling to Finnish tax reports so they can be used correctly in the EC Sales List report. It improves the accuracy of VAT-related reporting for businesses operating in Finland and across EU sales scenarios.
Original PR description
The aim of this commit is adding the triangular taxes into the tax report to use it in EC Sales List report. task-5126664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236427 Forward-Port-Of: odoo/odoo#229269
This change reduces noise in system logs by stopping the full contents of WebRTC messages from being recorded at the info level. Instead, only the message type and device are logged, which helps keep logs readable and avoids filling them with large receipt data. It also adds timing information for actions, making it easier to monitor performance.
Original PR description
Before this commit, the WebRTC client was logging every message it received in full at the 'info' level. This was causing logs to be flooded with base64 receipt data. We now only log the message type and device. We also now log the action execution time similarly to the websocket client. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
When a subscription delivery is returned, the delivered quantity on the related sales line is now updated correctly. This keeps subscription invoicing and delivery tracking accurate after returns, avoiding overcounting shipped items.
Original PR description
**Steps to reproduce** - Create a new subscription using a subscription product. Confirm it. - Run the "Sale Subscription: generate recurring invoices and payments" scheduled action to generate the delivery. Validate the delivery. - Return the delivery and validate the return. - Issue: the delivered quantity of the sale order line is not updated. **Cause** Currently, we consider a move as related to a subscription period based on the `date_deadline` field (see _get_outgoing_incoming_moves). Since `_prepare_procurement_values` is not called when creating a return, the `date_deadline` is not set on the return moves. **Change** The returns linked to a move in a subcription period will be conisdered for the computation of the delivered quantities. opw-5136406 Forward-Port-Of: odoo/enterprise#99734 Forward-Port-Of: odoo/enterprise#98690
This change makes sure split payments in Point of Sale are recorded against the same customer record as the related order, even when the sale is made under a child contact. It prevents mismatches in accounting and helps keep customer statements balanced and accurate.
Original PR description
### Description Before this commit, when split payment was enabled for a payment method and a PoS order was assigned to a child contact, the accounting move for the payment was linked to the child contact, while the order move lines were linked to the parent contact. This inconsistency resulted in unbalanced customer statements. This commit ensures that the payment move is assigned to the same accounting partner as the order lines. ### How to reproduce: * Create a child contact (res.partner). * Activate "Identify Customer" (split payment) for a payment method. * Open the session. * Create an order assigning the child contact and pay using this method * Close the session. * Accounting payment for this session will be assigned to child partner opw-5121710 Forward-Port-Of: odoo/odoo#237028 Forward-Port-Of: odoo/odoo#235951
This change corrects how manually entered average daily wage values are handled in Hong Kong payroll. When a user provides a manual amount, the system now keeps that value instead of overwriting it with a calculated one, avoiding incorrect payslip results.
Original PR description
The current logic is incorrect and while it does pick the ADW from the input line, it then proceeds to override that amount with the calculated one. In cases where the manual input is needed, this is a big issue.
This fix ensures delivery slips show the right ordered quantity when an order is partially delivered and a backorder is created, especially for make-to-order items. Previously, the slip could incorrectly show the remaining quantity as if it were the original order quantity, which was confusing for operations and customers.
Original PR description
Steps: - Create an MTO product. - Create an SO for 10 units and confirm. - Deliver 5 on the first picking, validate, and create the backorder. - Print the delivery slip of the first (done) picking.…
Steps:
- Create an MTO product.
- Create an SO for 10 units and confirm.
- Deliver 5 on the first picking, validate, and create the backorder.
- Print the delivery slip of the first (done) picking.
Before:
- MTO: Ordered = 5, Delivered = 5, Remaining = 5.
- Normal product: Ordered = 10, Delivered = 5, Remaining = 5.
Cause:
- _get_aggregated_properties builds a display key including the description:
line_key = f"{product.id}_{product.display_name}_{description}_{uom.id}_{move.product_packaging_id}".
- In MTO, backorder delivery moves are regenerated and sale_stock recomputes description_picking from the SO line, so backorders no longer share the same line_key and previous quantities are not merged.
Fix:
- Introduce _get_group_key_from_move to group sale moves by sale_line_id (fallback: product + UoM).
- For each picking, compute Ordered as the SO line quantity (in report UoM) minus quantities delivered on preceding pickings for that group.
- Keep the original line_key-based behavior for non sale-related moves and for empty moves.
opw-5112467This change makes spreadsheet features use the translation context meant for spreadsheets, instead of falling back to generic terms. As a result, labels and messages in spreadsheets should appear more accurately and consistently for users in translated languages.
Original PR description
When we give the translation function to the o-spreadsheet library, we give `_t` which doesn't have the translation context which means all translations fallback on the general translated terms instead of using the spreadsheet specific terms. 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
The Swiss Federal Tax Administration exchange rates are now saved with the correct date. This prevents rates from appearing one day off when users refresh currency rates.
Original PR description
Steps to reproduce: - Select exchange service: [CH] Federal Tax Administration (FTA). - Add USD (or other currencies). - Fetch the new rates (click on the reload icon). Issue: Rates are returned for yesterday but stored with today’s date. Cause: The request fetches yesterday’s rates and we store the date using `gueltigkeit` (valid-until). FTA rates are typically valid until the next morning (around 7 AM) or until the next business day on weekends. Example (fetch on Fri 14.11.2025): <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> For example, if we fetch on the 14th (Friday), we get this value: <gueltigkeit>15.11.2025,16.11.2025,17.11.2025</gueltigkeit> Solution: Query the FTA endpoint using today’s date and store the rate date from `datum` (publication date) instead of `gueltigkeit`. opw-5189127 Forward-Port-Of: odoo/enterprise#100046
The Belgian VAT return now includes the client nihil option again, which had been lost after a system change. This makes the export more accurate by only enabling the option when it is truly applicable, based on whether any customer exceeded the yearly invoicing threshold of 250€.
Original PR description
Since the new return system, the client nihil option that was inside the vat export xml was removed. We used a too simple mechanism which only checks if the tax report was empty or not. This was completely wrong, now we added the checkbox back for finer tuning and we precomputed it. The precompute is checking if any partner is exceeding 250€ invoiced for the current year. This commit adds a new module l10n_be_report_client_nihil which will be removed in master. It will be integrated with l10n_be_reports directly. task-5217079
This update prevents the website theme editor from crashing when a Google font is available only in one weight, such as 700. It ensures the editor requests the correct font variant so users can reopen and adjust their theme normally after saving.
Original PR description
Steps to reproduce: =================== 1. Edit the website theme and set an external font, e.g., UnifrakturCook. 2. Save, exit, then reopen the editor and go to the Theme tab. → Traceback occurs. Cause: ====== Some Google Fonts (e.g., UnifrakturCook) only provide a single weight (700). When fetching the font, html_builder does not request a specific weight, so Google Fonts attempts to return the default set, including 300. Since that weight does not exist for these fonts, Google Fonts responds with an error, leading to the traceback. This issue is same to the one fixed here: https://github.com/odoo/odoo/commit/f843c591c0377e0dab1a1f0cfaca36c1981c8880 but the fix was not ported during refactoring. opw-5259891 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236556
This update corrects the company used in a payroll accounting test so it matches the expected accounting setup. It helps ensure company-linked accounting data is validated consistently, reducing the risk of hidden configuration issues.
Original PR description
We are now testing for consistency between the company properties set on partners related to accounting values. opw-5127901
This fix ensures that when a route is chosen directly on a sales order line, Odoo keeps that choice instead of falling back to the product’s default route. This prevents the wrong supply process from being triggered, so orders now follow the intended buying or manufacturing flow.
Original PR description
**Issue** A route explicitly set on a sale order line is ignored: the system falls back to product-level routes. **Steps to reproduce** 1. Activate multi-route. 2. Unarchive the MTO route. 3. Create…
**Issue** A route explicitly set on a sale order line is ignored: the system falls back to product-level routes. **Steps to reproduce** 1. Activate multi-route. 2. Unarchive the MTO route. 3. Create a product. 4. Enable MTO + Manufacture on the product. 5. Create a sale order using this product. 6. Set the Buy route on the SO line. 7. Confirm the order. → A Manufacturing Order is created instead of a PO. **Cause** This regression originates from the changes introduced in https://github.com/odoo-dev/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a, where `propagate_warehouse_id` was removed and associated info began to be propagated through stock moves instead. In 19.0, the route of the rule started being injected into the move: https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/addons/stock/models/stock_rule.py#L367 To avoid infinite loops (e.g., WH1 resupplying WH2 and vice-versa), `_prepare_procurement_values` then filters out these injected routes: https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/addons/stock/models/stock_move.py#L1674-L1683 Unfortunately, whenever the `location_id` has a warehouse, the filtering applies to all `route_ids`, including those explicitly set by the user (e.g., on a sale order line) As soon as `route_ids` is cleared, `_get_rule` stops considering SO-line routes (first priority): https://github.com/odoo/odoo/blob/dab7c5821e627bc7120660778a288cb521a223d3/addons/stock/models/stock_rule.py#L599C13-L600C89 and falls back to product routes: https://github.com/odoo/odoo/blob/dab7c5821e627bc7120660778a288cb521a223d3/addons/stock/models/stock_rule.py#L604 **Solution** Revert the workaround that injected the rule's `route_id` into the move (added because `propagate_warehouse_id` no longer existed), and instead propagate the warehouse information directly in the inter-company case. Concretely: - Stop injecting the rule's `route_id` into the move: https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/addons/stock/models/stock_rule.py#L367 - Always keep the user's `route_ids` intact, no more filtering. - Explicitly propagate the warehouse coming from the rule in the inter-company case, restoring the intent of `propagate_warehouse_id`: https://github.com/odoo/odoo/blob/a7b504a3f5845feff8b676cc02ecf2d7b3489b7f/addons/stock/models/stock_move.py#L1655-L1656 This preserves manually-set routes (such as on SO lines) while still ensuring inter-company transfers work reliably. opw-5170290
The Spain localization balance sheet reports now open the Accounts Coverage Report without errors. The underlying report data was corrected and loaded in the right order so the report can display properly for users.
Original PR description
Step to reproduce: - for Spain localization, in developer mode: - Go to Balance sheet - Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES) - Click on the parameters button…
Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"
Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```
Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback
https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680
Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.
opw-5224114
Forward-Port-Of: odoo/enterprise#99865
Forward-Port-Of: odoo/enterprise#98745This update stops users from accidentally changing protected values when dragging items in Gantt views. It makes rows grouped by read-only fields behave as non-editable, so planning data stays consistent and unintended changes are avoided.
Original PR description
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping…
Issue ----- Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored. E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO. Steps to reproduce ----- - Have 2 products - Create a MO for product 1 with a WO at work center 1, plan it - Create a MO for product 2 with a WO at work center 2, plan it - Got to Manufacturing, Planning, Planning by Work Center - Add a custom group (by product) - Drag the WO of WC2 and drop it on top of the other WO > Both the WC and the product of the second WO change Cause ----- The example problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is both readonly and stored. https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34 While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by passing it to `write` since the field is stored. This does not pose any problem for related fields that are not stored. More broadly, gantt views should not ignore the `readonly` attribute of fields. Solution ----- Add a new `o_gantt_readonly` class to all cells of rows grouped by a readonly field - and their "child" rows. For example, if the grouping is done by "Work Center > Product > Quality Check" and "Product" is readonly, rows grouped by either "Product" or "Quality Check" will be marked as readonly. When the user drags a pill, dynamically remove the class from cells of the same "child group". The class will then be added back upon pill drop. ----- Ticket: opw-4875366 Forward-Port-Of: odoo/enterprise#100088 Forward-Port-Of: odoo/enterprise#94166
This fix ensures that date placeholders in signed documents only appear for the intended signer. It prevents one signer from seeing placeholder information meant for another, which helps avoid confusion during the signing process.
Original PR description
Version: - saas-18.3 Steps to reproduce: - Add date fields for multiple signers. - When the first signer signs, the date placeholder for the next signer becomes visible to the first signer. Issue: - Date fields for next signers were showing placeholders to the current signer. Fix: - Added a condition to only set the placeholder when it has a valid value. Impact: - Ensures date placeholders are visible only to the correct signer. task-5218970 Forward-Port-Of: odoo/enterprise#98256
This fix blocks saving a partner with a fiscal position that belongs to a different company. It helps avoid creating inconsistent customer/vendor records that would later fail when used on invoices.
Original PR description
It was possible to create a partner with a fiscal position from another company. Using this partner in an invoice would then raise the error like expected, but there is no reason to allow that configuration in the first place. opw-5127901
Miscellaneous changes
This pull request updates the 19.0 branch with maintenance changes. No specific business-facing feature or issue details were provided, so the impact appears limited and not expected to affect daily operations significantly.
7 changes
Enhancements to existing features
This change speeds up how product details are loaded during sales product configuration by fetching related data in batches instead of one by one. It reduces waiting time significantly, especially when products have many attributes and values, making the experience smoother for users.
Original PR description
Performing read operations on attributes and values in batch yields a significant performance improvement and is standard practice. Tested with 60 attributes and 8000 values: went from 2.7s to 0.8s (-70%) No task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Importing journal items will now accept lines linked to inactive accounts instead of failing with an unnecessary error. This makes data imports smoother when historical or temporarily disabled accounts are still referenced in the source file.
Original PR description
When importing journal items, if an item targets an inactive account, the import is causing an excessive error. We shall ignore the active/inactive flag in such a case. task-5350113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This change ensures invoice lines created from quotation templates display product details in the same consistent way as regular sales orders. As a result, the product name and description now appear correctly separated in the invoice PDF, improving readability and avoiding confusion.
Original PR description
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale…
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale and invoicing installed 2- Create a quotation template, and add a description in the line. 3- Create a quotation with the created template. 4- Confirm the order and create an invoice for the sale order. 5- Print the pdf, as seen the name and description are shown in the same line, while if the sale order was created without a template, we would have seen the description from product in the next line. ### Cause: There is a mismatch between `line.name` when it's from template and when it's from product itself, causing this issue. In the case, the line is not coming from template we have: https://github.com/odoo/odoo/blob/aaad780e897e941a3d5cf9b3a881252907ba266a/addons/sale/models/sale_order_line.py#L405-L416 in which: https://github.com/odoo/odoo/blob/aaad780e897e941a3d5cf9b3a881252907ba266a/addons/sale/models/sale_order_line.py#L432-L435 https://github.com/odoo/odoo/blob/aaad780e897e941a3d5cf9b3a881252907ba266a/addons/product/models/product_product.py#L852-L861 Which means the name will be ```python product_id.display_name + product_id.description_sale + line._get_sale_order_line_multiline_description_variants() ``` While when the quotation is coming from template the name is: ```python template_line.name + line._get_sale_order_line_multiline_description_variants() ``` As `template_line.name` is the template line description, we can add the `product_id.display_name` in `_compute_name` so both logic match. opw-5130171
This change ensures related number fields use the same database type as their source field when they have decimal precision settings. It prevents unnecessary recalculations during upgrades and avoids mismatches that could affect data storage and performance.
Original PR description
**Steps to Reproduce:** 1. create test ``Float`` field in model ``A`` with ``digits`` args 2. create ``Many2One`` field with comodel ``A`` and then create Float Field in ``B Model`` with related…
**Steps to Reproduce:** 1. create test ``Float`` field in model ``A`` with ``digits`` args 2. create ``Many2One`` field with comodel ``A`` and then create Float Field in ``B Model`` with related ``A`` model test and store True **Issue:** 1. ``column_type`` for both model table will be different. For ``test field in model A`` the ``column_type`` will be ``numeric``. But for the related field ``column_type`` ``float`` it should be ``numeric``. This happen because the @lazy_propery it hold the ``column_type`` which is ``float8`` and other related attributes from ``setup_related`` before that ``_digits`` have the null value. So, from [here](https://github.com/odoo-dev/odoo/blob/a9398502260fa57573b88fd62ca3f554e0685c7b/odoo/fields.py#L772) it remains ``float8`` it should update with ``numeric`` **Second issue comes From odoo 18.3**:= during upgrade if any new ``module`` is intalled due to dependency change and inherits the same model that is ``A``. Due to ``_auto_init`` it will recompute this related field because due to this newly [commit](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808) clear the columns column becomes [``False``] and [``not column``] becomes true from ``update_db`` and same reason as above it didn't return from [here](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808#diff-956d895aa67961bac940841f7c3d1e10eb8ecabec82ef017803c4a6a3bb7cd22R1074) because column type is ``float8`` which leads to memory of unecessary compute which shouldn't do in first place. **FIX:** Remove the ``column_type`` and let it get again as soon ``_digits`` attribute add. before fix:- ``` SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id'; column_name | data_type --------------+------------------ test_line_id | double precision (1 row) ``` After fix:- ``` SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id'; column_name | data_type --------------+----------- test_line_id | numeric (1 row) ``` opw-5222760 upg-3253635 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents a traceback when updating the analytic distribution of a locked manufacturing order that uses multiple analytic plans. It helps users avoid unexpected errors during accounting updates and keeps the workflow stable.
Original PR description
This commit only forward-ports the test ## Original issue: Updating the analytic distribution of a locked MO with multiple analytic plans raised an error, because `_create_analytic_entry()` only supports a single ID per key The issue was originally fixed in commit: https://github.com/odoo/enterprise/commit/c2648d6ff4a2f3e5234ff80a7f0ff77b2dbf4812 opw-4835165 Forward-Port-Of: odoo/enterprise#94101
When a manufacturing order quantity is increased in 3-step production, component replenishment now updates correctly for the pre-production to production flow. This ensures the system requests the right amount of stock, avoiding shortages or stale transfer quantities.
Original PR description
Issue ----- In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod,…
Issue ----- In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod, updating the producing qty doesn't update the replenishment quantity. Steps to reproduce ----- - Enable warehouses and multi-step routes - Set warehouse manufacturing to 3 step - Edit the 3 step production route - Change the pre-prod -> prod rule to mts else mto - Create a product "Comp" - Set a quantity of 5 in location pre-prod - Create a product "Prod" - Add a BoM with "Comp" as component - Create a MO for 10 of Prod - Confirm MO > There is a transfer stock -> pre-prod for 5 of Comp - Open the production quantity wizard, update value to 12 and confirm > The transfer still shows 5 of Comp instead of the needed 7 Cause ----- Changing the production quantity updates the raw moves of the MO. This triggers a write on the move with the new `product_uom_qty` so we do a `run_procurement` https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L481-L485 Before actually running any procurement we do https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L492 Since the procurement group's method is `mts_else_mto`, when we go through https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2329-L2332 we go into the `else` part and set the move's `procure_method` to mts. This means that, in the `run_procurement` method https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L504 is not true, so we don't add any procurement to run. Solution ----- In `_adjust_procure_method` we update the move's rule to the MTSO one we found https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2328 This means that we can update the check in `run_procurement` to also add a procurement to run if the move's rule is MTSO. ----- Ticket: opw-5008871
Miscellaneous changes
Two forward-port commits[^1],[^2] corrupted the POT files of these modules. They both resulted in missing `msgstr` entries causing the `msgmerge` in Weblate to fail. This commit regenerates the POT files to fix the issue. [^1]: https://github.com/odoo/odoo/commit/4e51a4a259bbb36dbbd7f6aa59ba30280f97cd89 [^2]: https://github.com/odoo/odoo/commit/f3286d792e17746d2330b5e06d5c5c8e01c52928
Original PR description
Two forward-port commits[^1],[^2] corrupted the POT files of these modules. They both resulted in missing `msgstr` entries causing the `msgmerge` in Weblate to fail. This commit regenerates the POT files to fix the issue. [^1]: https://github.com/odoo/odoo/commit/4e51a4a259bbb36dbbd7f6aa59ba30280f97cd89 [^2]: https://github.com/odoo/odoo/commit/f3286d792e17746d2330b5e06d5c5c8e01c52928
2 changes
Resolved issues and error corrections
When a delivery line is split during barcode packing, the remaining line now keeps the original package information. This ensures products that started in a specific package continue to be tracked correctly, avoiding confusion and mismatches in stock handling.
Original PR description
Steps to reproduce ----- - Enable packages - Create a stored Product "Prod" - Add a quantity of 5 "Prod" in stock, in package "PACK1" - Create a delivery for 3 units of "Prod" (so as to not move the…
Steps to reproduce ----- - Enable packages - Create a stored Product "Prod" - Add a quantity of 5 "Prod" in stock, in package "PACK1" - Create a delivery for 3 units of "Prod" (so as to not move the whole package) - Open the delivery in Barcode - Scan "Prod" - Put in pack > The new line created for the remainder of the delivery is not taken from PACK1 Cause ----- Put in pack causes the line to be split since there is some remaining quantity https://github.com/odoo/enterprise/blob/139a123637369737ae7a58eebdbc2743ce134a64/stock_barcode/static/src/models/barcode_picking_model.js#L1586-L1593 Through which we create a new line https://github.com/odoo/enterprise/blob/139a123637369737ae7a58eebdbc2743ce134a64/stock_barcode/static/src/models/barcode_model.js#L555-L559 With the origin package set as false by default https://github.com/odoo/enterprise/blob/139a123637369737ae7a58eebdbc2743ce134a64/stock_barcode/static/src/models/barcode_model.js#L617-L624 ----- Ticket: opw-5081496
This fix ensures customers cannot return more rented items than were originally picked up. It keeps rental quantities accurate and prevents inconsistent order records that could affect billing and inventory tracking.
Original PR description
## Versions 17.0+ ## Issue It is possible to return more products than what has been picked in Rental. ## Steps to reproduce - Create a service product available for rent; - Create a rental SO for any partner: - Add 5 units of the created service; - Confirm the SO; - Pickup 5; - Return 4; - Return 4; - Check the SOL containing 5 delivered products and 8 returned products. opw-5259727