Daily updates from Odoo
Tuesday, January 20, 2026
374 changes
32 changes
Enhancements to existing features
This update streamlines the accounting process for Ecuadorian businesses within Odoo by consolidating expense accounts and adding a new account for direct employee benefits. It also simplifies reconciliation processes for income-related expense accounts, ensuring accurate financial reporting.
Original PR description
Improve the distribution of expense and cost of revenue accounts in Ecuadorian localization We avoided not creating subcategories of expenses by eliminating the group called "Other employee benefit plan expense", which generated duplicity in the accounts. We fixed this by merging the accounts into the main "Employee benefit plan expense" group. Additionally, the account "Other employee benefits' was added to record any other benefits granted directly by the Ecuadorian companies. This ensures a better organization of the accounting setup. Mark as non-reconcilable the expense accounts (salaries and wages, travel expenses, contributions, etc) to avoid unnecessary reconciliation processes, these accounts are income statements and they are not accounts payable/receivable, therefore, they are closed at the end of the accounting period ### opw-4846355 Forward-Port-Of: odoo/odoo#208047
This update enhances the kiosk payment process by centralizing IoT communication through a new service, `iot_http`. This improves reliability and security by handling various IoT protocols for payment requests, ensuring smoother transactions for customers.
Original PR description
We now use the `iot_http` service to handle all IoT available protocols to send payment requests. Forward-Port-Of: odoo/enterprise#104811
Resolved issues and error corrections
This update fixes a technical issue preventing a key test from running successfully on the Odoo system. The change adds group permission controls to the payroll module, ensuring proper access and functionality for users. This resolves a potential restriction impacting payroll processing.
Original PR description
The test_employee_fields_groups unit test from hr/tests/test_self_user_access.py was not successful on the runbot due to access restriction. I added the groups parameters to the l10n_sa_gosi_api_is_available field definition in the hr_employee extension from the l10n_sa_hr_payroll_gosi module. Runbot error: 233954
This update fixes default printer settings for Point of Sale, ensuring users are presented with the most appropriate printer type (receipt or preparation) when creating new printers. It also adds a required field for product categories when creating preparation printers, reducing potential errors and improving data accuracy.
Original PR description
The goal of this pr was to set the printer type by default as `receipt` when a quick create was done from the "Receipt Printers" category and as `preparation` when it's done in the "Preparation Printers" category, both in `pos.config` and in `res.config`. Also, in the `pos.printer` form view, for a preparation printer, products categories are now required when creating a printer to avoid user oversights. And, a quick fix to make the default receipt printer as required, under the "Receipt Printers" category in the `res.config` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where free product reward lines incorrectly displayed a non-zero price in the shopping cart. The issue stemmed from an override in the `sale_subscription` module that was causing unnecessary discount calculations. The fix filters reward lines to prevent this recalculation, ensuring accurate pricing for free products.
Original PR description
### Issue: Due to this issue, the free product reward line might have a non-zero price. #### To reproduce: 1- Install `website_sale_loyalty` and `sale_subscription`. 2- Enable `Discounts` on…
### Issue: Due to this issue, the free product reward line might have a non-zero price. #### To reproduce: 1- Install `website_sale_loyalty` and `sale_subscription`. 2- Enable `Discounts` on configuration. 3- Create a `promotion`: - rule: minimum quantity: 0, minimum purchase: 10 - reward: free product, quantity: 1 4- Set a non-zero price on reward product from product page. 5- Create a product with price of 6 and publish it on the website. 6- On website, add 1 unit of created product to cart. 7- Open cart, and increase the quantity. 8- As you see the free product is added to cart but the price is non-zero. ### Cause: Based on #89397, the reward line have the discount of 100. In the `_compute_discount` this discount is set to 0: https://github.com/odoo/odoo/blob/e48a7f1b03f23a4c96e35ee4350029439ec73e47/addons/sale/models/sale_order_line.py#L797 As `compute_discount` only depends on `product_id`, `product_uom_id`, `product_uom_qty` this shouldn't cause issue. However, in `sale_subscription` its override includes `sale_order.plan_id` as dependency: https://github.com/odoo/enterprise/blob/d0375627c6f8de6098dfe93a80f522f31e3a4174/sale_subscription/models/sale_order_line.py#L86-L90 Which setting `plan_id` to `False` here makes discount to be recomputed: https://github.com/odoo/enterprise/blob/d0375627c6f8de6098dfe93a80f522f31e3a4174/website_sale_subscription/models/sale_order.py#L27-L30 ### Fix: This can be avoided by filtering reward lines in a `_compute_discount` override. As none of reward lines regardless of reward type are expected to have a discount calculated this fix will not break any other flows. It's noteworthy to mention that in the test, `_compute_discount` is directly called in order to mimic the flow without the need to install `sale_subscription`, as the `sale_subscription` is not root cause of the issue and the same issue could reproduced by any other modules overriding `_compute_discount`. opw-5485796 Forward-Port-Of: odoo/odoo#243827
This update corrects a technical issue where the payment callback URL was incorrectly triggered, causing verification problems. The fix ensures the callback URL only activates when a redirect is expected, aligning with Razorpay's documentation and improving payment reliability for UPI transactions.
Original PR description
Steps: - Install Razorpay and sales app. - Create a SO and try to pay with UPI pm in IOS mobile. Issue: - After payment compilation it is trying to redirect to `callback_url` which should only…
Steps: - Install Razorpay and sales app. - Create a SO and try to pay with UPI pm in IOS mobile. Issue: - After payment compilation it is trying to redirect to `callback_url` which should only trigger when `redirect` is `True`. Cause: - In Razorpay documentation it's not clearly mention it will only trigger `callback_url` when `redirect` is `True`, so in some cases it redirect to `callback_url` even `redirect` is `False` which is cause issue during signature verification as it try to verify signature according to `is_redirect` with `razorpay_secret` but in oAuth `razorpay_secret` is not set. Razorpay doc link: https://razorpay.com/docs/payments/payment-gateway/web-integration/standard/integration-steps/#123-checkout-options <img width="670" height="537" alt="image" src="https://github.com/user-attachments/assets/81c855c0-aaca-4953-bcff-942bc11a32d2" /> Fix: - Only set `callback_url` for `REDIRECT_PAYMENT_METHOD_CODES` PMs where we expect it to redirect to `return_url` and not in the oAuth flow, Instead relying on the `redirect` option of the Razorpay. opw-5389499 Forward-Port-Of: odoo/odoo#243596 Forward-Port-Of: odoo/odoo#243054
This update resolves an issue where grouping accounting records by their root account was failing, resulting in an error. The change allows for full domain optimization during record retrieval, ensuring accurate grouping and displaying the expected nested records. This improves the functionality of the chart of accounts feature.
Original PR description
Access records in a grouped by `account_root` list failed, showing an error message:
Unsupported operator on Root 'Account' (account.account) in [('root_id', 'any', [('display_name', 'in', [10])])]
Step to reproduce:
- New DB with `accountant` module
- Accounting -> Chart of accounts
- Group By "Root"
- Open any grouped record set
When opening the record set, Odoo fetches data using the domain `[('id', '=', '10')]`
The domain goes through optimization as follows:
```
[('id', '=', '10')]
basic : [('id', 'in', ['10'])]
full : [('root_id', 'any', [('display_name', 'in', [10])])]
```
However, the `_search_account_root` method protects the technical field `account_root`.
This commit adapts it to allow full optimized domain search and solving the error.
Ticket [link](https://www.odoo.com/odoo/project.task/5178896)
opw-5178896
Forward-Port-Of: odoo/odoo#238841This update resolves an issue where the Amazon connector wasn't correctly identifying key delivery modules for UPS, FedEx, USPS, and DHL. By mapping these modules, the connector now functions seamlessly with these major shipping carriers, ensuring accurate order processing and fulfillment.
Original PR description
Amazon connector did not recognize the _rest delivery modules (ups_rest, fedex_rest, usps_rest, dhl_rest). This maps them to the correct carrier names, consistent with existing mappings. Forward-Port-Of: odoo/enterprise#102606
This update optimizes how the attendance tracking module requests location data. By default, location tracking is disabled when in an office or event setting, reducing unnecessary requests to external services. This improves performance and efficiency.
Original PR description
Use the _get_localisation helper that uses geoip when available Disable geolocalisation of device by default (i.e. in the context of an office/event, all requests are in the same spot) In addition to #243073 Forward-Port-Of: odoo/odoo#243117
This update resolves an issue preventing correct Spanish translations in reports. The fix ensures the translation process has access to necessary data (like user and context) during the translation lookup, resulting in accurate and complete Spanish reports. This improves the user experience for Spanish-speaking customers.
Original PR description
Problem --------- Currently, the lazy translation is executed inside the Markup frame. This has the consequence of having the frame pretty much empty (no context, no user, no cr) when looking for the language. Thus, the lazy translate cannot retreive any language. Solution --------- Use `str` in the compute method so that the frame used to compute the translation is actually the compute method (which has data needed to retreive the language) and not the markup. Before: -> compute ..|-> Markup (the frame used) ....|-> _lt => fail After: -> compute (the frame used) ..|-> _lt ....|-> Markup error-237535 error-237536 Forward-Port-Of: odoo/enterprise#104776
This update resolves an issue where embedded buttons in the control panel were getting cropped due to incorrect height calculations during dragging. The fix ensures that the buttons display their actual size, preventing visual distortion and improving the user experience. This change improves the appearance and usability of the control panel.
Original PR description
The `o_embedded_actions` buttons are getting cropped when they are long enough. This is due to the `overflow-hidden` property which is now applied when no element are actively dragged. When an element is dragged after a css transformation, eg. the `o_dragged_embedded_action`, `getBoundingClientRect()` is returning the element height with the transformation. This creates an excess height on the `o_embedded_actions` due to the placeholder button having it's transformed height instead of the button height. Using offsetHeight returns the element size without the transform. Note this is not done on the width, because the width without the transform can lead to text-truncation. task-5225696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234120
This update resolves an issue where Odoo invoices with discounts generated for the Danish Nemhandel system were failing validation. The fix ensures discounts are correctly accounted for in the invoice data, allowing these invoices to be successfully transmitted to customers. This improves the accuracy of financial data and avoids potential disruptions in payment processing.
Original PR description
Before this fix, all the OIOUBL invoices with a discount generated by Odoo would fail the schematron validation, meaning they can't be sent to the customer through Nemhandel. The schematron enforces that the discount is taken into account at the PriceAmount, to keep the rules on lineExtensionAmount working. Also changes the import to understand that it's a discount. opw-5379474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241789 Forward-Port-Of: odoo/odoo#241614
This update resolves a compatibility issue with an older version of Odoo's spreadsheet functionality. Specifically, it ensures that the ODOO.FILTER.VALUE feature continues to work correctly across different Odoo releases. This prevents disruptions for users relying on this spreadsheet tool.
Original PR description
Task-5477426 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#244218
This update fixes an issue where the Odoo Studio export process incorrectly excluded certain fields. The fix separates the handling of computed and related fields, ensuring more accurate exclusion based on their type and writeability. This improves the reliability of exported models, confirmed by the Industry team.
Original PR description
This commit fixes the computation of excluded fields for the studio export models. Before this commit, the excluded fields computation was considering computed and related fields in a similar way but…
This commit fixes the computation of excluded fields for the studio export models. Before this commit, the excluded fields computation was considering computed and related fields in a similar way but there are subtle differences that cause the excluded fields to sometimes be wrong. While analyzing the heuristic with the ORM team, we decided to separate the computation of related and computed fields. After this commit, we have a refined computation of excluded fields for related and computed fields: - for computed fields (that are not related ones), we always exclude them except when they are writeable (i.e. stored or with inverse) - for related fields, we always exclude them when the relation is in the list of related models to exclude. We also exclude them when they are not writeable on the current record only (not the source record), except if they are required. Some export scenarios have been tested manually and brought with them adaptations in the hardcoded lists of default fields to exclude. The Industry team agreed with these changes. Task id: opw-4974787 Forward-Port-Of: odoo/enterprise#87530
This update resolves an issue where URLs were appearing twice in WhatsApp messages due to a formatting error in how the Odoo UI's HTML was converted to plain text. The fix prevents this duplication, ensuring users receive messages with URLs correctly formatted and avoiding potential confusion. This improves the clarity and usability of WhatsApp communication within Odoo.
Original PR description
Steps to reproduce: 1. Set up whatsapp integration. 2. Send a direct message containing a URL. 3. Observe that the URL appears twice in the message received in whatsapp. Issue: This issue arises…
Steps to reproduce: 1. Set up whatsapp integration. 2. Send a direct message containing a URL. 3. Observe that the URL appears twice in the message received in whatsapp. Issue: This issue arises within the `_send_message` method, where we are taking the Markup body that we use within the Odoo UI to have a clickable URL, like `<a href="https://example.com">https://example.com</a>`. Then, the html2plaintext function duplicates by adding the footnote for the anchor tag, which "duplicates" the URL since the text within the anchor tag is the same as the URL itself. This results in a message body that contains the URL twice, leading to confusion for the user. Solution: This commit addresses the issue by backporting the solution to this problem introduced in odoo/odoo@a152910 and using the `include_references` parameter of the `html2plaintext` function to exclude footnotes from the conversion. opw-4936400 Forward-Port-Of: odoo/enterprise#104252 Forward-Port-Of: odoo/enterprise#101083
This update fixes an issue where the preferred delivery carrier wasn't automatically applied when adding shipping to a sale order. The change ensures that the carrier specified for a customer partner is now correctly used, streamlining the shipping process and improving order accuracy. This resolves a previous bug impacting order fulfillment.
Original PR description
Steps to reproduce: - Create a storable product “P1” - Go to partner *Azure Interior*: - Set 'property_delivery_carrier_id' to any carrier - Create a sale order: - Customer: Azure Interior - Add 1 unit of P1 - Click on "Add shipping" Problem: Since this commit: https://github.com/odoo/odoo/pull/203955/files#diff-9f1fd37c63903c4c029f099d485a3f9831446850be55695a4603c05ef298885bL134-L137 the carrier defined on the partner is no longer loaded by default. Solution: Check if the carrier defined on the partner is among the allowed carriers, and if so, set it automatically. opw-5220118 Forward-Port-Of: odoo/odoo#235336
This update resolves an intermittent issue where live chat sessions would unexpectedly crash. The fix addresses a timing conflict between chat closing and agent member deletion, ensuring a reliable session end. This improves the overall stability and user experience of the live chat feature.
Original PR description
This commit fixes the `visitor leaving ends the livechat conversation` test that was sometimes failing. There is a race between the simulation of the guest leaving the chat that uses `withGuest` which is known to be problematic and the `action_unfollow` method, called when the chat window is closed. The unfollow method deletes the agent member, but since the guest cookie is still present, the `channels_as_member` rpc retrieves the guest member. The rest of the code doesn't expect this mismatch and a crash occurs. This commit ensures the `channels_as_member` rpc is properly done before closing the chat window. runbot-237947 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a formatting error in the Korean localization files (ko.po) that was causing issues with the display of documents. The fix ensures proper line wrapping, resulting in accurate and consistent translations for users. This improves the overall quality and usability of the Enterprise version.
Original PR description
EOL error due to incorrect line wrap
This update corrects a bug where the website generation process wasn't correctly setting a key value. The fix ensures that the website generation feature always defaults to 'True', guaranteeing that new websites are created when the /startwebsite flow is initiated. This resolves a potential issue preventing website creation.
Original PR description
Missing the 'import_website' value, and since /startwebsite always creates a website it should always be True.
This update increases the timeout for the main Odoo test suite to handle the growing number of tests. Previously, the suite would frequently fail due to lengthy run times, but this change provides a longer window to ensure all tests complete successfully. This improves the stability of nightly builds.
Original PR description
This commit increases the timeout of the main (desktop) hoot test suite. Since [1], the suite is split by sub-builds, such that each sub-build only runs the tests defined in the addons that are tested by that sub-build. So the suite never timeouts anymore on regular builds. However, in nightly, we still run the whole suite "old school", i.e. all tests in the same run. In that case, the suite sometimes (in 19.1) or often (in master) exceeds the previous timeout (50m). With 1 hour, we hope that it will be enough. Note that the number of tests keeps increasing, hence the need to increase the timeout. [1] https://github.com/odoo/odoo/pull/234132 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where inserting pivots from spreadsheets could cause errors or prevent resizing. Now, the spreadsheet pivot insertion process is streamlined, automatically adding necessary columns and matching the resizing behavior of web pivots, ensuring a smoother user experience.
Original PR description
Current behavior before PR: - Inserting a pivot from a spreadsheet could trigger spill errors when the pivot had more columns than the default columns. - Columns could not be resized when inserting a pivot from a spreadsheet, unlike insertion from a web pivot view. Desired behavior after PR is merged: - Both pivot insertion flows are combined into a single implementation to remove duplicated code. - Required columns are added automatically to prevent spill errors. - Columns are resized when inserting a pivot from a spreadsheet, matching the behavior of web pivot insertion. Task: [5404283](https://www.odoo.com/odoo/2328/tasks/5404283)
This update ensures that the minimum wage is accurately calculated and pro-rated based on employee work time. The change addresses a previous issue where the minimum wage wasn't correctly adjusted, ensuring compliance with Belgian labor laws. This update improves payroll accuracy and reduces the risk of non-compliance.
Original PR description
Since changes made in 302bf2b4e201da8f56b1da012dd7f03c81a85e22 the minimum wage should be pro-rated to the work time rate. Forward-Port-Of: odoo/enterprise#104419
This update fixes an issue where Live Chat reports consistently displayed days starting with Sunday, regardless of the user's preferred week start day setting. Now, the reports accurately reflect the user's language-defined 'First Day of Week', providing more accurate and relevant reporting data. This ensures consistency and a better user experience.
Original PR description
**Current behavior before PR**: The "Day of Week" group by in the Live Chat report always treats Sunday as the start of the week, ignoring the "First Day of Week" configured in the user's language settings. **Desired behavior after PR is merged**: "Day of Week" group by now correctly takes into account the user's configured "First Day of Week", as set in their language settings. **task**-[4808640](https://www.odoo.com/odoo/project.task/4808640) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234708 Forward-Port-Of: odoo/odoo#213307
This update resolves a problem where the payer company was incorrectly identified in the 1099 report when using multiple companies. The fix ensures that each 1099 report accurately reflects the correct payer company for each invoice, improving report accuracy and compliance. This impacts users with multi-company configurations.
Original PR description
When generating 1099 report with multicompany setup, the payer company is wrongly assigned in the csv file. Steps: - Have 2 companies - Make one bill per company with one different 1099 vendor for each one - With both companies selected, generate the 1099 report - open the csv file -> Payer name is the same for both line opw-5442190 Forward-Port-Of: odoo/enterprise#104660 Forward-Port-Of: odoo/enterprise#103805
This update fixes a usability issue by moving the GCC Format checkbox to the 'Customer Invoices' section within the settings. This ensures that users can always access this important setting, even when the broader Fiscal Localization section is hidden, streamlining the invoicing process.
Original PR description
This fix moves the GCC Format checkbox under the 'Customer Invoices' block so it remains accessible in branches where the Fiscal Localization section is hidden. task-5723793 Forward-Port-Of: odoo/odoo#244652
This update ensures that live chat and member lists automatically open by default, regardless of which panel is currently active. Previously, opening one panel would disable the other. This change provides a better user experience by maintaining the preferred default view for both live chat and non-live chat conversations.
Original PR description
*: crm_livechat, im_livechat Before this commit, auto-open of member panel and livechat info panel did not combine from [1]. This means that when livechat info was auto-open in livechat, this…
*: crm_livechat, im_livechat Before this commit, auto-open of member panel and livechat info panel did not combine from [1]. This means that when livechat info was auto-open in livechat, this necessarily meant the auto-open of member list was disabled, and vice-versa. This is a problem because when navigating between livechat and non-livechat would necessarily imply the dismiss of either panel, which is not good because the best default is having livechat panel open by default, and for non-livechat conversations it should auto-open the member list panel. This commit fixes the issue as follow: - auto-close of panel are aware of whether action are active, as removal of auto-open from auto-close makes sense only when another panel is made active when the older panel was visible - closing of member panel by opening the livechat info panel should preserve auto-open of member list for other conversations Task-5496830 runbot-237994 [1]: https://github.com/odoo/odoo/pull/238472 https://github.com/odoo/enterprise/pull/104435 Forward-Port-Of: odoo/odoo#243864
This update combines member and live chat information automatically when creating tickets through the website helpdesk and WhatsApp channels. Previously, this data was handled separately, leading to a less streamlined experience for users. This change ensures a more complete and accurate view of customer interactions within tickets, improving support efficiency.
Original PR description
*: website_helpdesk_livechat, whatsapp Task-5496830 https://github.com/odoo/odoo/pull/243864 Forward-Port-Of: odoo/enterprise#104435
This update fixes a bug that prevented users from correctly unbuilding manufactured products when the same serial number was used multiple times within a manufacturing order. The fix ensures that the system accurately tracks component usage, preventing validation errors and ensuring accurate inventory management. This improves the reliability of the manufacturing process.
Original PR description
Steps to reproduce the bug: - Create a storable product P1 - Tracking: Serial Number - BoM: Component: 1 unit of C1, tracked by Serial Number - Update the inventory of C1 - 1 unit with SN1 - 1 unit…
Steps to reproduce the bug:
- Create a storable product P1
- Tracking: Serial Number
- BoM: Component: 1 unit of C1, tracked by Serial Number
- Update the inventory of C1
- 1 unit with SN1
- 1 unit with SN2
- Create a Manufacturing Order to produce 2 units of P1
- Confirm and validate the MO using serials SN1-P1 and SN2-P1
- SN1 and SN2 of C1 are consumed
- Unbuild 1 unit of P1 with serial SN1-P1 Result: SN1 of C1 is correctly restored
- Unbuild 1 unit of P1 with serial SN2-P1
- Try to validate the unbuild
Problem:
A user error is raised:
"The serial number SN1 has already been assigned"
This happens because _action_unbuild attempts to reuse the same component serial number (SN1 of C1) without checking whether it has already been consumed by a previous unbuild operation on the same Manufacturing Order.
Solution:
This fix ensures that, when unbuilding tracked products, component serial numbers already used by previous unbuilds of the same MO are excluded from the candidate move lines.
This prevents reassigning the same serial number multiple times and avoids the validation error.
opw-5441256
Forward-Port-Of: odoo/odoo#242882This update resolves an issue preventing the generation of QR codes for invoices when using automated workflows. The fix ensures the system correctly accesses necessary configuration data, allowing QR codes to be created without requiring a direct HTTP request. This improves invoice automation and payment processing.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. In Accounting/Invoicing settings, enable "Add QR-code link on PDF"; 2. create an automation rule for the `account.move` model; 3. set "Trigger" to…
Versions
--------
- saas-18.3+
Steps
-----
1. In Accounting/Invoicing settings, enable "Add QR-code link on PDF";
2. create an automation rule for the `account.move` model;
3. set "Trigger" to "Create & Edit";
4. set "Apply on" domain to `[("state", "=", "posted")]`;
5. set "When updating" to "Status";
6. add an action to execute the following code:
```python
env['account.move.send']._generate_and_send_invoices(records)
```
7. call `action_post` on an invoice via RPC or Odoo Shell.
Issue
-----
> odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
> RuntimeError: object is not bound
Cause
-----
In order to add a payment link QR code to the invoice[^1], it needs to generate an access token for the portal. This happens via the `generate_access_token` function from `odoo.addons.payment.utils`. Issue is that it relies on having access to a `odoo.http.request` object, so that it can use its `env` to retrieve the `database.secret` config parameter.
When this flow gets triggered via an API call (or Odoo Shell), the `request` object is unbound, causing the error.
[^1]: feature added via commit bcb73cd159885
Solution
--------
Introduce an optional `env` kwarg to `generate_access_token`, falling back on `request.env` if it's not provided.
opw-5487075
Forward-Port-Of: odoo/odoo#244610
Forward-Port-Of: odoo/odoo#243528A glitch prevented users from removing all avatars from a website feature, leading to errors when trying to add new ones. This fix ensures the system correctly handles rapid avatar removal, preventing a disruption to the user experience.
Original PR description
**Problem** Users could remove all avatars from the `s_avatars` snippet by clicking the "Remove avatar" button rapidly. This also causes an error when attempting to add a new avatar afterward.…
**Problem** Users could remove all avatars from the `s_avatars` snippet by clicking the "Remove avatar" button rapidly. This also causes an error when attempting to add a new avatar afterward. **Reproduction** 1. Drop the `s_avatars` snippet. 2. Click very quickly on the "Remove avatar" button multiple times. **Cause** The code relied on preventing the removal of the last element by disabling the "Remove avatar" button based on DOM state. Because rendering is asynchronous, rapid clicks could be registered before the button was disabled, allowing the last avatar to be removed. **Fix** Add a check in `AvatarsHeaderMiddleButtons.removeAvatar` to prevent removal when only one avatar remains, covering cases where clicks occur before the UI updates. The components `CarouselItemHeaderMiddleButtons` and `NavTabsHeaderMiddleButtons` use the same logic of `AvatarsHeaderMiddleButtons` and could fail similarly, thus they have been fixed too, even if the bug is not currently reproducible on them. task-5462816
This update fixes a technical error that occurred when sale orders lacked an invoice date. The fix ensures that stock movements related to subscriptions are correctly filtered, preventing errors and improving the reliability of subscription order processing. This resolves a potential disruption to order fulfillment.
Original PR description
The Issue: Prior to this commit, When the sale order last_invoice_date is False, a traceback is thrown The Fix: To resolve this, We get the last_invoice_date or todays date opw-4403557 Forward-Port-Of: odoo/enterprise#75717
Users were experiencing blocks in the Point of Sale UI due to preparation printers ignoring print requests. This change reverts a recent update to restore normal print functionality and remove the blocking issue. It ensures users can consistently use the Point of Sale feature.
Original PR description
Since preparation printers are ignoring the print job requests sent a lot of users are being blocked in pos UI. This reverts commit fcd0aab5f1349310e161b175f118eb8d3db818e4. This unblocks the user's UI in case of a duplicate print Forward-Port-Of: odoo/odoo#243981
7 changes
Resolved issues and error corrections
This update fixes a potential issue where the website editor could fail to open correctly under certain network conditions. By delaying editor initialization until the iframe is fully loaded, the system now provides a more consistent and reliable editing experience. This ensures users can consistently create and manage website content.
Original PR description
Steps to reproduce: 1. Set network speed to 3G 2. Create website Page from the systry new menu 3. click on edit button You'll face the traceback. The website editor could try to open before the iframe finished loading, leading to non-deterministic behavior. This commit ensures the editor initializes only after the iframe load event, making the edit action consistent and reliable. Erlier fixed was not covering the all the cases. PR: https://github.com/odoo/odoo/pull/238054 runbot-233039
This update resolves a problem where the payer company was incorrectly identified in the 1099 report when using multiple companies within Odoo. The fix ensures that each 1099 report accurately reflects the correct payer company for each invoice, improving report accuracy and compliance. This impacts users generating 1099 reports for businesses with multiple entities.
Original PR description
When generating 1099 report with multicompany setup, the payer company is wrongly assigned in the csv file. Steps: - Have 2 companies - Make one bill per company with one different 1099 vendor for each one - With both companies selected, generate the 1099 report - open the csv file -> Payer name is the same for both line opw-5442190 Forward-Port-Of: odoo/enterprise#104660 Forward-Port-Of: odoo/enterprise#103805
This update fixes a potential issue in the Nilvera accounting module where the default journal type was incorrectly set. The default has been changed from 'in_invoice' to 'purchase' to prevent incorrect document processing. This ensures documents are created with the appropriate accounting settings.
Original PR description
…hing The default value of the journal type parameter was incorrectly set to a move type (`in_invoice`). Although all current callers explicitly pass the correct journal type, the default value has been corrected to `purchase` to avoid potential misuse. no task-id Forward-Port-Of: odoo/odoo#242865
This update removes unnecessary integer rounding from monthly VAT reports for Italian businesses (l10n_it). Previously, rounding was incorrectly applied to these reports due to a change made in a related project. This ensures accurate and consistent VAT reporting, aligning with Italian tax regulations.
Original PR description
**Description of the issue/feature this PR addresses**: Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in #193662. **Current behavior before PR**: Integer rounding on monthly l10n_it tax reports. **Desired behavior after PR is merged**: No more integer rounding on monthly l10n_it tax reports. [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243671 Forward-Port-Of: odoo/odoo#243100
This update removes unnecessary integer rounding from monthly VAT reports for Italy. The rounding was mistakenly carried over from annual reports, impacting the accuracy of monthly financial data. This change ensures consistent and correct reporting of VAT obligations.
Original PR description
Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in [#193662](https://github.com/odoo/odoo/pull/193662). [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) Forward-Port-Of: odoo/enterprise#104228 Forward-Port-Of: odoo/enterprise#103852
This update prevents a problem where users in different branches could create the same tax name. Previously, Odoo only checked for duplicates within a user's visible branches. Now, Odoo checks all branches to guarantee each tax name is unique, avoiding errors and ensuring data consistency across the entire organization.
Original PR description
**Description of the issue/feature this PR addresses:** In companies with many branches, a user could create a tax name that already exists in another branch. This happened because Odoo only checked for duplicates in the branches the user could see. To reproduce: 1. Create `Branch A` and `Branch B`. 2. A user with access ONLY to `Branch A` creates "Tax 1". 3. A user with access ONLY to `Branch B` creates "Tax 1". 4. Both are saved, creating a duplicate name. This fix adds sudo() to the check. Now, Odoo will check all branches to make sure the name is unique, even if the user cannot see the other branches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243185
This update resolves an issue that prevented users from creating payslips for contracts without a defined working schedule in Belgian companies. The fix ensures that the system defaults to the company's standard calendar when a contract lacks a specific schedule, preventing a traceback error. This improves the reliability of payslip generation.
Original PR description
Currently, a traceback occurs when a user tries to create a payslip for a contract that has no working schedule in a Belgian company. **Steps to reproduce this issue:** 1) Install l10n_be_hr_payroll…
Currently, a traceback occurs when a user tries to create a payslip for a contract that has no working schedule in a Belgian company. **Steps to reproduce this issue:** 1) Install l10n_be_hr_payroll and hr_attendance and switch to BE company 2) Create an employee with no working hours. 3) Create a contract for that employee with: - Work entry source as Attendance - No Working Schedule - State should be open/running 4) Click the Payslip smart button to create a new payslip for that contract. 5) A traceback occurs **Error:** ``` ValueError: Expected singleton: resource.calendar() ``` **Cause:** When creating a payslip for a contract with no resource_calendar_id, the method `_get_work_hours_split_half` calls `_get_max_number_of_hours` through self.resource_calendar_id. Since the contract's calendar lacks a resource_calendar_id, this triggers a ValueError in `_get_max_number_of_hours`. https://github.com/odoo/enterprise/blob/193b51ded0dfa46ed75f6c0020f0f5609f4a0f99/l10n_be_hr_payroll/models/hr_contract.py#L472 **Solution:** If the contract or employee does not have a resource_calendar_id, use the default resource_calendar_id from the company instead. opw-5237559 Forward-Port-Of: odoo/enterprise#103059 Forward-Port-Of: odoo/enterprise#99217
12 changes
Resolved issues and error corrections
This update fixes a test that was intermittently failing due to inconsistencies in how inbox messages are marked as read. The change ensures the test waits for the initial message fetch, preventing a common failure scenario and improving the reliability of inbox read marking. This enhances the overall stability of the Odoo messaging system.
Original PR description
The `Opening thread with needaction messages should mark all messages of thread as read` ensures that opening a channel marks the related inbox messages as read. However, this test can fail in a non-deterministic fashion. There are two flows that can mark inbox messages as read: fetching the messages or a manual request after opening the channel. The test expects the rpc to be issued, but if the messages are fetched before, it won't happen thus making the test fail. This commit awaits the initial fetch to prevent this issue. As a bonus, the second flow is also tested. runbot-237970 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that optional product images are only shown when the system is configured to display them. Previously, images were always shown, even when disabled, leading to a cluttered user experience. Now, a placeholder is used when no image is available, aligning the display with the 'Show product images' setting.
Original PR description
Before this commit: =================== - When the `Show product images` setting was disabled, the optional products UI still displayed product images. - If an optional product did not have an image, the UI displayed the image's alt text - Also when the product don't have image, the combo popup and product card just display the product name. After this commit: ================== - Optional product images are displayed only when the `Show product images` configuration is enabled. - If the optional product doesn't have an image, we will display an image placeholder instead of alt text. - If there is no product image, the combo popup and product card will display the image placeholder. Task: 5480181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem where the payer company was incorrectly identified in the 1099 report when using multiple companies. The fix ensures that each 1099 report accurately reflects the correct payer company for each invoice, improving report accuracy and compliance. This impacts users with multi-company configurations.
Original PR description
When generating 1099 report with multicompany setup, the payer company is wrongly assigned in the csv file. Steps: - Have 2 companies - Make one bill per company with one different 1099 vendor for each one - With both companies selected, generate the 1099 report - open the csv file -> Payer name is the same for both line opw-5442190 Forward-Port-Of: odoo/enterprise#104660 Forward-Port-Of: odoo/enterprise#103805
This update ensures that admin users cannot modify course ratings left by other users. Previously, edits to course reviews could unintentionally alter the original ratings. This change prevents data inconsistencies and maintains the integrity of course feedback.
Original PR description
*: website_slides The default values for the admin user should not be changed by editing or deleting others' messages in courses. task-5326273 **Note:** Following the first commit in this PR, the fix in PR #239554 is no longer required. So the second commit here reverts commit 89f4d0365b05b4a51c6017d5b3b67bd8e7b829ff, ensuring that the fix remains within the portal_rating module and preventing duplicate code for the same issue. See [this](https://github.com/odoo/odoo/pull/236475#issuecomment-3749796345) for more information. Forward-Port-Of: odoo/odoo#243314 Forward-Port-Of: odoo/odoo#236475
This update fixes a potential issue with Turkish invoice documents (l10n_tr_nilvera) by correcting the default journal type. Previously, the default was set incorrectly, which could have led to improper accounting. Now, the default is set to 'purchase' to ensure accurate and compliant document handling.
Original PR description
…hing The default value of the journal type parameter was incorrectly set to a move type (`in_invoice`). Although all current callers explicitly pass the correct journal type, the default value has been corrected to `purchase` to avoid potential misuse. no task-id Forward-Port-Of: odoo/odoo#242865
This update removes incorrect integer rounding from monthly VAT reports for Italian businesses (l10n_it). Previously, rounding was applied to monthly reports due to a change made in a previous update. This change ensures accurate monthly VAT reporting, aligning with Italian tax regulations. This fix resolves an issue impacting financial reporting accuracy.
Original PR description
**Description of the issue/feature this PR addresses**: Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in #193662. **Current behavior before PR**: Integer rounding on monthly l10n_it tax reports. **Desired behavior after PR is merged**: No more integer rounding on monthly l10n_it tax reports. [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243671 Forward-Port-Of: odoo/odoo#243100
This update removes unnecessary integer rounding from the monthly Italian VAT reports. The rounding was mistakenly carried over from annual reports due to a previous split in the codebase. This ensures accurate VAT reporting for Italian businesses.
Original PR description
Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in [#193662](https://github.com/odoo/odoo/pull/193662). [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) Forward-Port-Of: odoo/enterprise#104228 Forward-Port-Of: odoo/enterprise#103852
This update fixes a potential issue where users could create duplicate tax names in different branches of Odoo. Previously, the system only checked for duplicates within the branches a user could access. Now, Odoo checks all branches to guarantee unique tax names, preventing conflicts and ensuring data accuracy across the entire organization.
Original PR description
**Description of the issue/feature this PR addresses:** In companies with many branches, a user could create a tax name that already exists in another branch. This happened because Odoo only checked for duplicates in the branches the user could see. To reproduce: 1. Create `Branch A` and `Branch B`. 2. A user with access ONLY to `Branch A` creates "Tax 1". 3. A user with access ONLY to `Branch B` creates "Tax 1". 4. Both are saved, creating a duplicate name. This fix adds sudo() to the check. Now, Odoo will check all branches to make sure the name is unique, even if the user cannot see the other branches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243185
This update fixes a layout issue with image galleries containing many images, preventing indicator crowding. It also addresses a laggy feeling in image galleries due to lazy loading, improving the overall user experience by preloading carousel images and optimizing image loading timing.
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#232147This update resolves an issue where GS1 barcodes triggered a validation error, preventing users from scanning products correctly. The fix allows the system to gracefully handle GS1 barcodes that are misinterpreted as dates, ensuring consistent product scanning functionality within the Odoo Enterprise system.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in main_menu and explicitly reset parsed_results to False, allowing the normal main menu resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product, picking, or location detection still works as expected. opw-5357611 Forward-Port-Of: odoo/enterprise#104641
Code cleanup and technical improvements
This update enhances the testing process for Odoo's Arabic accounting modules (l10n_ar). Specifically, a new testing method and refactoring of the test suite ensures more reliable and accurate verification of these modules, improving overall system stability and compliance.
Original PR description
- Implemented a working `assert_json` method on `AccountTestInvoicingCommon`, that also supports the ignore_schema system and quick save using the `SAVE_JSON` test tag. - Refactors the whole test suite of `l10n_ar*` modules to use the new accounting test helpers properly. task-4891206 Forward-Port-Of: odoo/odoo#244466 Forward-Port-Of: odoo/odoo#242309
This update streamlines the testing process for the Ar-EDI module by automatically verifying request data against JSON files. This change allows tests to run without external dependencies and simplifies updates to test data by using the `SAVE_JSON` tag.
Original PR description
This commit refactors the whole `l10n_ar_edi` test suite to use the new helpers, and made it possible for the test to (finally) be run without external mode. Now, when running these new tests, the test framework will by default assert the request data with their associated JSON file. When a change is made, new overwrites for the test files can be easily changed by just adding the `SAVE_JSON` test tag on the command to run the tests. task-4891206 Forward-Port-Of: odoo/enterprise#104742 Forward-Port-Of: odoo/enterprise#103370
6 changes
Resolved issues and error corrections
This update resolves an issue where multiple picking operations were printed on the same page when multiple deliveries were selected. The change in the report layout prevented automatic page breaks, leading to a cluttered report. This ensures that reports for multiple deliveries are formatted correctly and easily readable.
Original PR description
When printing several picking operation at once, they are all in the same page. Steps to reproduce: ------------------- * Inventory>Operations>Deliveries * Create several Deliveries * Open list view to see all the deliveries * Select several deliveries * Print > Picking Operations -> All the picking operation report are on the same page. Observation: ------------- Since the change on the picking report layout https://github.com/odoo/odoo/pull/152280/changes#diff-7542c191def78bd64f54f1c33fde2c73e19e4d27f92b195c464d1d84e55b682fL6-R8 the report now uses a single article container for all records, this don't trigger automatic page break. opw-5481034
A tour was failing when Odoo was running without its demo data. This update corrects a minor inconsistency in the tour's setup, ensuring it functions correctly regardless of whether a demo database is present. This resolves a technical issue that prevented users from completing a key onboarding process.
Original PR description
The following tours were failing when executed without a demo database: `test_online_payment_mobile_self_order_preparation_changes` This commit fixes the issue by selecting the table number, ensuring consistent behavior in both demo and non-demo environments. Runbot error-[232944](https://runbot.odoo.com/odoo/runbot.build.error/232944)
This update fixes an issue where the TTC (Tax Transport Cost) value was incorrect for taxes with negative rates, and prevented errors related to missing payment method information. These changes ensure accurate tax calculations and reliable billing processes within the Odoo Enterprise system. This resolves a previously reported problem (opw-5002779).
Original PR description
This PR complete the fix in the following PR: https://github.com/odoo/enterprise/pull/104619 The TTC value was incorrect for taxes with negative tax rate An error may be raised if bill_data['payment_method'] is None opw-5002779 Forward-Port-Of: odoo/enterprise#104731
This update resolves an issue where the payer company was incorrectly identified in the 1099 report when using a multi-company configuration. The fix ensures that each 1099 report accurately reflects the correct payer company for each invoice, improving reporting accuracy and compliance. This impacts users generating 1099 reports across multiple businesses.
Original PR description
When generating 1099 report with multicompany setup, the payer company is wrongly assigned in the csv file. Steps: - Have 2 companies - Make one bill per company with one different 1099 vendor for each one - With both companies selected, generate the 1099 report - open the csv file -> Payer name is the same for both line opw-5442190 Forward-Port-Of: odoo/enterprise#104660 Forward-Port-Of: odoo/enterprise#103805
A bug was preventing users from clicking the 'Validate' button after an invalid barcode scan. This was caused by a misconfigured fix attempting to prevent concurrent barcode validations. The fix now correctly utilizes the framework's mutex mechanism for reliable validation, ensuring accurate processing of barcode scans without errors.
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#103999 Forward-Port-Of: odoo/enterprise#103835
This update resolves an issue where Turkish invoice documents were defaulting to an incorrect journal type. The default has been changed to 'purchase' to prevent potential errors and ensure proper accounting processing. This ensures accurate invoice handling within the Odoo system.
Original PR description
…hing The default value of the journal type parameter was incorrectly set to a move type (`in_invoice`). Although all current callers explicitly pass the correct journal type, the default value has been corrected to `purchase` to avoid potential misuse. no task-id Forward-Port-Of: odoo/odoo#242865
16 changes
New functionality added to Odoo
This update ensures that EDI invoices generated for Belgium, the Netherlands, France, and Luxembourg accurately reflect tax information required by Peppol standards. By adding tax category and exemption reason codes, the system now correctly handles VAT and other tax calculations, improving compliance and data accuracy for international transactions.
Original PR description
Before this commit : NL,FR,LU tax templates did not define the UBL/CII fields `ubl_cii_tax_category_code` and `ubl_cii_tax_exemption_reason_code`. As a result, EDI invoices generated for these countries were missing these tax metadata. After this commit : - All relevant NL,FR and LU tax templates now define their UBL/CII tax category and exemption reason codes. - Specific reason codes are assigned where applicable, and VATEX-EU-O is used as the default when no dedicated code exists. - EDI invoice generation now includes the correct tax metadata required by Peppol. task-4976471 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update adjusts the structure of website headings (hX) across multiple Odoo modules to enhance search engine optimization (SEO) and improve accessibility for users. By implementing a more logical heading hierarchy, we're making it easier for both search engines and users to navigate and understand our website content.
Original PR description
*: auth_totp_portal, website_event, website_event_booth_sale, website_forum, website_sale, website_sale_comparison For SEO and accessibility reasons, this commit replaces incorrect heading elements (hX) with appropriate hierarchy on pages lacking proper structure. task-5231498
This update corrects the structure of website appointment pages to improve accessibility and search engine optimization. The changes ensure proper heading hierarchy, addressing issues where headings were incorrectly used, which can negatively impact user experience and search rankings. This enhancement aligns with best practices for website design.
Original PR description
For SEO and accessibility reasons, this commit replaces incorrect heading elements (hX) with appropriate hierarchy on pages lacking proper structure. task-5231498
This update aligns the work time rate calculations across the HR and Resource modules, eliminating duplication and potential inconsistencies. It also adds restrictions to prevent unauthorized changes to the work time rate for companies, improving data integrity. This ensures a more reliable and streamlined payroll process.
Original PR description
Current behavior before PR: . The work time rate is currently computed separately in two different modules: hr_payroll (version model) and resource (resource_calendar model). Although they are…
Current behavior before PR: . The work time rate is currently computed separately in two different modules: hr_payroll (version model) and resource (resource_calendar model). Although they are calculated independently, both values represent the same concept and are functionally equivalent. This duplication can lead to inconsistencies and unnecessary complexity in maintenance . full_time_required_hours is not modifiable in the UI for a calendar linked to a company, but this restriction is not enforced at the database or back-end level. Desired behavior after PR is merged: . Synchronize the work time rate fields between the hr_payroll and resource modules to ensure they are related consistent . Add API constraints on full_time_required_hours to prevent modify its value if it belongs to a company . Modify the relevant tests to ensure consistency with the newly introduced full_time_required_hours constraints. task-5429287 --- 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 resolves a bug where alternative purchase orders were calculating prices incorrectly due to a conflict during testing. The fix aligns the test with recent currency rate updates, ensuring accurate price comparisons for alternative purchase orders. This ensures correct pricing calculations for a critical business process.
Original PR description
Issue before this commit: ========================= The test_12_alternative_po_line_different_currency test was moved to the purchase_alternative module in this…
Issue before this commit: ========================= The test_12_alternative_po_line_different_currency test was moved to the purchase_alternative module in this [PR](https://github.com/odoo/odoo/pull/218612). At the same time, the currency rate logic was updated in another [PR](https://github.com/odoo/odoo/pull/231948). During conflict resolution, the test was mistakenly reverted to the old behaviour, causing the test to break. As a result, the alternative PO price comparison became incorrect. Steps to Reproduce: ========================= - Install the purchase_alternative module. - Run the test: test_12_alternative_po_line_different_currency test case. - The test fails at: self.assertEqual(best_price_ids[0], po_alt.order_line.id) Cause of the issue: ========================= Recent currency rate changes introduced in [PR](https://github.com/odoo/odoo/pull/231948), That PR ensures that Currency rates are valid only starting the next day. During conflict resolution, these changes were removed from the test, causing invalid currency rates, leading to incorrect price comparisons. With This Commit: ========================= Ensure the test runs correctly by aligning it with the updated currency rate logic. runbot-build-error: [237989](https://runbot.odoo.com/odoo/runbot.build.error/237989)
This update resolves a compatibility issue with an older version of Odoo's spreadsheet functionality. Specifically, it ensures the spreadsheet feature continues to work correctly with older Odoo releases. This prevents disruptions for users who haven't yet upgraded to the latest Odoo version, maintaining a smoother experience.
Original PR description
Task-5477426 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#244218
This update prevents portal users with existing sales orders from modifying their country information through the profile settings. Previously, this setting was restricted for system administrators but not for portal users. This change ensures data consistency and prevents users from overriding important business information linked to their accounts.
Original PR description
Steps to reproduce: 1. Install website_forum, website_sale. 2. Confirm a Sale Order for a portal user. 3. Log in as the portal user, go to My Account -> Edit Information. 4. Country is in readonly. 5. Go to Forum -> Profile -> Edit 6. Edit the country 7. Nothing stops the user from doing so. --- Description of the issue this commit addresses: If there is already an invoice or a sale order for a partner, we restrict the edition of some of its values to system administrators. This is already enforced on the edition of the profile via /my/home route but not via the /profile/user. --- Desired behavior after the commit is merged: When an invoice or a sale order is set for a partner with portal access, he can't edit his country via the /profile/user route anymore. --- task-5331916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241908 Forward-Port-Of: odoo/odoo#237781
This update resolves an issue where the 1099 report incorrectly assigned the payer company when generating reports with multiple companies. The fix ensures that each line item in the 1099 report accurately reflects the correct payer company, improving the accuracy of tax reporting. This impacts users utilizing the multi-company accounting setup.
Original PR description
When generating 1099 report with multicompany setup, the payer company is wrongly assigned in the csv file. Steps: - Have 2 companies - Make one bill per company with one different 1099 vendor for each one - With both companies selected, generate the 1099 report - open the csv file -> Payer name is the same for both line opw-5442190 Forward-Port-Of: odoo/enterprise#104660 Forward-Port-Of: odoo/enterprise#103805
This update fixes a validation error that occurred when users attempted to unbuild tracked products. The issue stemmed from the system incorrectly reusing previously consumed serial numbers within the same manufacturing order. This change ensures accurate inventory tracking by preventing the re-assignment of serial numbers, improving order processing reliability.
Original PR description
Steps to reproduce the bug: - Create a storable product P1 - Tracking: Serial Number - BoM: Component: 1 unit of C1, tracked by Serial Number - Update the inventory of C1 - 1 unit with SN1 - 1 unit…
Steps to reproduce the bug:
- Create a storable product P1
- Tracking: Serial Number
- BoM: Component: 1 unit of C1, tracked by Serial Number
- Update the inventory of C1
- 1 unit with SN1
- 1 unit with SN2
- Create a Manufacturing Order to produce 2 units of P1
- Confirm and validate the MO using serials SN1-P1 and SN2-P1
- SN1 and SN2 of C1 are consumed
- Unbuild 1 unit of P1 with serial SN1-P1 Result: SN1 of C1 is correctly restored
- Unbuild 1 unit of P1 with serial SN2-P1
- Try to validate the unbuild
Problem:
A user error is raised:
"The serial number SN1 has already been assigned"
This happens because _action_unbuild attempts to reuse the same component serial number (SN1 of C1) without checking whether it has already been consumed by a previous unbuild operation on the same Manufacturing Order.
Solution:
This fix ensures that, when unbuilding tracked products, component serial numbers already used by previous unbuilds of the same MO are excluded from the candidate move lines.
This prevents reassigning the same serial number multiple times and avoids the validation error.
opw-5441256
Forward-Port-Of: odoo/odoo#242882This update simplifies the logging from our IoT drivers to improve readability and reduce unnecessary data. We've removed irrelevant details like process IDs and database names, and now securely identify the IoT Box using a shared token. This enhances log analysis and troubleshooting.
Original PR description
To ease readability in db's logs, we removed PID number and useless database name (as we don't have a db on the IoT Box) from the logs sent to the db. In addition, we now ensure IoT Box identity using the shared token, provided as an authorization header. see odoo/enterprise#102890
This update fixes a technical error that prevented users from correctly scheduling resource appointments within the Odoo system. The change adjusts how appointment availability is calculated, ensuring compatibility with the latest data format and preventing a 'ValueError' from occurring. This improves the reliability of the appointment scheduling process.
Original PR description
Steps to reproduce =================== 1. Open appointment app. 2. Click on resource appointment to open gantt view. => ValueError: too many values to unpack With commit [1], `_get_unavailable_intervals` now returns an interval object instead of a list of datetime ranges. However, the gantt resource unavailability logic was still expecting a list and unpacking start/stop values. This commit updates the logic to handle interval objects and extract the expected start and stop dates correctly. [1] https://github.com/odoo/odoo/commit/2dff65ab8b5a9db21d5b476065a72755cc4625be Task-5785529
This update adjusts the location of the GCC format checkbox within the Odoo settings, placing it within the 'Customer Invoices' section. This ensures users can always access this important setting, even when the broader Fiscal Localization section is hidden, streamlining the invoicing process.
Original PR description
This fix moves the GCC Format checkbox under the 'Customer Invoices' block so it remains accessible in branches where the Fiscal Localization section is hidden. task-5723793 Forward-Port-Of: odoo/odoo#244652
This update resolves an issue where outdated tests were lingering after a change to the canned response shortcut. The tests were removed to streamline the suite and ensure accurate results moving forward. This change improves the stability and reliability of the live chat feature.
Original PR description
In [1], auto focus was removed for canned responses in the navigable list. The intent was to avoid conflicts with emojis. In [2], the shortcut for canned response was changed to `::` and the auto focus behavior was restored. However, tests added in [1] were not removed. Since they were fragile (negative assertion), they are passing most of the time. This PR removes the tests that are now outdated. runbot-233358 [1]: https://github.com/odoo/odoo/pull/170900 [2]: https://github.com/odoo/odoo/pull/192953 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#244655 Forward-Port-Of: odoo/odoo#244472
This update resolves a recurring error on the IoT box where the Bluetooth adapter wasn't immediately ready, causing connection problems. The fix ensures the system handles the initial adapter startup more gracefully, preventing errors and improving the device's ability to connect to Bluetooth devices. This improves the reliability of the IoT box's functionality.
Original PR description
This PR fixes the bluetooth exceptions seen on the iot box when the bluetooth adapter isn't ready ``` 2026-01-14 10:05:48,596 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: Exception in…
This PR fixes the bluetooth exceptions seen on the iot box when the bluetooth adapter isn't ready
```
2026-01-14 10:05:48,596 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: Exception in thread Thread-3:
2026-01-14 10:05:48,743 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: Traceback (most recent call last):
2026-01-14 10:05:48,745 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/home/odoo/.local/lib/python3.13/site-packages/gatt/gatt_linux.py", line 138, in start_discovery
self._adapter.SetDiscoveryFilter(discovery_filter)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 72, in __call__
return self._proxy_method(*args, **keywords)
~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 141, in __call__
return self._connection.call_blocking(self._named_service,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
self._object_path,
^^^^^^^^^^^^^^^^^^
...<3 lines>...
args,
^^^^^
**keywords)
^^^^^^^^^^^
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/usr/lib/python3/dist-packages/dbus/connection.py", line 696, in call_blocking
reply_message = self.send_message_with_reply_and_block(
message, timeout)
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: dbus.exceptions.DBusException: org.bluez.Error.NotReady: Resource Not Ready
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger:
During handling of the above exception, another exception occurred:
2026-01-14 10:05:48,746 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: Traceback (most recent call last):
2026-01-14 10:05:48,748 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/usr/lib/python3.13/threading.py", line 1043, in _bootstrap_inner
self.run()
~~~~~~~~^^
2026-01-14 10:05:48,748 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/home/pi/odoo/addons/iot_drivers/iot_handlers/interfaces/bluetooth_interface_L.py", line 66, in run
dm.start_discovery()
~~~~~~~~~~~~~~~~~~^^
2026-01-14 10:05:48,748 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/home/odoo/.local/lib/python3.13/site-packages/gatt/gatt_linux.py", line 142, in start_discovery
raise errors.NotReady(
"Bluetooth adapter not ready. "
"Set `is_adapter_powered` to `True` or run 'echo \"power on\" | sudo bluetoothctl'.")
2026-01-14 10:05:48,748 2147 ERROR ? odoo.addons.iot_drivers.exception_logger: gatt.errors.NotReady: Bluetooth adapter not ready. Set `is_adapter_powered` to `True` or run 'echo "power on" | sudo bluetoothctl'.
```
Forward-Port-Of: odoo/odoo#243870This update corrects a bug where invoice XML files were incorrectly using the customer's VAT number instead of their company registration number (ondernemingsnummer) for key identification fields. The change ensures invoices comply with EU e-invoice standards, improving data accuracy and avoiding potential processing issues. This was achieved by prioritizing the company registry data source.
Original PR description
The base `_get_party_node` uses `commercial_partner.ref` for `PartyIdentification` and `commercial_partner.vat` for `CompanyID`. There was no logic to prefer `company_registry` when available. Refs:…
The base `_get_party_node` uses `commercial_partner.ref` for `PartyIdentification` and `commercial_partner.vat` for `CompanyID`. There was no logic to prefer `company_registry` when available. Refs: An independent invoice example: https://developer.vertexinc.com/einvoicing/docs/belgium-example-documents https://github.com/odoo/odoo/blob/40c862476382c68d7f452284074f5b44955d1f98/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1564-L1566 https://github.com/odoo/odoo/blob/40c862476382c68d7f452284074f5b44955d1f98/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1585 Steps To Reproduce: - Have accounting, account_edi_ubl_cii and contacts installed. - Create a Belgian company and set the VAT, Company ID and Reference (under Sales & Purchase tab). - Create a contact and set his eInvoice format in Accounting tab to EU Standard (Peppol Bis 3.0) and make sure to give him a country. - Go to accounting -> Customers -> Invoices and create an invoice for the contact you created. - Send the invoice to the contact and download the XML from the chatter and inspect it. - PartyIdentification/ID shows the partner's ref field value (e.g., "(odoobe)") instead of the company registration number. - PartyLegalEntity/CompanyID uses the VAT number instead of the company registration number (ondernemingsnummer). Ticket [link](https://www.odoo.com/odoo/project.task/5418190) opw-5418190 Forward-Port-Of: odoo/odoo#244518 Forward-Port-Of: odoo/odoo#243143
Code cleanup and technical improvements
This update simplifies the backend of our IoT server logger, aligning with a previous improvement. The controller has been reorganized for better clarity and now securely verifies IoT Box identities using a shared token. This enhances the stability and security of our IoT integration.
Original PR description
Following the odoo/odoo#238740, we now simplify the db's side of the IoT server logger. We also moved the logger controller to it's own file for improved readability. In addition, we now ensure IoT Box identity using the shared token, provided as an authorization header. see odoo/odoo#241355
16 changes
Enhancements to existing features
This update enhances the payment process for self-order kiosks by utilizing a new IoT protocol. It centralizes payment requests through a more reliable HTTP service, streamlining transactions and improving kiosk functionality. This change focuses on stability and efficiency for self-service ordering.
Original PR description
We now use the `iot_http` service to handle all IoT available protocols to send payment requests.
This update simplifies the process of generating consolidated invoices from Point of Sale orders. Previously, invalid orders (like those already invoiced) would halt the entire process. Now, any problematic orders are automatically ignored, allowing users to generate invoices for the valid orders efficiently. This enhances bulk invoice generation capabilities.
Original PR description
When trying to create a consolidated invoice in the POS from multiple orders, if any of them would not be valid (i.e. invoice already generated, or order still in draft), then Odoo would throw an error and not do anything. Now the orders for which invoices can't be generated will just be ignored, but for the rest of the orders the invoices will be generated as usual. This should make it easier to bulk select and generate invoices only where necessary. Task-[5491082](https://www.odoo.com/odoo/project/1737/tasks/5491082) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the restaurant POS system by automatically summing guest counts when multiple linked tables are used. Previously, each table was tracked separately. Now, when tables are linked, the system combines guest numbers for a more accurate total. This improves reporting and management of customer counts.
Original PR description
When two tables are linked in the pos, we would like to sum the guests. Here an example : If Table 1 has two guests and Table 2 has three guests, then Table 1&2 will have five guests. task: 5490906 --- 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 fixes a bug where users were getting stuck in the Point of Sale system due to IoT actions being ignored. The change ensures that actions are correctly processed, even when orders are cancelled, by using a data hash instead of a fixed UUID to identify actions.
Original PR description
This PR fixes the user getting stuck on the point of sale if some actions are being ignored by the iot box because these are considered as already executed. Currently the uuid asigned to an action doesn't change if an order is being cancelled so the iot box will systematically ignore the cancellation of pos orders if they were sent to the preparation printer before. This PR fixes this issue by instead using a hash of the data used to generate the receipt as a uuid of an action. If anything in the data changed the iot box will not ignore such actions anymore Community: https://github.com/odoo/odoo/pull/243822
This update fixes an issue where the carrier selected for a partner wasn't automatically applied when adding shipping to a sale order. The change ensures that if a partner has a preferred carrier set, it's now automatically used, streamlining the shipping process and improving accuracy. This resolves a previous bug impacting order fulfillment.
Original PR description
Steps to reproduce: - Create a storable product “P1” - Go to partner *Azure Interior*: - Set 'property_delivery_carrier_id' to any carrier - Create a sale order: - Customer: Azure Interior - Add 1 unit of P1 - Click on "Add shipping" Problem: Since this commit: https://github.com/odoo/odoo/pull/203955/files#diff-9f1fd37c63903c4c029f099d485a3f9831446850be55695a4603c05ef298885bL134-L137 the carrier defined on the partner is no longer loaded by default. Solution: Check if the carrier defined on the partner is among the allowed carriers, and if so, set it automatically. opw-5220118 Forward-Port-Of: odoo/odoo#235336
This update reverts a recent change that added new features to the mobile spreadsheet dashboards. It now returns the dashboards to display only charts, simplifying the user experience. Some adjustments were made to ensure compatibility with the existing chart-only functionality.
Original PR description
### [REV] spreadsheet_dashboard: go back to chart-only mobile dashboard This commit reverts 5cde5114d971a9edc12c9708ae0ea86bfb6db3b2, so the mobile dashboards go back to showing only the figures. Some adaptations were necessary to make the new features (carousel, granularity selector, ...) work. Task: [5447027](https://www.odoo.com/web#id=5447027&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a misleading message in the HR contract salary payroll module. We've updated the calculation to reflect part-time gross salaries instead of full-time salaries. This ensures accurate reporting and avoids confusion for payroll processing.
Original PR description
Since we are now setting the part-time gross and not the full time gross, this message is misleading.
A bug prevented users from successfully using the Odoo obfuscation command. The issue stemmed from the command incorrectly handling database names. This update corrects the command to properly process a single database, ensuring the obfuscation process functions as intended. This resolves a technical issue impacting database security.
Original PR description
It is not possible to use the obfuscate command Steps to reproduce: 1. Initialize a database `test` 2. In a terminal, try to obfuscate the database with the command `python odoo/odoo-bin obfuscate --pwd=1234 -d test` 3. An error occurs Issue: `config['db_name']` returns a list Solution: Make sure we use obfuscate with a single database and get the first (and only) database in the list opw-5480280
This update corrects a bug where users could incorrectly modify the category snippet, leading to empty blocks on the website. The change ensures the snippet is used only for categories, preventing unintended content changes and maintaining website consistency. This resolves an issue impacting product display.
Original PR description
Steps to reproduce: ==================== 1- Go to any product and in the tab Sales add some accessory products 2- Go to the website and edit a page 3- Add a category list block 4- Change category list filter to "Accessories for product" 5- Save -> The block is empty Cause: ====== The category snippet was meant to be used only for categories. The problem is that its possible to change from "Categories List" to anything else. When the user makes the choice to add a categories snippet he shouldn't be able to change the content of the snippet from categories to products, blogs, etc.. Solution: ========== Prevent replacing the category snippet to anything else. opw-5497284
This update prevents the HTML Builder editor from freezing due to rare errors. A timeout mechanism is implemented as a last resort to release the editor and alert the user to potential data issues. The change also adds safeguards to long-running operations to ensure a smoother user experience.
Original PR description
Before this commit, if an error occurred within the mutex that did not explicitly throw, the mutex could remain locked indefinitely. This blocked subsequent actions and prevented the user from saving. This commit introduces a timeout mechanism for Operations. This is intended for very rare cases as a last resort to prevent the editor from becoming completely unresponsive. When a timeout occurs: - The mutex is released, allowing the user to recover (e.g. by deleting the faulty snippet). - The user is notified of the issue. - A warning is displayed during saving to indicate that the content might be in a corrupted state. Additionally, the `canTimeout: false` flag is added to options that are expected to remain open for long periods (such as the snippet modal). task-5152911
This update resolves an issue where the payer company was incorrectly identified in the 1099 report when generating reports across multiple companies. The fix ensures that each 1099 line accurately reflects the correct payer company, improving the accuracy of tax reporting for businesses with multiple entities.
Original PR description
When generating 1099 report with multicompany setup, the payer company is wrongly assigned in the csv file. Steps: - Have 2 companies - Make one bill per company with one different 1099 vendor for each one - With both companies selected, generate the 1099 report - open the csv file -> Payer name is the same for both line opw-5442190 Forward-Port-Of: odoo/enterprise#104660 Forward-Port-Of: odoo/enterprise#103805
This update fixes an issue where changing the rental period of an order didn't automatically update the associated rental transfers. The fix mimics the rescheduling behavior of purchase orders, ensuring that rental transfers are accurately adjusted when the rental period is modified. This improves the reliability of rental order management.
Original PR description
### Steps to reproduce: - In the settings enable "Rental Transfers" - Create a storable and rentable product P - Create and confirm a rental order for 1 unit of P - Change the rental period to 10 days in the future #### > The rental tranfers were not updated accordingly ### Cause of the issue: Nothing is currently implemented to reschedule the rental transfers. ### Fix: We somewhat mimic the reschedule purchase behavior: https://github.com/odoo/odoo/blob/6ca34a0f5347e0611cde95453119dda8b40fa589/addons/purchase_stock/models/purchase_order_line.py#L98-L101 But we rely on the order itself rather than its order lines since the `start_date` and the `return_date` are related fields so that no `write` is triggered when the order is rescheduled: https://github.com/odoo/enterprise/blob/96a80f583a0ca502ff06bc05d03775c76c6a7537/sale_renting/models/sale_order_line.py#L18-L19 opw-5158508 Forward-Port-Of: odoo/enterprise#102437 Forward-Port-Of: odoo/enterprise#101334
This update addresses a technical issue that caused list views to crash when aggregating data from fields with monetary values. The fix ensures that the system gracefully handles missing currency information, preventing aggregation errors and improving the stability of list views. This resolves a bug impacting data reporting.
Original PR description
This commit resolves a traceback during list view aggregation when the view is grouped. The crash occurred specifically when aggregating a `float` field that uses the `monetary` widget. Unlike true `monetary` fields, the server does not automatically send a `currency_id` aggregate for `float` fields. The aggregation logic previously failed when this data was missing; it now handles the case by ignoring it since it's not supported. opw-5725692
This update resolves an issue where combo choices weren't displaying correctly in the self-order and kiosk modes. Previously, users had to reconfigure combo choices after setting a product variant. This change ensures combo choices are displayed correctly without requiring manual reconfigurations, improving the self-order experience.
Original PR description
Before the fix, when we set a product variant as combo choice. In self/kiosk, we'll see the product template instead of the product itself. And we need to configure it again. It occured because for all of the products in the kiosk/self, we display the product template. The expected behavior if we set a product variant as combo choice is to have the product variant in the combo directly without having to reconfigure it. The bug occurs only since 19.0 because a fix was already done from 18.3 to 18.4 in this pr : #219908 but the fwport for 19.0 has never been merged. task: 5493798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the presence status widget was incorrectly displayed for archived employees in the HR module. The change hides this widget when an employee is marked as inactive, improving the user experience and ensuring consistent data presentation. This ensures archived employee records are displayed cleanly.
Original PR description
**Steps to reproduce:** Navigate to Employees -> Open an archived employee -> the presence status appears below the Archived banner **Solution:** Hide the presense status widget when the employee is inactive Task: 5350479
This update resolves an issue where user avatars in the Chat UI were appearing distorted or incorrectly sized. The change ensures avatars are displayed properly using the ‘object-fit: cover’ style, providing a consistent and professional user experience. This improves the visual quality of user profiles.
Original PR description
Before this commit, user avatars in the Chater UI were not displayed using the object-fit: cover style, causing distorted or improperly scaled images. Current behavior before PR: <img width="671" height="380" alt="image" src="https://github.com/user-attachments/assets/a4b7ef3a-0c69-4fec-bf2a-70c9bd89236e" /> Desired behavior after PR is merged: <img width="663" height="384" alt="image" src="https://github.com/user-attachments/assets/479586c8-a01c-45fb-9e46-9246616e1329" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243181 Forward-Port-Of: odoo/odoo#242320
8 changes
Enhancements to existing features
This update organizes UBL test files for better compatibility with future move formats and improved schema validation. The test files have been moved to a more structured folder within the account_edi_ubl_cii module, streamlining testing and development efforts. This change supports ongoing improvements to the UBL invoice generation process.
Original PR description
This commit rearranges the UBL test files' subfolder to be one level higher, from `export/bis3/be` to `export/bis3/invoice/be`, in preparation for supporting different move formats and for better ignore schema support. task-4891206
Resolved issues and error corrections
This update resolves an issue where users were seeing a generic 'Oh snap!' error message instead of the correct 'Invalid Operation' message when saving Time Off allocations with incorrect dates. The fix backports changes from the 18.3+ release to ensure a better user experience and accurate error display.
Original PR description
This commit https://github.com/odoo/odoo/commit/e566570e82e9 introduced a regression where the saveButtonClicked method automatically bound onSaveError as the error handler. This displays…
This commit https://github.com/odoo/odoo/commit/e566570e82e9 introduced a regression where the saveButtonClicked method automatically bound onSaveError as the error handler. This displays FormErrorDialog with "Oh snap!" for all save errors, causing UserErrors and ValidationErrors to show the generic "Oh snap!" message instead of the proper "Invalid Operation" dialog. If you compare the original commit to the one here for the forward port 18.3+: https://github.com/odoo/odoo/pull/224620, you can see that the author reverted the problematic onError binding in saveButtonClicked and added forceLeave support to handle RedirectWarning redirects when the form is dirty. This PR backports those same changes to 18.0. Steps To Reproduce: 1. Go to Time Off > Allocations > Create new allocation. 2. Set an End Date before the Start Date. 3. Click Save. 4. Error displays as "Oh snap!" instead of "Invalid Operation". 5. Switching tabs then shows the expected "Invalid Operation" dialog. Ticket [link](https://www.odoo.com/odoo/project.task/5488127) opw-5488127 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a technical issue related to how tax reverse charges are reported on BIS3 invoices. Previously, the system couldn't accurately handle these charges, leading to potential reporting errors. Now, tax reverse charges are correctly categorized as 'Prepaid Amounts' to ensure accurate invoice generation.
Original PR description
There is no WithholdingTaxTotal node in BIS3. You cannot report any negative tax amount as taxes. You can only report VAT taxes but tax reverse charge are not considered as VAT. This commit reports the tax reverse charge amount as a PrepaidAmount instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a technical error in the l10n_au_hr_payroll module that was causing a warning message to appear incorrectly on the TFN dashboard. The fix ensures accurate reporting of TFN status for employees, preventing potential payroll issues. This update was triggered by a specific configuration related to employee TFN status.
Original PR description
Steps to reproduce: ------------------- 1. Install l10n_au_hr_payroll. 2. Enable multi-company and switch to an AU company. 3. Change an existing employee’s company to the AU company ([employee…
Steps to reproduce:
-------------------
1. Install l10n_au_hr_payroll.
2. Enable multi-company and switch to an AU company.
3. Change an existing employee’s company to the AU company
([employee created more than 28 days ago](https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/l10n_au_hr_payroll/data/hr_payroll_dashboard_warning_data.xml#L31)).
4. Under the payroll tab, set the TFN Status to:
"Employee applied for TFN but didn't receive it yet, less than 28 days ago".
5. Open Payroll.
Issue:
--------
A traceback occurred:
```
Error: NameError("name 'invalid_employees' is not defined")
```
Cause:
------
The evaluation code computes `warning_count` using
an undefined `invalid_employees` variable.
Solution:
---------
Define `invalid_employees` before using it to compute
`warning_count` and `warning_records`.
**NOTE:**
The [upgrade script](https://github.com/odoo/upgrade/blob/ed5bc3fd99ef6fba4bc7162934df36396ae9fc3f/migrations/l10n_au_hr_payroll/saas~18.4.1.0/end-migrate.py#L30) is already available from version 18 to 19.
opw-5459998This update resolves an issue where the 'Import Bank Statement' action incorrectly selected a journal in multi-company environments due to elevated server permissions. The fix ensures the action filters by the currently chosen company, preventing incorrect journal selection and improving data accuracy. A new test confirms the fix's reliability.
Original PR description
Issue: when using the server action 'Import Bank Statement' the code would not filter on the currently selected company for choosing the journal on which to encode the bank statement and simply take the first result. Because the server action is running with sudo rights, in a multi-company environment more then one journals are found and the selected one is often wrong. Solution: filter on company during the selection of the journal. Note: a test was added in which we run the function with sudo rights to ensure an error is raised when the journal does not exist on the currently selected company, even if it is present on another company. Task-5494685
This update removes a previously implemented fix for the website slides module, streamlining the code and preventing duplication. The change ensures the fix remains contained within the portal_rating module, improving efficiency and reducing potential maintenance overhead. This update is crucial for maintaining a clean and reliable user experience.
Original PR description
Following the changes in PR #236475, the fix in PR #232696 is no longer required. This commit reverts commit 4c02c970ed824e2b1ade90b905365519044abc69, ensuring that the fix remains within the portal_rating module and preventing duplicate code for the same issue. This change should be forward ported up to saas-18.2. For later versions, the revert is already handled in PR #243783.
This update resolves a problem where gift card coupons weren't being generated correctly, leading to errors. The fix ensures coupons have enough time to be created and that the gift card is added to the order before the page is refreshed, preventing a common error.
Original PR description
When the last tour of this step was ignored, the coupons did not have enough time to be generated, resulting in an error because we are trying to access them later on in the backend. We thus had an out of range error on the coupons list. Another issue was that we refreshed the page too soon after clicking the gift card product, so it did not have time to add it to the order before refreshing the page. We now use a the *endTour* function to make sure the coupons have time to be generated to avoid said error. We also make sure that the gift card has been added to the order before refreshing the page. runbot-232857
This update resolves an issue where users would receive an error when selecting a company after it had been unarchived. The problem stemmed from a timing conflict in how the system refreshed company data. This change ensures that the system correctly identifies and allows access to recently unarchived companies, improving usability.
Original PR description
**Steps to reproduce** - Have at least two active companies - Archive one company - Unarchive the company - Select the just unarchived company in the company selector - `Access Error: Access to unauthorized or invalid companies.` **Cause** There was a timing issue between the cache invalidation and the call to super. After the cache invalidation, if `_get_company_ids` of `res.users` was called before the call to `super` in the `write`, it would not return the just unarchived company. opw-5449925 Forward-Port-Of: odoo/odoo#244482
3 changes
Enhancements to existing features
This update enhances the spreadsheet module by adding logging when exporting large datasets, particularly during spreadsheet downloads, clipboard copies, and printing. It also restricts access to frozen or XLSX spreadsheet downloads to authorized users, improving data security and control.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances logging when exporting large amounts of data from Odoo spreadsheets, addressing potential performance issues. It now tracks data downloads, clipboard copies, printing, and freezing, providing better visibility into spreadsheet activity. Additionally, access to frozen or XLSX spreadsheet downloads has been restricted to authorized users.
Resolved issues and error corrections
This update corrects a technical issue related to the transmission of ELM (Einnahmen-Lohn-Meldung) tax data for Switzerland, specifically for the 2026 canton import. The change ensures accurate reporting of payroll taxes for businesses operating in multiple cantons, aligning with updated Swiss tax regulations.