Daily updates from Odoo
Monday, January 26, 2026
264 changes
16 changes
Enhancements to existing features
This update optimizes the way Odoo generates reports by grouping related database queries. Previously, each report filter triggered a separate query, which was slow. Now, multiple related filters are processed together, significantly reducing report generation times. This change improves the speed of key reports like the Generic Balance Sheet.
Original PR description
Before this commit, the 'domain' engine was never batched: one expression to evaluate caused one SQL query to be run just for it. With this commit, we group domains that could be evaluated together. Essentially, when we have domains targetting the same many2one field of account.move.line (typically account_id, with conditions like 'account_id.code' or 'account_id.account_type'), we run only one SQL query for all of them, targetting all the move lines according to the report filters. Then, we iterate on its result for each domain to evaluate. When iterating over the results, we filter the ones we keep by searching separately on each traversing model (in our example, account.account), to isolate the ones that are actually targetted by each expression. Tested on our prod. With this, opening the Generic Balance Sheet goes from 1min 35s to 36s. opw-5130725 Forward-Port-Of: odoo/enterprise#105068 Forward-Port-Of: odoo/enterprise#101725
Resolved issues and error corrections
A bug in the live chat feature was causing freezes due to a feedback loop when updating information across multiple tabs. This update fixes the issue by preventing the live chat state from continuously updating in local storage, ensuring smoother operation and preventing potential disruptions. This improves the overall stability of the live chat experience.
Original PR description
Since [1], the live chat info panel state is saved to the local storage. Writing the livechat info panel state to local storage on every field change (especially coming from the storage event itself) caused a retroaction loop across tabs, leading to potential freezes. For example: - Tab A writes OPEN to local storage. - Tab B receives OPEN and updates its field. - Tab A writes CLOSE, local storage updated. - Tab B, based on stale state, writes OPEN back to local storage. - Tab A receives OPEN, updates its field, writes CLOSE again. This PR fixes the issue: the field is only written on direct user action and the computeed field is invalidated on storage event, effectively breaking the loop. [1]: https://github.com/odoo/odoo/pull/238472 Forward-Port-Of: odoo/odoo#245697
This update adjusts the location of configuration files within the IoT drivers, ensuring they can be correctly identified and upgraded after a recent system change. This change is necessary to maintain the functionality of the IoT drivers and prevent potential issues with package updates. It’s a routine maintenance task.
Original PR description
As we moved configuration folder in `setup/iot_box_builder`, we need to adapt the path to find them. Related PR: https://github.com/odoo/odoo/pull/229698
This update fixes an issue where the Follow-Up Report displayed full account amounts instead of the remaining amounts when reconciled entries were present. This change ensures users accurately see the outstanding balances, improving reporting and financial analysis.
Original PR description
Currently, when viewing the followup report with reconciled entries, we display full amounts instead of the residual amounts. task-5868881
This update fixes issues where self-order pricing didn't consistently apply pricelist rules to product variants. Now, the checkout page and product pages accurately display the correct price based on the selected variant and associated pricelist rules. This ensures accurate pricing for self-order transactions.
Original PR description
This PR fixes 2 bugs in self order when we are dealing with variants. The first bug in commit https://github.com/odoo/odoo/commit/0cd3a64955052b7fb5507f8fbb3414e0a894250d The order pricelist_id was…
This PR fixes 2 bugs in self order when we are dealing with variants.
The first bug in commit https://github.com/odoo/odoo/commit/0cd3a64955052b7fb5507f8fbb3414e0a894250d
The order pricelist_id was not taken into accounting when adding a line corresponding to a product variant. So any price rules acting on the variant, that are specific to the current pricelist, will not be applied.
The second bug in commit https://github.com/odoo/odoo/commit/77dbf4b2cf1b1dea3bb5ba107da83e13e5283afb
The product page was displaying the price of the default product, instead of that of the selected variant.
A third commit https://github.com/odoo/odoo/commit/bf2e3d90e3f3405db9be78acfdf2558bf47b449a was to fix `price_extra` calculations and make it consistent between the product page and the rest of the app.
I have included the steps to reproduce and more details about the fixes separately in each commit.
However, the reproduction steps are the same:
1. Make a product with 2 variants, size S and M for example.
2. Create 2 pricelists, A and B, and make them available in PoS. The
default one should be A.
3. For the created product, create 2 price rules:
1. One changing the price of the variant S for the pricelist B
2. One changing the price of the variant M for the pricelist B
4. Enable mobile self order and create a peset that applies the
pricelist B
5. Open self order, and select that preset (it should apply the
pricelist B).
6. Select the product of step 1, and choose the variant M.
opw-5467593
Forward-Port-Of: odoo/odoo#243304This update fixes a problem with the Point of Sale tour, ensuring it consistently guides users through the setup process. The team addressed a generic error message and a timing issue within the tour, improving the overall user experience. These changes were made to enhance the ease of use for new Point of Sale users.
Original PR description
In this commit, we add few steps in the tour to ensure the tour take always the good way. Few python assertions between has been added to know where the unit test fails (easier to debug). We take advantages of this commit to fix few utils: - Dialog.cancel() was too generic. We add at least title to let the possibility to be more precise. - selectPresetTimingSlotHour() has been fixed to wait the good triggers in the DOM before the tour continues. runbot-error-id 237756 runbot-error-id 237762 Forward-Port-Of: odoo/odoo#243799
This update fixes a calculation error in the Austrian VAT tax report. Previously, the report incorrectly subtracted deductible input tax, leading to inaccurate VAT payable or credit figures. The fix adds the deductible input tax to the calculation, ensuring the report accurately reflects Austrian tax regulations.
Original PR description
The Austrian tax report computes line 7 by subtracting the deductible input tax instead of adding it, leading to an overstated VAT payable or understated credit. ### **Steps to reproduce:** - Install…
The Austrian tax report computes line 7 by subtracting the deductible input tax instead of adding it, leading to an overstated VAT payable or understated credit. ### **Steps to reproduce:** - Install `Accounting` app with `l10n_at` localization and switch to AT Company. - Create a customer invoice for some product with price 1000 and 20% Tax. - Create a vendor bill for some product with price 100 and 20% Tax. - Open the Austrian tax report for the corresponding period. ### **Observed behavior:** section-7 shows `-220` instead of the correct amount `-180`. because value of, section-4 = -200 section-5 = 20 section-6 = 0 Current calculation for **section-7 = section-4 - section-5 + section-6** which is equal to `-220` ### **Expected behavior:** 1) Section-4(VAT Computation (U1/U30))- negative value is correct as this is the amount of sales tax which needs to pay to the tax office. 2) Section-5(Deductible input tax computation) and section-6(Other corrections) - are positive values and are added to section-4 as this is the input tax which is get back from the tax office. hence the correct calculation for **section-7 will be section(4+5+6).** ### **Root cause** Since [commit](https://github.com/odoo/odoo/pull/224604/commits/06666fc55a7a3f569a0d15f0827ed8e2199cf51c), introduced a formula that subtracts the deductible input tax(section-5) in section-7, causing the miscalculation. ### **Fix** Update the section-7 aggregation formula to add deductible input tax instead of subtracting it. **opw-5476604** Forward-Port-Of: odoo/odoo#245174
A recent issue preventing the demo mode of the Account PEPPOL module from connecting correctly has been resolved. The fix addressed a minor discrepancy in how the connection was being established, ensuring the demo mode now functions as expected. This improves the usability of the PEPPOL demo for testing and training.
Original PR description
There is one argument too much for the mock of _create_connection compared to the real one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245678
This update resolves an issue where saving link tracker records with URLs (like `https://demo.com`) would cause an error. The fix ensures that URLs entered in the 'Code' field adhere to the required format, preventing the error and allowing users to successfully save link tracker records with URLs.
Original PR description
Saving a link tracker record fails when the user enters a URL in the Code field. Steps to reproduce the error: - Install ``link_tracker`` module - Create a new link tracker record with Target Link >…
Saving a link tracker record fails when the user enters a URL in the Code field. Steps to reproduce the error: - Install ``link_tracker`` module - Create a new link tracker record with Target Link > Save - Edit the record and set Code: ``https://demo.com`` > Save Traceback: ```py ValueError: Extra URL must use same scheme and host as base, and begin with base path ``` https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/addons/link_tracker/models/link_tracker.py#L77 After this commit: https://github.com/odoo/odoo/commit/977e62d91f3e8235e251e9d21b08f53db1856c6b, When the user sets the code as ``https://demo.com``, Error will be raised from [1], because the extra URL must use same scheme and host as base, and must begin with the base path. [1]: https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/odoo/tools/urls.py#L55-L58 sentry-7022131826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235491
This update fixes an issue where payment references on Italian invoices were incorrectly populated with a unique invoice number. Now, the payment reference field only uses the actual payment reference provided by the partner, simplifying automated payments and aligning with Italian tax regulations. This ensures accurate reconciliation of payments and improves the efficiency of financial processes.
Original PR description
Description of the issue/feature this PR addresses: The payment_reference field in invoices was being filled with a wrong field from the imported XML, progressivoinvio is the progressive number of invoices sent by the partner's system, not a partner's requested payment reference. Current behavior before PR: On import, payment_reference was being filled with ProgressivoInvio, making automated payments out to partners harder. Desired behavior after PR is merged: payment_reference is only being filled if partner specifies a payment reference in the EDI, avoiding confusion. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245058
This update fixes a visual issue where product attributes with single values were displaying incorrectly with empty borders. The change refines the CSS selector to accurately hide attribute sections, ensuring a cleaner and more consistent user experience for product browsing. This improves the overall presentation of product information.
Original PR description
Before this commit, when a product attribute with display_type 'pills' has only one non-custom value, the parent li.variant_attribute is correctly hidden. However, the CSS :has() selector still matched the inner li.o_variant_pills, causing the attributes section to display with empty borders. This commit refines the selector to only match pills outside of variant_attribute elements (UOM pills). task-5852515 | Current (19.0) | After | |--------|--------| | <img width="809" height="395" alt="image" src="https://github.com/user-attachments/assets/64519161-e552-492f-b010-d1353b07f80a" /> | <img width="809" height="395" alt="image" src="https://github.com/user-attachments/assets/6022e371-18eb-4d2a-99d0-da3c94b291d0" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245175
This update ensures that LNA (a security feature) is consistently enabled for IoT devices across all Odoo POS systems, including kiosks. Previously, LNA was only active in the POS, creating a potential security gap. This change strengthens security and improves the overall performance of self-order IoT devices.
Original PR description
Before this commit, LNA was being used for IoT devices in the POS but not in the Kiosk when `point_of_sale.use_lna` was enabled. After this commit, LNA will also be enabled for IoT devices in the Kiosk. task-5874663 Forward-Port-Of: odoo/enterprise#105460
This update optimizes how category data is loaded on the website, resolving a previous issue that caused excessive memory usage. The change reduces the amount of data processed, leading to faster website loading times and a smoother user experience. This improves overall website performance.
Original PR description
Previously the function was fetching all the product template ids and looping over them for each product template. This triggered the prefetch_ids and prefetch fields for these products which would cause memory issues due to the bloat of the cache from the prefetcher. The current way is a read_group over the categories and check if category id exists or not. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239499
This update resolves a visual issue where Marketing blocks sometimes displayed incorrectly due to a problem in how the system converted table layouts. The fix ensures that tables render consistently, regardless of column sizes, preventing layout overflows and maintaining a professional appearance. This improves the overall user experience for users creating and viewing Marketing content.
Original PR description
This reverts commit 0ffb96dedc776552564cec28140340ec38dee9d1. The commit was incomplete and while it prevented the crash, the resulting table did not match the expected layout. Original issue:…
This reverts commit 0ffb96dedc776552564cec28140340ec38dee9d1. The commit was incomplete and while it prevented the crash, the resulting table did not match the expected layout. Original issue: Problem: The grid conversion logic only finalized a row when iterating through the last column in the input list. If a row reached exactly 12 grid spans while more columns remained (e.g., a `col-12` in the middle), the logic did not start a new row. As a result, remaining columns overflowed the current row visually. Cause: In a single row, if a column had a size 12 and was followed by another column of any size, it would crash because the algorithm did not reset the index to the start of the next row. Steps to reproduce: - Add a Marketing block. - Reduce the size of the left card from the left side.<img width="719" height="580" alt="image" src="https://github.com/user-attachments/assets/1e62eaf7-6ab1-4120-b643-62427ce3ec3a" /> - Save. - Traceback. Solution: This more thorough fix properly handles all problematic aspects: - filter conflicting `col-x` instructions on a single element to keep only one size - ensure that a gridIndex of 12 does not cause a crash in the algo - properly add all effective `td` in a row in all circumstances (there where cases where the final row could be omitted) opw-5439481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245674
This update resolves an issue where Stripe-created expense records were being duplicated, causing confusion and errors in the system. By preventing the duplication, we ensure accurate expense tracking and streamline the process for employees. This improves data integrity and reduces potential reconciliation problems.
Original PR description
Prevent expenses automatically created by Stripe Issuing to be duplicated. Currently, it adds a lot of noise on customer dbs. The payment method is duplicated and it can lead to errors (eg: employee submit duplicatas instead of the original expenses. The automatic reconciliation doesn't happen afterwards) task-5246475 Forward-Port-Of: odoo/enterprise#102034
This update resolves issues where smart buttons on VoIP call forms were missing access groups, causing errors and incorrect numbers to display. The fix ensures these buttons function correctly, improving the user experience when initiating VoIP calls across various modules like CRM, Helpdesk, and Sales.
Original PR description
1. Tickek/Application smart buttons on voip.call form miss access groups. 2. In voip.call form, when clicking the application smart button, a singleton error will raise. 3. Incorrect numbers on smart button. Task-[5461729](https://www.odoo.com/odoo/5778/tasks/5461729) Forward-Port-Of: odoo/enterprise#103233
6 changes
Resolved issues and error corrections
This update fixes an issue where the 19%I tax code (9) was missing from Datev exports for expense journal entries. The problem stemmed from how payment amounts were aggregated, leading to a loss of tax information. This ensures accurate tax reporting in Datev.
Original PR description
Currently, when using 19%I tax in vendor bills, the tax code (9) is shown correctly in the BU-Schlüssel section of the datev export. This however is not the case for expense journal entries. Steps to reproduce: - With DE Company setup - Create an Expense as follows: - Included taxes: 19% I - Paid by: Company - Create report > Submit to Manager > Approve > Post Journal entries - Open General Ledger and export Datev Data Issue: Tax code will be missing from the exported entry. This occurs because, when processing payment move lines, amounts and accounts are aggregated, losing track of the source tax. opw-5388791 Forward-Port-Of: odoo/enterprise#105435 Forward-Port-Of: odoo/enterprise#102548
This update resolves a test failure in the web_studio module caused by a missing dependency. The fix ensures that all required modules are included in the test, preventing false failures and improving test reliability. This ensures consistent test results and prevents disruptions to the system.
Original PR description
`RELATED_MODELS_TO_EXCLUDE` contains `account.edi.document`, which is installed by `account_edi`, which is neither in the `needed_modules` set nor a dependency of any of them. Therefore the test can fail because `account_edi` is not installed even though every module in the set is. Improve the test by checking that the models or fields we're checking for actually belong to the modules we've listed. Also add the missing module in the list. Forward-Port-Of: odoo/enterprise#105408 Forward-Port-Of: odoo/enterprise#104879
This update corrects a bug that prevented users from clicking the 'Validate' button after an invalid operation in the stock barcode system. The issue stemmed from a previous attempt to manage concurrency, which incorrectly blocked the button. The fix now relies on the framework's mutex mechanism for reliable validation, ensuring the button remains functional.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps route - Create a product tracked by SN - In the barcode app > Operations > Internal transfers > New - Scan you tracked product - Click on…
### Steps to reproduce: - In the settings enable: Multi-Steps route - Create a product tracked by SN - In the barcode app > Operations > Internal transfers > New - Scan you tracked product - Click on Validate > Invalid operation - Scan a Serial number #### > You can not click on validate anymore ### Cause of the issue: The issue has been introduced in 41c6e7a90fd4f0cf84e74cf0ed036f4da0ec6112 in a try to avoid concurrency issue when calling the barcode validation too quickly. To be more precise, this commit added a `isValidating` property to the barcode model that is set prior to the rpc call and suppose to remove after in order tobypass subsequence calls of the `validate` method when a call is already in progress: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L477-L494 However, in the present case and since orm call returns an error the the call the validate method is interupted at this orm call and the line https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L494 is not executed so that the this.Validating stays true and the button can not be clicked nor executed anymore: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L131-L133 ### Fix: We revert the incorrect fix: 42d77e751cb5e049ea1e81b44fca0d07e8f45b32 and we rather rely on the Mutex class of the JS framework just as done in the `_processBarcode`: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L505-L507 This will ensure that the validation calls will be processed sequentially and since the `button_validate` of stock pickings is ignored on done pickings because of the first soft fix https://github.com/odoo/odoo/pull/204790 : https://github.com/odoo/odoo/blob/1664daf894ec878b64af8ab75c0d10f05e00df80/addons/stock/models/stock_picking.py#L1134-L1135 we have the guarantee that the records will not be validated twice. opw-5388297 Forward-Port-Of: odoo/enterprise#104352 Forward-Port-Of: odoo/enterprise#103835
This update ensures that LNA (a security feature) is consistently enabled for IoT devices across both the POS and Kiosk systems. Previously, LNA was only active in the POS when enabled, creating a potential security gap in the Kiosk. This change enhances security and ensures consistent functionality for IoT-enabled point-of-sale transactions.
Original PR description
Before this commit, LNA was being used for IoT devices in the POS but not in the Kiosk when `point_of_sale.use_lna` was enabled. After this commit, LNA will also be enabled for IoT devices in the Kiosk. task-5874663 Forward-Port-Of: odoo/enterprise#105460
This update corrects an error that prevented the creation of new contract templates in the US payroll module. The system was incorrectly enforcing a requirement for a filing status, which doesn't apply to templates. This change ensures that contract templates can now be created without causing errors, aligning with the correct process of determining filing status per employee.
Original PR description
1. Set "My US Company" state to California, 2. Go to Employees > Employees > Contract Templates, 3. Click New, 4. Fill in a name and save, 5. Invalid Operation: "The employee state filing status is empty..." A constraint ensures an l10n_us_state_filing_status is set on `hr.version`. The field is used by the salary rules. This field used to be on `hr.employee` and was moved to `hr.version` [1]. There's two types of `hr.version` records: templates without employee_id and actual contract versions linked to an employee. We don't want to evaluate the constraint for the templates, the only way to set a filing status is through the employee so it will always raise. This is functionally correct as well, contract templates should not have a hardcoded filing status, this should be determined per employee. The constraint will now only raise when loading a contract template on the employee or editing the field through the employee. [1] odoo/enterprise#83136 opw-5458566
This update corrects a technical issue preventing the proper validation of vendor bills in the ARCA system. The change ensures the required 'CodAutorizacion' field is correctly included in the data sent for verification, resolving errors related to missing information. This ensures accurate bill processing and compliance with Argentine regulations.
Original PR description
In this commit https://github.com/odoo/enterprise/pull/103370/changes#diff-2459e118c605cf039bb94c62561285ad753b6a27c571f10a25547ee9b01aa318R289 where a refactor has been made, the field 'CodAutorizacion' was left as 'invCodAutorizacion' on _l10n_ar_edi_get_request_data_verify. This leads to errors when validating vendor bills on ARCA, since the organism could not find the required field. <img width="640" height="163" alt="image" src="https://github.com/user-attachments/assets/74a0cdc6-c007-474c-a67b-fd12d484838f" /> Forward-Port-Of: odoo/enterprise#105362
6 changes
Resolved issues and error corrections
This update resolves an issue where users with limited sign rights couldn't access the sample template. The fix changes a security setting to allow template item creation, ensuring all users can utilize the sample document for signature requests. This improves usability for all users.
Original PR description
**Issue** Users without 'Admin' Sign rights could in some cases not access the sample template. **Steps to reproduce** 1. Go to 'Templates' and archive the existing one in order to have the 'Try our sample document' shown and click on it. 2. Add some sign items to the template, and send it for a signature request. 3. With an user having only 'User: Own Templates' Sign rights, go to 'Templates' and click 'Try our sample document'. Access Error: Blame the following rules: - sign.item: group_sign_user: Create and manage template items **Cause** When the template has an associated sign request, it is copied. The problem is that the user currently doesn't have enough rights to create sign items for the copied template: https://github.com/odoo/enterprise/blob/2e8fb2ca274a0cf15d7b78a663bffe9cbb700153/sign/security/security.xml#L92-L101 **Change** Change the `user_id` of the new template to allow creating the sign items for it. opw-5254566
This update fixes an issue where multiple product filters were not consistently saved during pagination, leading to incorrect product listings. The fix ensures that all selected attribute filters are correctly passed to the URL, maintaining accurate filtering across pages. This improves the user experience and ensures consistent product results.
Original PR description
Current behavior: When a user selects multiple filters (attributes) that result in multiple pages of products, navigating to the second page causes some filters to be lost. Specifically, only the…
Current behavior:
When a user selects multiple filters (attributes) that result in multiple pages of products, navigating to the second page causes some filters to be lost. Specifically, only the last selected attribute value is kept in the URL of the pager.
This happens because the `/shop` controller processes query parameters using a standard Python dictionary (**post). Since a dictionary cannot hold duplicate keys, an URL like `?attrib=1&attrib=2` is reduced to `{'attrib': '2'}`, losing all previous values.
Steps to reproduce:
1. Install `website_sale`.
2. Reduce "Products per Page" (e.g., to 4) to easily trigger pagination.
3. Go to the /shop page.
4. Select a first attribute (e.g., Color: White).
5. Select a second attribute (e.g., Size: M).
6. Ensure the result spans at least two pages.
7. Click on page "2".
8. Observation: The second attribute filter is lost, and the product list changes incorrectly.
Fix:
Ensure that `attribute_values` are stored as a list within the `url_args` passed to the pager. Since Odoo's `website.pager` uses `url_encode` internally, passing a list of values for a single key correctly generates repeated parameters in the resulting URL (e.g., `attrib=1&attrib=2`).
opw-4152637This update fixes an issue where invoices were incorrectly using a progress number instead of the actual payment reference provided by the partner. Now, the payment reference field in Italian invoices will only be populated with the payment reference specified by the partner, ensuring accurate automated payments and reconciliation. This improves the process of receiving and managing payments from our Italian business partners.
Original PR description
Description of the issue/feature this PR addresses: The payment_reference field in invoices was being filled with a wrong field from the imported XML, progressivoinvio is the progressive number of invoices sent by the partner's system, not a partner's requested payment reference. Current behavior before PR: On import, payment_reference was being filled with ProgressivoInvio, making automated payments out to partners harder. Desired behavior after PR is merged: payment_reference is only being filled if partner specifies a payment reference in the EDI, avoiding confusion. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245058
This update resolves a technical issue where the demo data for the Mexican payroll modules incorrectly set the company and partner names during installation. This prevented proper CFDI stamping of invoices and payment complements in the demo databases, ensuring a stable and functional demo environment.
Original PR description
The demo data of the Mexican payroll modules was overriding the company and partner name during installation, which can break the CFDI stamping flow for invoices and payment complements in demo databases. Forward-Port-Of: odoo/enterprise#103870 Forward-Port-Of: odoo/enterprise#102558
This update resolves an issue where users would encounter an error when creating inherited views. The fix ensures that a validation error is triggered if the XPath configuration is incomplete, preventing the 'TypeError' and improving the user experience when customizing views.
Original PR description
Currently, an error occurs when a user creates an inherited view. **Steps to Reproduce:** - Go to `Settings > Technical > User Interface > Views`. - Create a new view by entering `name` and selecting…
Currently, an error occurs when a user creates an inherited view.
**Steps to Reproduce:**
- Go to `Settings > Technical > User Interface > Views`.
- Create a new view by entering `name` and selecting any `inherited view`.
- In the `Architecture`, enter the below code:
```
<xpath position="replace">
<field name="name"/>
</xpath>
```
- Now save the view.
`TypeError: Argument must be bytes or unicode, got 'NoneType'`
Cause:
As we can see, when the user enters an xpath without the expr attribute, and when it goes to find the inherited node [1]. Since the expr is missing, its value becomes None [2]. Passing this None as an argument [3] causes the error.
This commit ensures that when a user creates or edits a view with an xpath that is missing the expr attribute, a ValidationError is raised indicating that the expr attribute is missing in the XPath.
[1]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L145
[2]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L76
[3]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L78
[4]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/addons/base/models/ir_ui_view.py#L377-L384
sentry-7161414430
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242203This update corrects a technical issue preventing the proper validation of vendor bills in Argentina (ARCA). The change ensures the required 'CodAutorizacion' field is correctly included in the data sent for verification, resolving a validation error that was impacting bill processing. This ensures accurate and timely processing of invoices.
Original PR description
In this commit https://github.com/odoo/enterprise/pull/103370/changes#diff-2459e118c605cf039bb94c62561285ad753b6a27c571f10a25547ee9b01aa318R289 where a refactor has been made, the field 'CodAutorizacion' was left as 'invCodAutorizacion' on _l10n_ar_edi_get_request_data_verify. This leads to errors when validating vendor bills on ARCA, since the organism could not find the required field. <img width="640" height="163" alt="image" src="https://github.com/user-attachments/assets/74a0cdc6-c007-474c-a67b-fd12d484838f" /> Forward-Port-Of: odoo/enterprise#105362
2 changes
Enhancements to existing features
This update expands Odoo's language support to include Spanish, recognizing the significant number of Spanish speakers. By adding Spanish translations, we improve the usability of Odoo for a wider range of customers and users. This enhancement aligns with our commitment to global accessibility.
Original PR description
The official language is English, but Spanish is spoken by ~41 million. task-5247124 Forward-Port-Of: odoo/enterprise#105246
Resolved issues and error corrections
This update removes outdated test code related to exchange rate precision in the l10n_mx_edi module. A previous fix inadvertently left this code in place, and this PR ensures a cleaner and more streamlined testing environment. This resolves a minor technical issue.
Original PR description
The PR #102557 fixed an issue with exchange rate precision for Solution Factible. However, its forward ports for 18 (PR #104195) and saas-18.2 (PR #104673) did not properly delete some of the old test code. This PR deletes that code. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200) Forward-Port-Of: odoo/enterprise#105339
8 changes
Enhancements to existing features
This update enhances the employee contract creation process in the Odoo Enterprise system. Specifically, a new condition now prevents users from creating a new contract if the start date is missing and the employee has only one version or hasn't been fully created. This streamlines the workflow and avoids potential errors.
Original PR description
- added a condition to hide New Contract button if contract start date is empty and the employee only has 1 version or if the employee is not created task-id: 5075255
This update enhances the user experience within the Odoo Discuss meeting view by increasing the size of key buttons and refining the visual design. Specifically, the layout and button styling have been adjusted for better usability, along with smaller avatar images and a modernized card name appearance.
Original PR description
- bottom buttons in meeting view are bigger - layout buttons in meeting view are moved with side meeting actions - side meeting actions uses non-bg visual - meeting bottom buttons now have hover effect Also makes these other UI changes to discuss calls: - card name has text-shadow instead of dark bg color - avatar img size has been reduced (100px to 80px, was too big) Task-5462123 Before / After <img width="959" height="644" alt="Screenshot 2026-01-02 at 18 16 50" src="https://github.com/user-attachments/assets/b2bd4128-c298-4bfe-9843-4ff9aa2a7595" /> <img width="954" height="639" alt="Screenshot 2026-01-02 at 18 01 24" src="https://github.com/user-attachments/assets/5b954d86-e65e-4c97-8485-9c62200f60b0" /> Forward-Port-Of: odoo/odoo#241924
Resolved issues and error corrections
A test failure related to employee assignments within the MRP Work Order module has been resolved. The fix prevents a constraint error that occurred when multiple employees were repeatedly assigned to the same user, ensuring consistent test results. This improves the reliability of our core work order processes.
Original PR description
Before this commit, the test `test_allowed_employees_restriction` was failing because two different employees of the same company were assigned one after another to a same user. When the changes are commited, the constraint `_user_uniq` was triggered. Solution: use a different user instead of reassigning to the same one so that the constraint isn't triggered when setting another employee to the user. fixes odoo/enterprise#96931 runbot error 234537 Forward-Port-Of: odoo/enterprise#103833
This update fixes issues related to how tax information is processed for HR documents, particularly those using the UBL (Universal Business Language) standard. It now displays warnings instead of silently skipping documents, providing clearer information for users and improving the reliability of tax calculations. This ensures accurate tax reporting for HR-related transactions.
Original PR description
- Improving error handling for various requests - Adjusting XML generation to not conflict with `account_edi_ubl_cii_tax_extension` if it is installed - Adding a separate test for HR:E category taxes - Replacing skipping import of not successfully fiscalized document with warnings displayed on the moves after import task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245625 Forward-Port-Of: odoo/odoo#245028
This update fixes a build error that occurred when displaying call status badges, preventing a crash in certain scenarios. The issue stemmed from an undefined 'id' value within the call status calculation logic. The fix ensures the correct record ID is used, regardless of whether the call is a real or virtual record, improving stability.
Original PR description
We fix the build error 238415: _Cannot read properties of undefined (reading 'isInProgress')_. That error is raised in the class UserAgent ```js isInProgress(callId) { return (…
We fix the build error 238415: _Cannot read properties of undefined (reading 'isInProgress')_.
That error is raised in the class UserAgent
```js
isInProgress(callId) {
return (
(this.mainSession?.call?.id === callId && this.mainSession.isInProgress) ||
(this.transferSession?.call?.id === callId && this.transferSession.isInProgress)
);
}
```
because both this.mainSession and callId are undefined in the test context.
### Root cause
In the class CallStatusBadgeField
```js
get statusLabel() {
const isInProgress = this.isInProgress(this.props.record.data.id);
const { direction, state } = this.props.record.data;
return Call.getStatus({ direction, isInProgress, state });
}
```
isInProgress is called with this.props.record.data.id but id can not be found in this.props.record.data so that when there
is no main voip session, the crash occurs.
Actually, for a real record, the id is given by this.props.record.resId and for a virtual record (a record not already created in db) the id is given by this.props.record.virtualId. Note that resId and virtualId are never both defined.
### Fix
Since a session is always linked to a read record, we pass to isInProgress the id given by this.props.record.resId but we have to protect us from the case were the record is virtual. Hence the use of the optional chaining operator in case the sessions would not be defined.
runbot-error-238415This update prevents the OCR from automatically updating a user's address information when processing QR-bills. Previously, the system would incorrectly overwrite existing partner details, causing confusion for users who receive QR-bills via email and forward them. This change ensures accurate address data is maintained, streamlining the billing process.
Original PR description
When the OCR detects that the document is a QR-bill, it will always overwrite the address information from the partner currently set on the record. We shouldn't do that if the partner wasn't created by the OCR. In the following scenario, it's pretty obvious why it is a bad idea: - User receives his QR-bills on his personnal email address. - He forwards it to the email alias set up for vendor bills. - A vendor bill is created with himself set as the supplier (already a bit annoying for him) - The OCR automatically analyses the document and updates the user's record with the address found in the QR-bill (really annoying). The same issue can arise if the user manually sets a supplier before sending the QR-bill for digitization. task-none Forward-Port-Of: odoo/enterprise#105343 Forward-Port-Of: odoo/enterprise#104902
Features or functions removed from Odoo
This update removes an outdated field used to track live chat operators, streamlining the system. Previously, this information was often inaccurate and could be reliably obtained from channel history. This change improves data accuracy and simplifies the live chat process.
Original PR description
*: ai_crm_livechat,website_helpdesk_livechat The `livechat_operator_id` field was used while not being completely accurate. Indeed, this field was updated only once when changing from chatbot to a real agent. On top of that, all this information can be reliably derived from the `livechat_channel_member_history`. This commit tries to remove this field and make use of other ways to find the right information depending on what is needed. task-4854887 See odoo/odoo#240778
Code cleanup and technical improvements
This update removes an outdated field used to track live chat operators, improving data accuracy. The system now relies on historical channel membership data for reliable information. This change simplifies the live chat system and enhances data management.
Original PR description
*: crm_livechat, website_livechat The `livechat_operator_id` field was used while not being completely accurate. Indeed, this field was updated only once when changing from chatbot to a real agent. On top of that, all this information can be reliably derived from the `livechat_channel_member_history`. This commit tries to remove this field and make use of other ways to find the right information depending on what is needed. task-4854887 See odoo/enterprise#102570
17 changes
Enhancements to existing features
This update enhances the Point of Sale interface by providing clear visibility into LNA permission status. A new button in the navigation bar displays the current status and opens a popup with detailed information, allowing users to quickly understand access rights. This improves transparency and streamlines operations related to LNA permissions.
Original PR description
Before this commit it was not possible to know if LNA permission was granted, denied or not yet granted from the POS interface. This commit adds a button in the navbar to show the current LNA status and open a popup with more information. taskId: 5874947
Resolved issues and error corrections
This update resolves an issue where customers exceeding their sales credit limits weren't being properly flagged in the Point of Sale (POS) system. The fix ensures that warnings are displayed when a customer's purchase total surpasses their defined credit limit, preventing potential overspending and improving financial control. This enhancement impacts the customer experience and financial accuracy.
Original PR description
Steps to reproduce: ------------------- 1. Install pos_settle_due and accountant 2. In Accounting settings, enable "Sales Credit Limit" 3. Create a new customer, enable its "Partner Limit" and set it…
Steps to reproduce: ------------------- 1. Install pos_settle_due and accountant 2. In Accounting settings, enable "Sales Credit Limit" 3. Create a new customer, enable its "Partner Limit" and set it to 100 4. Open PoS, select that partner, and select products such that the total exceeds 100 Notice that even though we have exceeded that partner's limit of 100, there are no indicators on the customer button (orange background on hover), nor there are warnings on the partners list modal nor on the payment page. Why the bug ----------- In `getPartnerCredit`, we are using `order.amount_total` to get the current ordre amount, however, this field is `undefined` for a new order and it's been assigned a value in `setOrderPrices`, which since [9538698](https://github.com/odoo/odoo/commit/9538698), is only called before sending the order to the backend. The fix ------- Now we read the total amount from the getter `order.priceIncl`, and round it as we would do in `setOrderPrices`. opw-5489975
This update resolves a visual glitch in the time-off interface for Belgian employees. Previously, sickness relapse fields appeared unexpectedly after approving time off. The fix adjusts the layout to properly position these fields, ensuring a consistent and user-friendly experience.
Original PR description
Bug production steps: Select employee works in Belgium company, go to timeoff and approve >= 1 months time off and select new timeoff after 1-2 days and there Sickness Relapse fields occur in the shifted UI. Bug cause: The field sickness_relapse added after attach file part, before there was label for the attach file part and it was occupying 2 columns, after removing column it occupies only 1 and the first part of the boolean sickness relapse fields come next to the attach file part. Bug solution: Make the colspan 2 for the attach file part, by that way the sickness_relapse will start from the below line. task - 5493425 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243753
This update fixes an issue where the tax code (9) was missing from Datev exports for expense journal entries when using 19%I tax. The problem stemmed from how payment amounts were aggregated during the export process. This ensures accurate tax reporting for German companies when exporting financial data to Datev.
Original PR description
Currently, when using 19%I tax in vendor bills, the tax code (9) is shown correctly in the BU-Schlüssel section of the datev export. This however is not the case for expense journal entries. Steps to reproduce: - With DE Company setup - Create an Expense as follows: - Included taxes: 19% I - Paid by: Company - Create report > Submit to Manager > Approve > Post Journal entries - Open General Ledger and export Datev Data Issue: Tax code will be missing from the exported entry. This occurs because, when processing payment move lines, amounts and accounts are aggregated, losing track of the source tax. opw-5388791 Forward-Port-Of: odoo/enterprise#105435 Forward-Port-Of: odoo/enterprise#102548
This update resolves an issue preventing refunds for NFC-e transactions in the Point of Sale (PoS) system. Previously, a technical error caused a 'not found' message when attempting to process refunds. The fix ensures that the system correctly identifies and processes NFC-e refund requests, improving PoS functionality.
Original PR description
**Steps to reproduce:**
- Setup a database that supports NFC-e
- Go to PoS, make a purchase, then refund it
- A traceback appears, saying we couldn't find the original invoice
**Why the fix:**
Before this commit the way we checked if there was already an invoice in the payload we give to the API was wrong, as it was always true. This happens because before the
*def _get_l10n_br_avatax_service_params(self):* call, we set res['invoice_refs'] as {}, then we were supposed to fill it. But if we check https://github.com/odoo/enterprise/blob/32b73b12f9f8f5600b820d9a938bfbb0cf10054d/l10n_br_edi_pos/models/account_move.py#L13 'invoice_refs' is found in res, even though it is empty, so we never entered the if statement.
We now check if there is a value in res['invoice_refs'] and if not we set it.
opw-5359407
Forward-Port-Of: odoo/enterprise#102770This update resolves an issue where image snippets weren't consistently updating across the website builder. The fix ensures that the correct image element is always used when processing snippets, leading to more reliable image display and functionality. This improves the user experience when adding images to website pages.
Original PR description
[FIX] html-builder, *: update snippet at each snippet dropped handler *: website In the `ImageSnippetOptionPlugin`, at the `on_snippet_dropped_handlers` call, the `snippetEl` received as argument is replaced by the image selected by the user in the media dialog. The problem is that the call to subsequent handlers is done with `snippetEl` that is not an element of the DOM anymore. This commit fixes this by updating `snippetEl` if needed after each call to a `on_snippet_dropped_handlers` handler. task-5785233 Forward-Port-Of: odoo/odoo#243766
This update fixes a visual glitch in the image gallery where slides would appear blank briefly, particularly on Firefox. It improves performance by preloading carousel images and updating the GallerySlider interaction to handle more images, preventing indicator crowding.
Original PR description
## [FIX] website: add versioning for GallerySlider interaction The GallerySlider interaction (and its edit mode counterpart) is not up to date: the logic is still written for old snippets (before…
## [FIX] website: add versioning for GallerySlider interaction
The GallerySlider interaction (and its edit mode counterpart) is not up
to date: the logic is still written for old snippets (before [9042b1c],
so before 18.0).
In the meantime, the pagination for the indicators was lost, meaning
that if you add too many images, the indicators will have less and less
space.
Steps to reproduce:
- Drop an Image Gallery snippet
- Set the indicators to squared or rounded miniatures
- Add 15 or more images
=> All the indicators are crammed into the same line.
With this commit, we deprecate the old `GallerySlider` interaction and
create a `GallerySlider001` for the snippets dropped since 18.0.
For the indicators, instead of a pagination, we now use a horizontal
scrolling container which centers on the active indicator.
[9042b1c]: https://github.com/odoo/odoo/commit/9042b1c
## [FIX] website: preload available carousel images
As images are lazy loaded, it means that in the context of a carousel or
an image gallery, they only start loading once the user clicks either on
its indicator or on the previous / next button (or after completing an
auto-slide). While Chrome seems to optimize that to make it seemless, on
Firefox this causes the carousel slide to appear blank for a moment
before the image suddenly pops up, as the sliding animation arrives to
its end.
In effect, this causes a flicker and a feeling that the carousels, and
especially the gallery, is extremely laggy.
To mitigate that while trying to keep the advantages of image lazy
loading, this commit partially backports [08d837e], which loads the
images of the next and the previous carousel items.
Additionally, we prefetch the target images on pointerdown / keydown on
an indicator. That may seem like too small of a difference to be
interesting, but it actually gives a little bit of time between the
pointerdown and pointerup (which triggers the slide event) to start
loading the images, which with a correct connexion already goes a long
way towards mitigating the laggy feeling.
[08d837e]: https://github.com/odoo/odoo/commit/08d837e70f28a84a9bd97974f5d15d387a42b7c0
task-5245513
Forward-Port-Of: odoo/odoo#244823
Forward-Port-Of: odoo/odoo#232147This update fixes a bug where tax return names and status indicators weren't correctly translated when a new language was installed in Odoo. The solution automatically generates translations for all existing tax return names upon language installation, ensuring consistent and accurate reporting across multiple languages. This improves the user experience for international users.
Original PR description
**Commit 1:** [FIX] account_reports: translation of account returns states Steps to reproduce: - Open the tax returns - Set an account opening date to generate some returns - Add another language to…
**Commit 1:** [FIX] account_reports: translation of account returns states Steps to reproduce: - Open the tax returns - Set an account opening date to generate some returns - Add another language to the database and select it -> The states of the returns (the little bubble in the kanban cards) aren't translated even though the translation is present in the pot and po files. **Commit 2:** [FIX] account_reports: translation of date in returns title Steps to reproduce: - Have 2 languages on the db - Generate the tax returns by going to Accounting/Tax Returns and set the opening date - Switch to the second language -> The period displayed in the name of each return isn't translated **Commit 3:** [FIX] account_reports: translate account returns name after lang installation Steps to reproduce: - Generate the tax returns by going to Accounting/Tax Returns and set the opening date - Install another language -> The names of the returns aren't translated in the new language. Solution: When installing a new language, generates the translation of the title for all existing returns task-5421659
This update resolves an issue where smart buttons on the voip call form were missing access groups and causing a singleton error. The fix ensures these buttons work as expected, providing users with the correct application options. It also corrects inaccurate numbers displayed on the buttons.
Original PR description
1. Tickek/Application smart buttons on voip.call form miss access groups. 2. In voip.call form, when clicking the application smart button, a singleton error will raise. 3. Incorrect numbers on smart button. Task-[5461729](https://www.odoo.com/odoo/5778/tasks/5461729)
This update ensures that LNA (a security feature) is consistently enabled for IoT devices across both the POS and Kiosk systems. Previously, LNA was only active in the POS when enabled, creating a potential security gap in the Kiosk. This change enhances security and ensures consistent functionality.
Original PR description
Before this commit, LNA was being used for IoT devices in the POS but not in the Kiosk when `point_of_sale.use_lna` was enabled. After this commit, LNA will also be enabled for IoT devices in the Kiosk. task-5874663 Forward-Port-Of: odoo/enterprise#105460
This update resolves an issue where Mexican CFDI invoices generated with Solution Factible PACs were being rejected due to incorrect exchange rate precision. The fix ensures that exchange rates are rounded to the required 6 decimal places, aligning with the requirements of payment processors like Solucion Factible. This prevents invoice errors and ensures compliance.
Original PR description
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request…
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs. Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200) ## Steps to reproduce: [Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing) 1. Navigate to Apps and install l10n_mx_edi. 2. Switch to any of the Mexican companies that appear. 3. Navigate to Accounting > Configuration > Currencies. 4. Click into the USD currency. 5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field). 6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible. [Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing) 1. Navigate to Accounting > Customers > Invoices. 2. Select New to create a new invoice. 3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES). 4. Add the 45 day Payment terms. This should change the payment policy to PPD. 5. Change the currency to USD. 6. Add the product FURN_8220 (or any with the unspsc_code_id set). 7. Set the unit price of the product to 58968.29. 8. Confirm the invoice. 9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again. 10. Select Register Payment, then Confirm Payment. 11. Select the Update Payments smart button. 12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line. Forward-Port-Of: odoo/enterprise#105102 Forward-Port-Of: odoo/enterprise#102557
This update corrects a bug in how reordering rules utilize warehouse routes. Previously, leaving the 'warehouse_ids' field blank resulted in incorrect route assignments. This fix ensures that reordering rules correctly apply the 'Buy' route when using the default 'All Warehouses' placeholder, streamlining inventory management.
Original PR description
Update warehouse_ids placeholder ("All Warehouses") to a new placeholder that reflect its behavior.
### Steps to reproduce:
* Enable multi-Step Routes
* Inventory > Routes > Buy > Warehouses
* Select the checkbox but leave the field empty (placeholder says "All Warehouses")
### Steps to verify behavior:
* Leaving the warehouse_ids fields empty ("All Warehouses")
* Create a product tracked by quantity and add a vendor
* Create a Reordering Rule
-> It doesn't put the "Buy" route by default as it should
opw-5264571This update resolves a visual issue where the camera button displayed a warning message for channels that didn't require camera access. Now, the warning is only shown for channels configured for video-full-screen mode, streamlining the user experience and avoiding unnecessary alerts for typical voice calls.
Original PR description
Only channels that have cameraPermission of `prompt` should show the red and warning. If the permission is `denied` or `granted`, no badge should be shown. task-5263066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing manufacturing administrators from completing work orders. The fix adds necessary permissions to ensure the workflow functions correctly, allowing users with manufacturing access to successfully produce materials. This improves efficiency and eliminates a roadblock in the production process.
Original PR description
Steps to reproduce:
Create a user with admin access rights for Manufacturing and Quality only. Then, create a work center that has a cost per hour.
Create a product that has a BoM and create a MO then confirm it.
Add a work order that takes place in the created work center and has duration of 60 mins.
Using the created user, try to "Produce All".
Issue:
The user gets an access error when trying to "Produce All", eventhough they have manufacturing access rights.
Fix:
Add sudo access where the process fails to ensure that the workflow is as expected.
Note: a test will be added in anoher PR
opw-5480608This update fixes an issue where the inventory reason provided during barcode inventory counts wasn't being recorded. Now, when completing an inventory count via the Barcode app, the specified reason will be properly logged in the Moves History, ensuring accurate tracking of inventory adjustments. This improves the reliability of inventory reporting.
Original PR description
## Issue
When completing an *Inventory Count* from the Barcode app, the *Inventory Reason* requested to the user is not registered anywhere.
## Steps to reproduce
1. Install the *Barcode* app (`stock_barcode`)
2. In the *Barcode* app, click *Count Inventory*
3. Add a product and set a quantity for it
4. Click *Confirm* (do not scan to confirm)
5. Write an *Inventory Reason* and click *Apply Now*
6. Go to Inventory > Reporting > Moves History
- **The _Inventory Reason_ given in step 5 does not appear anywhere**
If the inventory adjustment is done through Inventory > Operations > Physical Inventory, the user can also provide an *Inventory Reason*, but this time, it will appear in the *Moves History* in the *Reference* (`stock.move.line.reference`) column.
## Cause
Since https://github.com/odoo/enterprise/commit/3efea75a88120519ef4be1a41c8faa7278bc332c, the value provided by the user is never passed to the Python side.
opw-5423934This pull request corrects a technical error where the Greek language code was incorrectly identified as 'gr'. It also adds missing translation modules for Cyprus and Greece, ensuring that Odoo supports these languages correctly. This improves the user experience for customers and partners who speak Greek.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245524 Forward-Port-Of: odoo/odoo#244684
This pull request corrects a critical issue where newly added modules to the Odoo Enterprise stable version were not included in the translation files (.weblate.json). This meant that the Greek language (el) was not supported for translation, preventing users from accessing the software in Greek. The update adds the necessary module definitions to the .weblate.json file, ensuring proper translation support.
Original PR description
Modules added into stable without being properly added to .weblate.json file = never translatable. Forward-Port-Of: odoo/enterprise#105355 Forward-Port-Of: odoo/enterprise#104890
8 changes
Enhancements to existing features
This update simplifies how businesses can customize event registration pages. By separating the registration logic, developers can now easily inherit and modify the underlying system using the 'prepare' method, leading to more flexible and tailored event experiences. This change enhances the extensibility of the website event module.
Original PR description
Since this controller returns raw markup, it is impossible to inherit. By splitting the controller `registration_new`, allows to manage custom developments with the inheritance of the prepare method instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update corrects a nightly failure related to the default timezone used for appointments. The fix changes how the timezone is handled during testing, ensuring consistent behavior. This prevents disruptions to appointment scheduling and improves overall system reliability.
Original PR description
**Issue:** Default tz of `'appointment.appointment_default_resource_calendar'` is not always `"Europe/Brussels"`. **Fix:** Override in test instead of asserting its value. opw-5163892
This update resolves an issue where carousel snippets were being incorrectly cropped in the preview modal. Now, the snippet preview automatically adjusts to the content's height, ensuring a complete and accurate representation of the carousel. This improves the user experience when creating and editing snippets.
Original PR description
Steps to reproduce: - Drag and drop a Carousel. - Add content to the first slide of the carousel to make the snippet taller. - Save the snippet as a custom snippet. - Open the snippet dialog. - Issue: The height of the preview for the saved snippet is forced to 550px, causing the snippet to be truncated. After this commit, the height is no longer forced; it now adapts to the snippet content. task-5156137
This update fixes errors in the SAF-T export process for Romanian companies when partner information (country or name) is missing. The changes ensure accurate registration number generation and prevent report errors, improving compliance for our Romanian clients.
Original PR description
Fix SAF-T export errors when partners have no country or name. For Romanian companies, the RegistrationNumber should be generated as “04 + partner ID” for customers not subject to VAT and with unknown CNP, without including the country code. Steps to reproduce country issue: - Configure a Romanian company with l10n_ro_saft installed - Create a contact without a country - Create and validate an invoice for this contact - Export the SAF-T file from the General Ledger report You you will get a TypeError because you cant concatenate Bool and String. Steps to reproduce name issue: - Create a main contact - Add a child contact without a name - Change the child type to “Company” - Create and validate an invoice - Export the SAF-T file from the General Ledger report This prevents KeyError when printing the first 70 characters of the partner name in the report. opw-5499918 Forward-Port-Of: odoo/enterprise#105020
This update resolves a bug in the website editor that occurred when users manipulated selections in Chrome, leading to invalid offsets. The fix ensures that the selection plugin validates offsets before using data, preventing errors and maintaining editor stability. This improves the user experience and prevents unexpected behavior.
Original PR description
**Description of the problem** In the website editor, the user can manipulate the page in such a way to generate a problematic `SelectionPlugin.activeSelection`, which still points to an existing…
**Description of the problem** In the website editor, the user can manipulate the page in such a way to generate a problematic `SelectionPlugin.activeSelection`, which still points to an existing `anchorElement`, but has an invalid `offset`. **How to reproduce** This seems to be reproducible only on Chrome. 1. Enter in the website edit mode 2. Drop the `s_newsletter` snippet 3. Drop the `s_popup` snippet 4. Click on the popup, and delete it 5. Click on the blank space inside the `s_newsletter` snippet 6. Delete the `s_newsletter` snippet 7. The error occurs Notes: 1. Snippet different than `s_newsletter` can be used to reproduce the problem, as long as they contain a blank space. 2. It is important to make sure that the movement of the mouse pointer does not trigger any preview when going from step 5 to step 6. **Why the problem happens** On Chrome, clicking on a blank area can cause `document.getSelection()` to return a selection with a null `anchorNode.` When this happens, `SelectionPlugin.getSelectionData()` will use the already existing `activeSelection` if `activeSelection.anchorNode` is still connected. Before this commit, this method only checked that `anchorNode` was connected, without validating offsets. This leads to the following edge case: 1. The user removes the `s_popup` 2. At this point, `document.getSelection()` would point to the `s_newsletter` snippet, so if the user just deletes the snippet nothing bad would happen. But instead, if: 3. The user clicks on a blank area in `s_newsletter`, `document.getSelection()` will now return a null `anchorNode` 4. The user delete the `s_newsletter` snippet, and `SelectionPlugin.getSelectionData()` is called by an handler after the deletion 5. At this point: `document.getSelection()` has a null `anchorNode`, so the method will check if `activeSelection.anchorNode` is still connected, WITHOUT validating the offsets. 6. Since `anchorNode` is still connected, this selection will be used, and an error will be triggered shortly after, because the offset is too high (pointing to `s_popup` which does not exist anymore). **Fix** After this commit, when `SelectionPlugin.getSelectionData()` checks that `activeSelection.anchorNode` is still connected it also checks that the offsets are valid (meaning that they are smaller than the number of nodes). task-5430500
This update resolves a bug that caused the follow-up report to crash when users unfolded partner lines while prefix groups were enabled. The fix corrects an error in how the report processed data, ensuring stability and preventing unexpected errors for users.
Original PR description
When prefix groups were enabled, and a prefix group line had been unfolded, the report crashed when trying to unfold the partner. This happened because res_ids_map is computed for each of the unfolded lines, including the prefix groups one, which then had no 'res.partner' key, causing a key error.
This update resolves a technical issue that prevented users from adding attachments when sending emails to large groups of contacts (501+). The fix addresses a limitation in how the system handles data volume, ensuring the email composer function works reliably with larger contact lists. This improves the user experience for sending bulk emails.
Original PR description
Steps to reproduce: 1. Install 'contact' 2. Create 501+ contacts (e.g. by duplicating existing one) 3. Select all contacts in list view and click Send Email (from Action menu) 4. Try to add an attachment Issue: - A traceback is raised in the mail composer: `SyntaxError: Unexpected end of JSON input` Cause: `res_ids` is not set on the composer when more than 500 records are selected. This is expected, as the compute method `_compute_res_ids()` does not write `res_ids` when the number of active_ids exceeds 500 (to avoid storing large payloads on the field). Because of this, the code trying to JSON.parse(res_ids) fails. see: https://github.com/odoo/odoo/blob/abc8417413faf598fb83106de4328571d71888aa/addons/mail/wizard/mail_compose_message.py#L400 Solution: - Fallback to context.active_ids when res_ids is not available opw-5351374
This update resolves an issue where users without superuser privileges could encounter access errors when generating global invoices in the Mexican CFDI module. The fix ensures proper access control and cache management for the ir.sequence used in global invoice creation, preventing errors and intermittent failures.
Original PR description
**PROBLEM** 1. When generating a global invoice with a user without super user access, a access error may occur on the ir.sequence model. 2. There is an issue with the cache of the field…
**PROBLEM** 1. When generating a global invoice with a user without super user access, a access error may occur on the ir.sequence model. 2. There is an issue with the cache of the field `l10n_mx_edi_global_invoice_sequence_id`. (this is why problem can sometimes resolves itself on restarting the odoo instance). **STEP TO REPRODUCE** 1. Create 1 invoice with CFDI to public checked. 2. Goes to the list view for invoices, select the invoice, and apply the action "create global invoice" to it. 4. A access error may appear (depending on cache value). **CAUSE** 1. In `_get_global_invoice_cfdi_sequence()`, we get or create the ir.sequence used for global invoices. We are creating it with sudo(), so a user without sudo privilege can write to it. But, when we are retrieving a ir.sequence record that already exist, when don't use sudo(), this causes an access error for user without sudo privilege. 2. In `_get_global_invoice_cfdi_sequence()`, we try to get the computed field `l10n_mx_edi_global_invoice_sequence_id`. If it doesn't exist, we create a ir.sequence, but we forget to assign it to the field. Because we already trigger the compute method of the field by trying to access it, there is a None value in cache for it. This means we will always create a ir.sequence, despite one already existing for the company until the cache expires or the compute method is re-triggered. opw-5472552
1 change
Resolved issues and error corrections
This update optimizes the timesheet report to address slow loading times when processing large datasets. The team implemented a more efficient query using a CROSS LATERAL JOIN to filter relevant dates, significantly reducing processing time. The report now loads in approximately 2 seconds, resolving a previous issue impacting report usability.
Original PR description
After this commit https://github.com/odoo-dev/enterprise/commit/6c33bde74342b634d9f6fbda4ef407ffe9bac54f we introduced a new left join which seems that it slowed down the query a lot. So the report doesn't load at all if we have a lot of records. In this PR we are introducing CROSS LATERAL JOIN as we want to generate only the the relevant dates not all dates between the min starting date and max ending date of all slots. Query plan after modification https://explain.dalibo.com/plan/eh5293ba2354f43c The testing cardinality of the tables: `planning.slot` 7178 rows `hr.employee` 332 rows `resource.resource` 332 rows `resource_calendar_leaves` 4061 rows `account_analytic_line` 267376 rows `generate_series()` will produce 206417 rows | Before | After | |-----------------------------------------|-------| | Query keep being active with no results | ~2s | opw-5089052