Daily updates from Odoo
Monday, January 19, 2026
300 changes
14 changes
Resolved issues and error corrections
This update resolves a test failure within the im_livechat module. The issue stemmed from a mismatch between the demo data's time zone setting and the test's expectations. By explicitly setting the time zone for the OdooBot partner record, the test now passes correctly.
Original PR description
This PR fixes a failing assertion in `test_channel_get_livechat_visitor_info`. The test fails since [*] because the demo data sets the OdooBot time zone to 'Europe/Brussels', while the test was asserting it to be False. This PR explicitly sets the time zone of the OdooBot partner record and updates assertions accordingly. [*] https://github.com/odoo/odoo/pull/210094 runbot-237778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue where live chat agents weren't receiving the latest conversation updates. The change ensures the live chat system correctly connects to the channel bus, guaranteeing agents see real-time updates within the live chat interface. This improves the agent experience and the quality of customer interactions.
Original PR description
The `test_form_view_embed_thread` ensures that the live chat list view redirects to the discuss app and that the bus subscription for the selected channel is properly made. This ensure that a live chat agent looking at a channel will receive the latest updates for the conversation. To ensure the bus subscription is made, the bus service is patched in order to detect calls to add or remove methods. However, we only wait for `whenReady` which is not enough to guarantee the bus is already exposed via `odoo.__WOWL_DEBUG__`. This PR ensure we wait for the list view to be displayed, which ensures the webclient is mounted and the debug info is already set. runbot-234928 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 a bug in the Point of Sale system that prevented users from creating orders with custom prefixes. The change ensures order names are correctly generated, avoiding errors related to data type conversions. This ensures consistent order naming functionality across Odoo 19.1.
Original PR description
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with…
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with config number 1 active and make a purchase - A traceback appears saying that we can't convert the sequence to an Integer **Why the fix:** Having a custom prefix with letters used to work, but in version 19, we now store the sequence_number with the prefix, which can be composed of characters which can not be stored in an Integer field such as sequence_number. To prevent this error, we remove the prefix and the suffix (which has the same issue) from the sequence_number before storing it. We then add the prefix and the suffix back when computing the order's name, so that it's consistant with the prefix and the suffix the user chose. This is the way the order's name was computed before version 19.0, which saw the prefix and suffix disappear from the order's name. opw-5386575 Forward-Port-Of: odoo/odoo#239515
This update resolves an issue where the l10n_mx_edi module was encountering a 'singleton error' when multiple invoices with the same payment method code were processed. The fix ensures that the system correctly handles these scenarios, preventing errors and improving data accuracy. This change impacts the generation of invoice reports.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#103460A test used to fail intermittently due to a race condition caused by a lingering success notification. This commit resolves the issue by automatically closing the notification message after an inventory adjustment, ensuring accurate test results. This improves the reliability of the inventory packaging test.
Original PR description
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The…
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The error message is: `AssertionError: 16.0 != 15.0` In the tour, we do a first inventory adjustment where we set the `proquct1` qty to 16, then we do a second inventory adjustment where we set its qty to 15. Now, the assert sometime fails because in the tour, the last step check the success message is visible: ```javascript trigger: ".o_notification_bar.bg-success", ``` The issue with that is that we already do a first inventory adjstment and its success notification is still visible while processing the second inventory adjustment, creating a race condition. To fix that, we just need to close the first notification message, and to do so, this commit back-ports and uses the step utils' method `checkNotificationMessage` (see [1]) since this method checks a notification message is there and close it. [1]: https://github.com/odoo/enterprise/pull/101495 runbot-build-error: [227692](https://runbot.odoo.com/odoo/runbot.build.error/227692) Forward-Port-Of: odoo/enterprise#104614 Forward-Port-Of: odoo/enterprise#104481
This update resolves an issue where demo data installation caused incorrect packaging behavior during a specific test. The fix ensures that new packages are created with unique names, preventing the system from incorrectly adding items to the demo data package instead of the intended new package. This improves the reliability of the demo data.
Original PR description
The test `test_put_in_pack_in_new_created_package` does a simple thing: 1. We scan a product then put it in pack; 2. We scan a second package than scan the package created during previous put in pack. To be sure we scan the package created in 1., we reset the package sequence so we're sure the created package will have 'PACK0000001' as name. The issue is: when demo data are installed, a package with this name is already created, which means when we scan 'PACK0000001' in step 2., instead of packing the second line into the newly created package, we pack it into the demo data package. To avoid that, this commit sets the package's sequence to 42 so we're sure the created package will be named 'PACK0000042'. runbot-build-error: [98126575](https://runbot.odoo.com/odoo/runbot.build.error/237802) Forward-Port-Of: odoo/enterprise#104623
This update removes a recent change that was causing performance issues and instability within the spreadsheet dashboard feature. The previous attempt to use ETags for efficiency wasn't delivering the expected benefits and was creating more problems than it solved. This reversion ensures the dashboard continues to function reliably.
Original PR description
This reverts commit 3b014027cb785a2c567ec94fd14ae24f39f92783. We already had many issues (and probably a lot more to come) with etag computation in spreadsheets, the ratio cost/benefit is not worth it. This reverts the etag computation in spreadsheet dashboards. Task: 5504270 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 change removes a recent update that was causing issues with spreadsheet performance. The effort to implement etag computation in spreadsheets didn't outweigh the problems encountered, so we've reverted the changes to restore previous functionality. This ensures spreadsheets continue to operate efficiently.
Original PR description
This reverts commit 60fc64d0fd2458f60b5d922fe12c0d09dc2bcde0, 67ba628326b4eb0336095b912f40d0f320a848aa and 8f3e242e197b2f269827499b0d89b2e9080f5d09. We already had many issues (and probably a lot more to come) with etag computation in spreadsheets, the ratio cost/benefit is not worth it. This reverts the etag computation for spreadsheets. Task: 5504270
This update resolves an issue where users couldn't immediately configure their website after installing the website module. The fix ensures the website setup configurator is correctly triggered during installation, streamlining the user experience and preventing delays in website setup. This change addresses a previous installation failure.
Original PR description
Since [1], installing the website module fails to launch the configurator, preventing users from setting up their website immediately. This issue occurs because `website_generator` is set to auto-install. During the installation sequence, `website_generator_wait` overrides `website_configurator_todo`, causing the latter to be bypassed. This commit provides a temporary fix to ensure the configurator is correctly triggered [1]: https://github.com/odoo/enterprise/commit/c0f26ac040b1d8ff81a2f53306e81da1778d70c2
This update resolves a recurring issue in the Odoo message copy test that occasionally failed. The fix modernizes the test to more reliably capture the copy functionality by focusing on the composer's state rather than relying on potentially unreliable keyboard shortcuts. This ensures the test consistently passes, improving overall system stability.
Original PR description
Before this commit, the "Copy Message Link" test was sometimes failing. It happens for two reasons: - It presses "ctrl+v" with the intent of copying the message link in the composer but doesn't check if the composer is focused (it should not be as the test clicks away to copy the link). - It then presses "enter" with the intent of posting the message, without checking if the composer is filled or even ready to send. This test replaces the "press" steps: - "ctrl+v" is replaced by `insertText`: we already check that the copy works and "press" is less reliable. - We click on the send button when enabled. runbot-237538 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 technical issue that prevented test cases from running correctly. The `pickup_time` and `return_time` fields were initially defined in one module, but later moved to another. This change required updating related code to ensure proper functionality and test case setup.
Original PR description
During the development of odoo/enterprise#102625, the fields `pickup_time` and `return_time` were first defined in `sale_renting`, as they were prior to the PR, but during development it was decided to move the fields into `website_sale_renting`, where they are actually used. Unfortunately, some remaining code in `sale_renting` was not updated accordingly, which caused the setup of test cases to fail when `website_sale_renting` was not installed along with `sale_renting`. runbot-237987
This update resolves a technical issue that caused translation tests to fail due to delays in loading sidebar content. By preloading translated elements, the system now ensures the sidebar is fully ready before tests begin, improving test reliability and speed. This enhances the overall translation process.
Original PR description
When opening the sidebar in translation mode, translated elements must be preloaded before the sidebar renders. Without preloading, the fetch requires an extra tick to complete, causing tests that immediately check sidebar content to fail because the sidebar isn't fully open yet. runbot-237540 Forward-Port-Of: odoo/odoo#242490
This update fixes an issue where EU Standard invoices (Peppol Bis 3.0) were incorrectly displaying the customer's reference instead of the company registration number for key identifiers. The change now utilizes the company registry information, ensuring compliance with Belgian e-invoice regulations. This ensures accurate data transmission for VAT reporting and other business processes.
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#244143 Forward-Port-Of: odoo/odoo#243143
This update resolves an issue where the forecasted inventory view incorrectly linked manufacturing reservations (mrp.production) to stock picking records. The fix ensures that the correct manufacturing reservation document is displayed, improving accuracy and usability for users managing production planning.
Original PR description
**Issue:** The forecasted inventory view assumed that line.reservation was always a `stock.picking`. In manufacturing flows, the reservation can be an `mrp.production`, which caused incorrect…
**Issue:** The forecasted inventory view assumed that line.reservation was always a `stock.picking`. In manufacturing flows, the reservation can be an `mrp.production`, which caused incorrect navigation to a `stock.picking` record. Fix this by comparing both model and id when checking if the reservation differs from the outgoing document, and by opening the reservation using its actual model. This ensures the correct document is shown and avoids duplicate or invalid links in the "Used by" column. **Steps to reproduce:** - Create a v19 db with sale,mrp,sale_stock with `--demo-true`. - Go to products -> search for 'FURN_0269' product and open form view. - open forecasted smart button for forecasted reeport. - check the used by column for mrp reservation - i.e,: `WH/MO/00001 - WH/MO/00001` appears twice. - clicking on first, opens correct record of `mrp.production` where the units is reserved. - clicking on the second, navigate to false record of `stock.picking` by taking the id of `mrp.produciton` as the reserve is having `_name: "mrp.production"` **Screenshots from UI:** - Product page: <img width="1253" height="572" alt="stock_1" src="https://github.com/user-attachments/assets/13cd7f0a-34b0-48ea-a8d5-5337cbf9f5a5" /> - Forecasted report for that product: <img width="1908" height="994" alt="stock_2" src="https://github.com/user-attachments/assets/ce0af8a3-9f37-469c-8119-36b6e7be9c4a" /> - Clicking on First `WH/MO/00001` button: <img width="1265" height="568" alt="stock_3" src="https://github.com/user-attachments/assets/a8cb8a08-5c24-45f7-ad2e-5e3987f9ee70" /> - Clicking on second `WH/MO/00001` button, navigating to incorrect `stock.picking` by taking id of `mrp.production` even though there is no picking avaiable: <img width="1264" height="519" alt="stock_4" src="https://github.com/user-attachments/assets/3a2d1613-ccbb-4994-898c-c885690c507e" /> **Final view Before and After the Fix:** - For final view, In order to check the reservation done by `stock.picking`, I have created a `sale.order` having delivery for the same product to showcase both of them are working. - **Before Fix:** <img width="1907" height="994" alt="stock_5" src="https://github.com/user-attachments/assets/4441910e-348b-4270-ab1b-db903b334c97" /> - **After Fix:** <img width="1905" height="940" alt="stock_66" src="https://github.com/user-attachments/assets/ba288e6b-b2c9-47ed-b752-233ff876fb55" /> opw-[5481220](https://www.odoo.com/odoo/70/tasks/5481220?debug=1) upg-[3804157](https://upgrade.odoo.com/odoo/upgrade.request/3804157?debug=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244222
5 changes
Enhancements to existing features
This change updates the source of lead mining data within Odoo's IAP to Dun & Bradstreet. Previously, data came from Clearbit, which is being discontinued. This ensures continued access to high-quality lead information for our users, leveraging a provider already used for partner autocomplete.
Original PR description
Before this commit: - Lead mining data was fetched from `clearbit` provider on IAP which is now going to be removed for discovery service After this Commit: - Data will now be fetched from `dun_and_bradstreet` provider on IAP which we are already using for the `partner_autocomplete` IAP PR: https://github.com/odoo/iap-apps/pull/1274 task-4873238 Forward-Port-Of: odoo/odoo#235521
Resolved issues and error corrections
This update corrects a technical issue where the website's payment providers were incorrectly linked to multiple companies, causing errors during testing. The fix ensures that each payment provider is associated with the correct website company, resolving the test failure and improving data consistency.
Original PR description
What is fixed ------------- The test_payment_provider_visibility_with_portal didn't pass due to a multi company issue. In demo data, "Demo" payment provider exists for different companies which led the search method to return every one of them. Trying to assign the shop website id to each of them then raises an error as their company_id are inconsistent. The fix ------------- We now ensure only one provider is selected and its company is the same as the website's company. Runbot error : 237822 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where invalid warehouse locations triggered repeated geolocation requests to OpenStreetMap. Now, when geolocation fails for an invalid address, a default coordinate is set, preventing further unnecessary requests and improving system performance. This ensures smoother location selection for users.
Original PR description
When a warehouse location had no coordinates, a request to geolocate the address was made to OpenStreetMap every time the location selector was open. However, when the address was invalid, the geolocation failed, and no coordinates were set, which caused further geolocation requests being continuously sent. This commit changes the geolocation behavior to set invalid coordinates for the address when the request fails, thus disabling future geolocation attempts for that address. Forward-Port-Of: odoo/odoo#244439
This update fixes an issue where clicking links within the Odoo chat window on mobile devices caused the window to remain open and block the newly opened page. The change automatically folds the chat window after a link click, ensuring users can immediately view the linked content. This enhances usability and prevents frustration for mobile users.
Original PR description
Clicking on an odoo link in the chat window will take the user to the related page in odoo. However, in mobile view, the chat window remains unfolded and covers the entire page, so the user can't see the newly opened page below the chat window unless they fold the chat window. This change fixes this by folding the chat window in mobile view when clicking an odoo link inside the chat window. task-4762503 Forward-Port-Of: odoo/odoo#244383 Forward-Port-Of: odoo/odoo#208440
This update resolves an issue where the l10n_mx_edi module was encountering a 'singleton error' when multiple invoices referenced the same payment method. The fix ensures that the system correctly handles these scenarios, preventing errors and improving data accuracy for Mexican electronic invoicing reports.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#1034609 changes
Enhancements to existing features
This change updates the source of lead mining data within the IAP system. We've switched from the Clearbit provider to Dun & Bradstreet, a provider already used for partner autocomplete. This ensures more consistent and reliable lead information is available to our users.
Original PR description
Before this commit: - Lead mining data was fetched from `clearbit` provider on IAP which is now going to be removed for discovery service After this Commit: - Data will now be fetched from `dun_and_bradstreet` provider on IAP which we are already using for the `partner_autocomplete` IAP PR: https://github.com/odoo/iap-apps/pull/1274 task-4873238 Forward-Port-Of: odoo/odoo#235521
Resolved issues and error corrections
This update fixes an issue where sign templates created in languages other than English didn't correctly reflect the document name. The fix ensures that template names are always updated to match the document name, regardless of the user's language setting, improving the user experience for international users.
Original PR description
## Steps to reproduce: 1. Upload a new PDF document to be signed. 2. Select it in the Documents app to sign it. 3. Check the name of the sign template created. ## Issue: When creating signature templates in languages other than English, the template name would stay as "New Template" instead of updating to the actual document name. This happened because the code was comparing the template name against a translated version of "New Template", but the template was initially created with the English default value. Since "New Template" ≠ "Nueva Plantilla" (Spanish), the comparison failed and the name never got updated. The fix ensures we always compare against the original English default value, so the template name gets properly updated to match the document name regardless of the user's language. Related commit: 4254542 opw-4980747
This update fixes an issue where product prices in Point of Sale were incorrectly displayed due to a double currency conversion. The fix prevents the list price from being multiplied by the exchange rate twice, ensuring accurate pricing for users with multi-currency POS configurations. This improves the reliability of sales transactions.
Original PR description
**Steps to reproduce:** - Have a company that has USD as currency - Make a PoS config that has another currency in the sales journal, such as AED - Open that PoS - Click on a product, then go the the Info tab - Some of the displayed prices will be wrong, as they are multiplied by the exchange rate twice **Why the fix:** If the config's currency is different from the company's currency, we convert the templates' list_price to match the config's currency. This is done in those lines https://github.com/odoo/odoo/blob/b64bdf67dcf273a7e666928ffa6df37b45566f2b/addons/point_of_sale/models/product_template.py#L277-L278 The current problem with this is that this function is called twice, thus multiplying the list_price twice and making it wrong. We can prevent this by checking if it has already been converted before multiplying the template's list_price. opw-5226656
This update allows users to automatically generate QR codes on invoices linked to payment links, enhancing payment convenience. The previous issue occurred when generating these QR codes via API calls due to a missing environment object. This fix provides an optional environment object to the QR code generation process, resolving the error and enabling the feature to function correctly.
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-5487075This update corrects a technical issue preventing users from importing XML invoices through the accounting module. The problem stemmed from a required 'CustomizationID' tag being missing from the XML files, which is now enforced. This ensures proper invoice processing and avoids import failures.
Original PR description
[FIX] account_edi_ubl_cii: xml import error customization id This error happens when the user tries to import an xml invoice in accounting > customer > invoice and the CustomizationID tag is empty. The cause of this is the CustomizationID tag that exists in the file, but it's empty. This tag is mandatory in a ubl file, so we cannot process the file if it's empty. opw-5238398 Forward-Port-Of: odoo/odoo#236668
This update fixes an issue where product prices weren't correctly calculated when using Point of Sale with different currency settings. The fix ensures standard product prices are converted to the PoS currency, preventing incorrect pricelist calculations and ensuring accurate order totals. This improves the reliability of pricing within the PoS system.
Original PR description
The standard price of the products were not converted to the currency of the PoS journal, which could lead to issues when creating pricelist items based on the standard price. Steps to reproduce: ------------------- * Change the currency of any PoS journal to a different currency than the company currency. * Create a product with a standard price > 0. * Create a pricelist that uses the standard price as a base price. (e.g. price = standard price * 2) * Add this product to a PoS order > Observation: The price is not correctly computed according to the pricelist, because the standard price was not converted to the PoS currency. Why the fix: ------------ We just make sure to convert the standard price of the products when loading the products in the PoS session the same way as we do it for the list price. opw-5124388 Forward-Port-Of: odoo/odoo#241620 Forward-Port-Of: odoo/odoo#241168
This update resolves an issue where subfolders accessed via shared links weren't initially displayed correctly. The fix ensures that subfolders are immediately accessible when a user views a shared folder, eliminating the need for a refresh. This enhances the user experience for sharing and accessing documents.
Original PR description
**Steps to reproduce:** - Create a portal user - Go to the documents app - Click on the marketing folder - Share the marketing folder through a link (Anyone with a link = viewer + discoverable) -…
**Steps to reproduce:** - Create a portal user - Go to the documents app - Click on the marketing folder - Share the marketing folder through a link (Anyone with a link = viewer + discoverable) - Copy the share link - Login with the portal user in an incognito window - Paste the share link in an incognito browser - Click on "brand 1" folder, result nothing is showing while there should be a folder and a picture - Click on "brand 2" - Click back on "brand 1" and now the folder and picture are visible - If you click on a subfolder of "brand 1" you also get an error **Issue:** Discoverable subfolders accessed using `accessToken` are not available on the first read of a user and this happens for each level of the hierarchy (refresh is needed each time). When using sharing link to display folders with a user, the subfolder document access is created on `/documents/touch/` using `_from_access_token`. But on the js side the call is delayed (with debounce) and occurs after the `web_search_read`. This means that subfolders are only accessible after a refresh or by switching back and forth between folders. Also, even after the folder is displayed, if there are other subfolders in it, going deeper in the hierarchy won't work as well without a refresh due to the `search_panel_select_range` missing the new folder. **Fix:** Not sure on the best way to fix this, the issue will always be related to performance. Current fix checks if a reload is needed by sending a flag in the `/documents/touch/<access_token>` request result when a new document access was created. opw-5156297 Forward-Port-Of: odoo/enterprise#104451 Forward-Port-Of: odoo/enterprise#99820
This update resolves an issue where the l10n_mx_edi module was encountering a 'singleton error' when multiple invoices with the same payment method code were processed. The fix ensures that the system correctly handles these scenarios, preventing errors and improving invoice generation reliability. This change impacts the Mexican e-invoicing reports.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#103460This update fixes a minor visual issue in the contact view of delivery addresses. The GLN field was awkwardly positioned and lacked a label, making it difficult to find. The change repositions the label before the notes field for better clarity and usability.
Original PR description
The field is placed weirdly in the view when opening the contact view of the delivery address. There is no label, making it almost impossible to discover, and it is in the middle of everything. Let's put it down before the notes field. Before: <img width="971" height="510" alt="image" src="https://github.com/user-attachments/assets/2e0e7d96-1a7f-4fe5-b17d-4c5b25a3e7bf" /> After: <img width="824" height="554" alt="image" src="https://github.com/user-attachments/assets/3bc47f20-72a9-4247-8dd3-9e939046c6d7" /> task-none
3 changes
Enhancements to existing features
This update expands Odoo's ability to handle Ukrainian Tax Identification Numbers (TINs). Previously, only 12-digit numbers were accepted, but now 8-digit numbers – including those prefixed with 'UA' – are supported. This ensures accurate data entry for Ukrainian businesses and avoids errors.
Original PR description
with this commit:- - We are adding support for Ukrainian Tax ID numbers of 8 digits, which was 12 previously. - The following formats are now accepted: - National company numbers: 8 digits (e.g., 12345678) - European company numbers: 8 digits prefixed with 'UA' (e.g., UA12345678) - Individual numbers: 12 or 10 digits (e.g., 123456789012) - This change allows users to enter Ukrainian TINs that were previously incorrectly rejected due to length restrictions. task-5414806 opw-5373469 Forward-Port-Of: odoo/odoo#243258
This change updates the source of lead mining data within Odoo from Clearbit to Dun & Bradstreet. This aligns with a broader shift in data services and leverages an existing provider used for partner auto-completion, ensuring data consistency and improved lead quality. This update is part of a larger IAP migration.
Original PR description
Before this commit: - Lead mining data was fetched from `clearbit` provider on IAP which is now going to be removed for discovery service After this Commit: - Data will now be fetched from `dun_and_bradstreet` provider on IAP which we are already using for the `partner_autocomplete` IAP PR: https://github.com/odoo/iap-apps/pull/1274 task-4873238 Forward-Port-Of: odoo/odoo#235521
Resolved issues and error corrections
This update corrects a bug that prevented users from importing XML invoices through the accounting module when the CustomizationID tag was missing. The CustomizationID tag is a required element in UBL files, and this fix ensures that invoices with this tag are now correctly processed.
Original PR description
[FIX] account_edi_ubl_cii: xml import error customization id This error happens when the user tries to import an xml invoice in accounting > customer > invoice and the CustomizationID tag is empty. The cause of this is the CustomizationID tag that exists in the file, but it's empty. This tag is mandatory in a ubl file, so we cannot process the file if it's empty. opw-5238398 Forward-Port-Of: odoo/odoo#236668
47 changes
Enhancements to existing features
This update adds a new filter to the product catalog, allowing it to display products previously purchased by a customer. This improves the customer experience by prioritizing products they've bought before, making it easier for them to find relevant items. It enhances product discovery and potentially drives sales.
Original PR description
Prior to this commit: - The product catalog did not provide a way to prioritize or filter products based on a customer’s past purchases. Post this commit: - A new filter is introduced to identify products previously bought by the selected customer, allowing the catalog to filter those products accordingly. task-5187283
This update enhances Odoo's server stability by allowing multiple gevent servers to operate simultaneously on compatible systems. It improves shutdown processes and prevents overwhelming the database connection pool, leading to more reliable performance. If a graceful shutdown fails, the servers are terminated immediately to ensure consistent operation.
Original PR description
Allow for multiple gevent servers on systems that support socket.SO_REUSEPORT, allowing multiple processes to listen on the same address. We also allow them to be shutdown gracefully by closing their socket and setting a 60s stop_timeout for ongoing requests. We terminate websocket connections in batches, to avoid flooding the new gevent server with all the new connections all at once. We do this as a factor of the maximum connection pool to the DB as this will likely be the limiting factor for the new gevent server. If the stop is not graceful we SIGKILL them immediately, same as before.
This update enhances the clarity of tax information within Odoo by moving key details to the main tax form and introducing a quick reference popover for tax tags on invoices. This improves usability and provides faster access to important tax definitions, streamlining invoice processing.
Original PR description
**PURPOSE**
- Move Tax Description to the main tax form for better visibility.
- Move Active and Tax Scope to Advanced Options.
- Allow clicking tax tags on invoices to show a simplified, read-only
Tax definition for quick reference.
**SPACIFICATION**
- Reposition Fields in Account Tax Form
1) Move the field description from the Advanced Options tab to the
main form.
2) Move the fields Active and Tax Scope from the
main tax form to the Advanced Options tab.
- Introduced a new popover, which will open when you click on the tax-tag
which is read-only and contains information on the current tax's description
and its distribution over Invoice and Credit Note.
task-5180784This update introduces the ability to define reports based on fiscal years, aligning them with your company's accounting cycles. Additionally, users can now manually set custom reporting dates within the return creation wizard, providing greater control over financial reporting. This improves reporting accuracy and caters to diverse business needs.
Original PR description
A new periodicity (fiscalyear) is added. This implied that the return will be aligned to all fiscal years including the one from the model account.fiscal.year Another improvement is that we can force custom dates on the return creation wizard for specific cases. task-5346466
This update enhances the user experience for managing bills by improving the visual clarity of form and list views. Specifically, it addresses issues with duplicate bill detection and provides a new 'delete all' button for easier management, ensuring accurate billing records.
Original PR description
This commit improves the UI of bills, and how duplicates bills are handled and detected, the following changes were made: 1- the "Drag and drop" icon size was too small, the icon size was increased 2- the outstanding debits section needed clearer information when displaying info about the other bills/transactions, dates are now always visible and hovering shows the reference 3- There was no use for the print button on a bill, it was removed 4- A bill could be a duplicate even if the reference was not set, before this commit, that behavior was not recognized, Also the displayed name for duplicate bills was not clear, making it difficult to recognize a bill just from its name 5- A delete all button (for duplicate bills) was added This commit is the first part of this task, second part targeting master task-5258726 Forward-Port-Of: odoo/odoo#243797
This update aligns the payment field widget in the Enterprise version of Odoo with the Community Edition. This ensures consistency and simplifies the process of entering payment information for invoices, improving user experience and data accuracy.
Original PR description
Added extra fields to align with the widget in CE task-5258726 Forward-Port-Of: odoo/enterprise#104300
This update streamlines the display of buttons within the bank reconciliation widget. Previously, buttons were shown on separate lines, now they consistently appear alongside the last displayed button for a cleaner and more intuitive user experience. This improves usability and reduces visual clutter.
Original PR description
This commit aims to: Avoid having the dropdown toggle on a separate line, it should always stick to the last displayed button. task-5382731 Forward-Port-Of: odoo/enterprise#103799 Forward-Port-Of: odoo/enterprise#101692
Resolved issues and error corrections
This update fixes a bug in the chatbot where invalid phone numbers were accepted, leading to inaccurate data. Now, the chatbot validates phone input, displaying an error message and preventing users from proceeding until a valid number is entered, ensuring reliable contact information.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Before this change, the chatbot phone step allowed any input, including invalid characters, leading to incorrect phone numbers and inconsistent data. **Current behavior before PR:** --------------------------------- - Phone step accepts any input - Users can proceed with invalid numbers **Desired behavior after PR is merged:** ----------------------------------------- - Phone input is validated in the chatbot - Invalid numbers show an error message: `'xxx' does not look like a valid phone number. Can you please try again?'` - Users cannot proceed until a valid number is entered **Task:** 4949441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where excessive logging was appearing in Odoo's unit tests. By hiding these logs, the tests now run more efficiently and reliably. This improves the overall stability and performance of the Odoo platform.
Original PR description
This commit hides unwanted logs in unit tests check_undeterminisms 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 an issue where valid Mexican account numbers (CLABE) were incorrectly formatted with spaces. This change ensures that payroll reports generated for Mexico comply with EDI standards, preventing errors in reporting and financial processing. The fix utilizes a sanitized account number to guarantee accurate data transmission.
Original PR description
Before this commit, an account number that is a valid CLABE would be formatted with spaces. Reporting this account number then in the mexican EDI would be wrong because it's expected to have no spaces. This commit solves this issue by reporting the sanitized_account_number instead. task-5727295
This update enhances how users manage their consent for online account synchronization. The change allows for a more flexible approach to handling consent requests, addressing a previous technical issue. This improves the user experience and ensures compliance with data privacy regulations.
Original PR description
In this commit:https://github.com/odoo/enterprise/commit/bf5b7d03fe8e138ee8bc0246d3d148638db5d620 we introduce a message on the account_online_link to be able to manage the consent. But since manage_consent is not a field of account.online.linki would traceback, we changed the position of the code by popping the value. Also changed the url to use the provider_type to be able to use the route with any provider if needed task-5187621 Forward-Port-Of: odoo/enterprise#104519 Forward-Port-Of: odoo/enterprise#102428
This update addresses several small issues within the l10n_hr_edi module, primarily focused on improving error handling and the user interface. Specifically, it enhances the process of fiscal document status checks, supports multi-company operations, and streamlines bill approval workflows. These changes ensure greater stability and usability for users.
Original PR description
- Adjusting error handling for receiving an empty response from MER for a document fiscalization status. - Adding additional checks for running multi-company-wide MER API methods. - Adjusting how approval API call is handled when confirming a bill. - Adding a tooltip about Company BU in MER settings and missing "company dependent" indicators for the credentials. Continuation of task-4925745 Related to opw-5477846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244357 Forward-Port-Of: odoo/odoo#244023
This update corrects a data issue within the Odoo Enterprise system related to Chilean SII (Service de Impuestos Internos) reporting. Specifically, the information for the 'Alto Hospicio' Regional Office and its associated Comuna (Alto Hospicio) within the Taracapá region has been added, ensuring accurate tax reporting compliance.
Original PR description
Oficina Regional Alto Hospicio Comuna Alto Hospicio Región Taracapá Forward-Port-Of: odoo/enterprise#102712
This update enhances the customer display popup in Point of Sale, making it easier to access customer information across devices. Now, both desktop and mobile users will see a QR code to scan, and desktop users will also have a button to open the customer display directly on their device. This streamlines the process of viewing customer details during transactions.
Original PR description
Changed to open the QR code popup on the desktop as well. Before it was opening directly in a new window and it was hard to open it on a separate device. The QR popup will: - on desktop: will show a button to open the customer display on the same device, or to scan the qr - on mobile: will show only the qr code to scan task-5129241 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243618 Forward-Port-Of: odoo/odoo#229478
This update removes a feature that allowed users to directly open folders from the sync configuration list. This change simplifies the process of selecting and editing configuration rows, leading to a more user-friendly experience. The removal addresses a usability issue that was causing confusion.
Original PR description
Previously, clicking a folder in the sync configuration list redirected the user to the folder view, which made it difficult to select or edit the configuration row. To improve usability, the ability to open folders directly from `documents_account.documents_folder_setting_view_list` has been removed. task-5212503 Forward-Port-Of: odoo/enterprise#103218
This update fixes an issue where numbers extracted from OCR boxes were incorrectly parsed due to language-specific decimal separator settings. The change simplifies the parsing process by consistently using a standard JavaScript `Number` parser, ensuring accurate numerical data entry within the system. This improves data integrity and reliability.
Original PR description
When using a language that doesn't use a dot as decimal separator, the number parsed from the box content was incorrect. For example, if the content of the box was "1234.56", the parsed value would have been "123456". This happened because the float parser available through the registry takes into account the language of the user and its configured thousands/decimal separators. Since the content of the boxes are always formatted as "1234.56", without thousands separator and with a dot as decimal separator, the regular `Number` parser of Javascript can be used to get consistent results. opw-[5427979](https://www.odoo.com/odoo/49/tasks/5427979) Forward-Port-Of: odoo/enterprise#104467
This update fixes an issue where cash order creation in Point of Sale was missing essential information like company and user details. Previously, orders weren't properly linked, leading to potential data discrepancies. This change ensures cash orders are created with accurate context, improving order tracking and reporting.
Original PR description
Before this commit, the order for cash moves was created without setting the session_id, company_id, and user_id fields. opw-5500966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244287
This update fixes an issue where order processing within batch picking was inconsistent. The change ensures that order lines are correctly associated with picking IDs by using the ID field instead of the field itself, resolving a technical problem related to how Odoo compares related data. This improves the reliability of batch picking operations.
Original PR description
Ordering recordset based on relationnal field should always take the relational field's `.id` instead of the field itself. This is due to the BaseModel `__gt__` override comparing if a set is included into another and not if the `id` is bigger that the other `id`. runbot : 237512 Forward-Port-Of: odoo/enterprise#104561
This update fixes a problem with the Point of Sale testing process. Previously, the tour wouldn't always complete successfully. By adding a final check to ensure at least one paid order exists, the tour now reliably finishes, guaranteeing consistent and accurate test results. This improves the quality of our Point of Sale testing.
Original PR description
By adding a last step ( that check that there is at least one paid order), we ensure that the RPC is done before closing the tour. error-runbot-id~233511 error-runbot-id~232677 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#243815
This update resolves an issue where group channels (DMs with fewer than 3 members) were causing confusing display behaviors like incorrect status indicators and missing author names. By removing a specific calculation, the system now accurately reflects the nature of group channels, providing a more reliable user experience.
Original PR description
Before this commit, the "correspondent" property of Thread would be computed for channels of type group (group DMs) having less than 3 members. This would lead to various confusing behaviours, including: 1. The "back on" banner being shown. 2. The chat bubble showing an IM status. 3. The notification item not showing the message author's name. This commit fixes the issues by not computing `correspondent` for channels of type group. task-5462395 Forward-Port-Of: odoo/odoo#243874 Forward-Port-Of: odoo/odoo#242058
This update fixes a technical issue that caused tracebacks when a member was typing in group chats with multiple users. The fix ensures that the 'ImStatus' component isn't incorrectly displayed in group chats, preventing errors and improving stability. This resolves a potential disruption for users engaging in group conversations.
Original PR description
Before this commit, when another member of a group chat with more than 2 members was typing it would result in a traceback. Steps to reproduce: 1. Have `hr_homeworking` and/or `hr_holidays` installed 2. Create group chat with 2 other users 3. Open said group chat 4. Have another member start typing -> traceback This happens because since [1] the condition to show the `ImStatus` component became `showImStatus`, which is true in group chats when another member is typing. However since group chats with more than 2 members have no correspondent, this leads to the `ImStatus` component having no `persona` attribute, which in turn causes a crashes in templates without a guard on `persona` access. This commit fixes the issue by making `showImStatus` only true in DMs, since it's not expected for group chats to have a correspondent and hence an IM status should not be shown. [1]: https://github.com/odoo/odoo/pull/234715 Forward-Port-Of: odoo/odoo#243798
This update adjusts the size of the 'looking for help' timers in live chat conversations on the discuss sidebar. The change makes the overall text content of these conversations more visually balanced, improving readability and the user experience. This is a minor cosmetic fix.
Original PR description
Timers on "looking for help" live chat conversations on discuss sidebar were slightly too big. This commit reduces the size to make the overal text content of a discuss item more balanced. Before / After <img width="296" height="100" alt="Screenshot 2026-01-16 at 16 58 50" src="https://github.com/user-attachments/assets/32d8e304-c00f-4d2f-bcb9-3b58be7f01c4" /> <img width="298" height="99" alt="Screenshot 2026-01-16 at 16 58 57" src="https://github.com/user-attachments/assets/2cc6fff7-8613-4b56-b44c-22ad72738286" /> Forward-Port-Of: odoo/odoo#244306
This update ensures that newly created General(MISC) entries in Odoo automatically have 'no follow-up' enabled. This simplifies reporting and prevents unnecessary notifications for these common transaction types, streamlining our accounting processes. It’s a small change that improves efficiency and reduces potential noise in our reporting.
Original PR description
General(MISC) entries should be no_followup by default. task-5489772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244309
This fix addresses an issue where a project was automatically created when ordering 0 units of a prepaid service product within a quotation. The change ensures that projects are only created when a valid quantity of the service is ordered, streamlining the quoting process and preventing unnecessary project creation. This resolves a potential confusion and improves data accuracy.
Original PR description
--- ## Short functional explanation of the error Let's say we have a prepaid service as a product, generating a project upon order. When we order 0 units of this product as an optional product, a project is still created. ## Reproduction Steps 1. Create a product of type Service. Set Project in the field Create On Order. Set the Invoicing Policy at Prepaid. 2. Create a quotation containing an optional product with 0 units of this service and click on confirm. ### Expected behavior The quotation is confirmed, but no project is created. ### Unexpected behavior A project linked to the product and the quotation is created. ## Origin of the issue When creating projects linked to order lines, we don't check if such projects are linked to optional products. opw-5406118 Forward-Port-Of: odoo/odoo#240608
This update corrects a bug where invoices could be incorrectly linked to DIAN documents after a rejection. When a DIAN error occurs, the system now verifies key details (customer, date, time) between Odoo and the DIAN XML to ensure accurate linking, preventing data mismatches.
Original PR description
**Steps to reproduce:** (only reproducible in production) - Install accountant and l10n_co_dian - Switch to a Colombian company (e.g. CO Company) - In Accounting settings, configure the Colombian…
**Steps to reproduce:** (only reproducible in production) - Install accountant and l10n_co_dian - Switch to a Colombian company (e.g. CO Company) - In Accounting settings, configure the Colombian localization with valid DIAN credentials - Create an invoice for a Colombian customer - Confirm the invoice - Send the invoice to DIAN - Cancel and delete the invoice - Create another invoice for another Colombian customer with the same name (sequence) than the previously deleted invoice - Confirm the invoice - Send the invoice to DIAN **Issue:** A previous fix (https://github.com/odoo/enterprise/commit/4d782030631350cfaa8f2993e68f33c9f66929e4) had been made to sync together a DIAN document from Odoo and DIAN when the following error was returned by DIAN: "Regla: 90, Rechazo: Documento procesado anteriormente." It can happen when an invoice is sent to DIAN but due to a connection issue, the DIAN response is not received and the invoice is flagged as rejected. In that case, the "Regla: 90" error is returned by DIAN when trying to send the invoice again and the fix is linking the identifier returned by the DIAN error with the invoice to prevent this issue. However, the fix wasn't taking into account the case in which the error returned by DIAN is legit and the identifier is linked to another document. It results of having an invoice that is linked to an incorrect document in DIAN. The customer, date and other info, completely different. **Solution:** When "Regla: 90" error is returned by DIAN, a check is performed to make sure that the customer, the issue date and time on the document in Odoo and on the XML from DIAN are the same before assigning the identifier from DIAN to the document in Odoo. opw-5095212 Forward-Port-Of: odoo/enterprise#99936
This update fixes an issue where tax names and invoice labels were displayed in English for Vietnamese users. By adding Vietnamese translation columns to the tax template CSV, the system now correctly displays tax labels in Vietnamese, improving the user experience for Vietnamese-speaking businesses. This ensures accurate and localized reporting for our Vietnamese clients.
Original PR description
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused…
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused tax names and invoice labels to display in English even when the user's language was set to Vietnamese. By adding the `name@vi_VN` and `invoice_label@vi_VN` columns to the tax template CSV, taxes will now display with proper Vietnamese labels when the chart of accounts is installed for Vietnamese companies, improving the user experience for Vietnamese-speaking users. Technical details: - Added `name@vi_VN` and `invoice_label@vi_VN` columns to the CSV header - Added Vietnamese translations for all tax records in the template - Translations follow Vietnamese tax terminology conventions - The chart template loader automatically processes columns with `@lang` suffix and applies them as translations for translatable fields 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#244151 Forward-Port-Of: odoo/odoo#236502
This update resolves a technical issue causing duplicate entries in the Accounts Coverage Report, specifically when using the Ireland reports. The fix ensures accurate reporting by ignoring identical report lines with the same name and code, preventing misleading results.
Original PR description
Reproduce the bug: -Install Ireland(ie) reports -Enable debug mode -Go to Reporting>Balance Sheet>Accounts Coverage Report -The generated sheet should have false positive duplicates error Fix: Ignore the report lines that has the same name and the same code task: 5373732 Forward-Port-Of: odoo/enterprise#101311
A technical issue prevented the correct installation of the l10n_be_hr_payroll module. This update resolved a conflict related to a field definition, ensuring the module functions properly when installed independently. This change improves the stability and usability of the Belgian payroll functionality.
Original PR description
A traceback about bike_id occurs when only installing l10n_be_hr_payroll. The field bike_id is in the fleet bridge of the belgian payroll. The field is already present in the _get_whitelist_fields_from_template method in that module. Removing the field from the l10n_be_hr_payroll method solves the issue. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/234856 task-5504273 Forward-Port-Of: odoo/enterprise#104612
A technical issue in the tour test was causing it to incorrectly select contacts. This update resolves the problem by ensuring the tour always uses the correct contact associated with the call being demonstrated, specifically selecting from the Recent tab instead of the Contact tab when demo data is used.
Original PR description
`call_activity_chatter_link` tour fails when test contains demo data. When contains demo data, the test select a wrong contact in Contact tab. In this commit, we change to select the first call in Recent tab to ensure this is the contact of the call we just made. Forward-Port-Of: odoo/enterprise#104687
This update resolves a problem where customers couldn't change product selections within the Point of Sale configurator. The issue stemmed from overly restrictive attribute exclusions, preventing valid combinations. The fix removes the problematic code to allow customers to freely select product options.
Original PR description
Step to reproduce: - Create 2 attributes with 2 values each A1V1 A1V2 and A2V1 A2V2 - Create a product with these attributes and set the attribute exclusion so that only 2 valid combinations are…
Step to reproduce: - Create 2 attributes with 2 values each A1V1 A1V2 and A2V1 A2V2 - Create a product with these attributes and set the attribute exclusion so that only 2 valid combinations are possible. (ex: a1v1 excludes a2v2 and a1v2 excludes a2v1) - Open PoS and try to add the product to the cart. - The configurator popup will appear. Observation: - You will not be able to change the selection because the other combinations are not correct. Cause: - The issue was already fixed [1] but issue was reintroduced in [2] Fix: - Remove the code, which was causing the issue, we shouldn't disable an option and allow customer to change the combiantion [1] https://github.com/odoo/odoo/commit/5864780ed703f61d763e1b49c33da3bbf8ca32f2 [2] https://github.com/odoo/odoo/commit/6e7c663543ba2b219d492795971f42e3e2c1213e opw-5418977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244347 Forward-Port-Of: odoo/odoo#241259
This update resolves a recurring issue where the quotation signing tour occasionally failed to complete correctly. The fix adds a deliberate pause within the tour to ensure all interactions have finished loading, resulting in a more stable and reliable experience for users. This enhances the overall usability of the sale management process.
Original PR description
This commit fixes the flaky quotation signing tour in sale_management by adding an explicit step to wait for interactions to fully load before proceeding with the next steps. runbot error-224021 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242848 Forward-Port-Of: odoo/odoo#242746
This update resolves a technical issue where the HTML editor would crash when attempting to remove formatting from a cell with a lingering color. Now, users can reliably remove colors from empty cells without encountering errors, improving the overall stability and usability of the editor.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a m x n table - Write some text in a cell, apply color on text - Delete text and keep empty colored element - Select cell - Trying to remove format throws infinite loop error in removeAllColor **Desired behavior after PR is merged:** Clicking on remove format button should remove color from empty colored element without causing traceback. task-5454993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243976 Forward-Port-Of: odoo/odoo#241829
This update fixes an issue where the POS product information popup only showed the first tax applied to a product. Now, the popup correctly displays all tax names, separated by commas, providing customers with accurate tax details. This improves transparency and ensures correct pricing calculations in the Point of Sale system.
Original PR description
Before this commit: --- - The POS product info popup displayed only the first tax from `tax_details`, which meant multiple applied taxes were not visible. - The logic fetched a single tax name instead of all tax applied to the product. After this commit: --- - The POS store sends a full list of tax names instead of a single name. - The popup template displays all tax names, comma-separated. task-5406826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244284 Forward-Port-Of: odoo/odoo#239813
This update fixes an issue where right-clicking on links within messages was obscured by extra message actions. Now, users will see the standard browser context menu options like 'Open Link' and 'Copy Link' when right-clicking on a message link, improving usability.
Original PR description
Before this commit, when right-clicking on a link in a message body, this was showing the list of message actions in dropdown. This is a problem because right-click on link has features like "Open link" / "Copy link" and so on. They were over-shadowed by the right-click on message for showing of message actions. This commit prevent the showing of message actions in dropdown from right-click in links in message body, so that the browser context menu is open instead in that scenario, showing features like "Open link" and "Copy link". Forward-Port-Of: odoo/odoo#244252
This update resolves a technical error in the Point of Sale system that prevented users from creating order names with custom prefixes. The fix ensures order names, including prefixes, can be generated correctly, preventing tracebacks and ensuring proper order functionality. This improves the reliability of the POS experience.
Original PR description
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with…
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with config number 1 active and make a purchase - A traceback appears saying that we can't convert the sequence to an Integer **Why the fix:** Having a custom prefix with letters used to work, but in version 19, we now store the sequence_number with the prefix, which can be composed of characters which can not be stored in an Integer field such as sequence_number. To prevent this error, we remove the prefix and the suffix (which has the same issue) from the sequence_number before storing it. We then add the prefix and the suffix back when computing the order's name, so that it's consistant with the prefix and the suffix the user chose. This is the way the order's name was computed before version 19.0, which saw the prefix and suffix disappear from the order's name. opw-5386575 Forward-Port-Of: odoo/odoo#239515
This update resolves a test failure that occurred when the current date was in 2027. The issue stemmed from a subscription end date set for December 31, 2026, causing a system error when processing invoices in 2027. This ensures the subscription functionality operates correctly across different years.
Original PR description
Before this commit, the test was failing if today date was in 2027. it occured because the end_date of the subscription was on the 31 of December 2026. As a result, when running in 2027, the _create_recurring_invoice method would close the order. runbot-id-237658 Forward-Port-Of: odoo/enterprise#104604
This update enhances the security of our web service connections by allowing us to securely verify server identities using certificate records. Previously, our system struggled with how to properly utilize these certificates, but this change now allows for more robust and secure communication with external services. This improves overall system reliability and security.
Original PR description
Our webservice client (`zeep`) connections lacked a way to use `certificate.certificate` models to verify the connection with server identification. This is rather complicated, since PyOpenSSL only allows filenames with their default methods. We now add the feature to pass these certificate records, load them into memory buffers, and add them to the CA store. IAP PR: odoo/iap-apps#1308 Task [link](https://www.odoo.com/odoo/project.task/5068741) task-5068741 Forward-Port-Of: odoo/odoo#244386 Forward-Port-Of: odoo/odoo#238717
This update fixes an issue where the Netherlands localization incorrectly created duplicate fiscal positions. The change removes the duplicate and properly defines the NL Domestic fiscal position, ensuring accurate VAT handling and compliance with Dutch regulations. This ensures the accounting system functions correctly for Dutch businesses.
Original PR description
Installing the Netherlands localisation creates two Domestic fiscal positions, both incorrectly configured. This commit removes the empty duplicate fiscal position and properly defines the NL Domestic fiscal position by setting the Country Group, leaving Country empty, and disabling VAT requirement. task-5489829 Forward-Port-Of: odoo/odoo#244183
This update fixes an issue where reports were displaying unit prices with incorrect decimal precision. The change removes a technical widget that was overriding the configured Decimal Accuracy settings, ensuring reports now accurately reflect product prices based on the company's currency setup. This improves the accuracy of sales reporting.
Original PR description
Steps to reproduce: 1. Install the Sale app. 2. Enable developer mode and go to Decimal Accuracy. 3. Set the "Product Price" precision to 3 digits. 4. Create a quotation and print the report. Issue:…
Steps to reproduce: 1. Install the Sale app. 2. Enable developer mode and go to Decimal Accuracy. 3. Set the "Product Price" precision to 3 digits. 4. Create a quotation and print the report. Issue: The decimal precision of the unit price is not respected in the report. Cause: The unit price field in the report uses the `monetary` widget, which ignores the Decimal Accuracy configuration and enforces currency precision instead. Solution: Remove the `monetary` widget from the unit price field in the report so that Decimal Accuracy is applied correctly. Before: <img width="570" height="97" alt="image" src="https://github.com/user-attachments/assets/dda22b25-0ade-40ae-b585-c6251ba89c89" /> After : <img width="584" height="87" alt="image" src="https://github.com/user-attachments/assets/b51d3040-e7b5-41d6-bdd9-7ec799b8005d" /> opw-5418665 Revert [PR #224219](https://github.com/odoo/odoo/pull/224219/files#diff-92dda03d204cc6ea8b7aacd0c07939843c83b1841f4a3049903844777d83c07bR201) to the original implementation so that the configured Decimal Accuracy is correctly applied in reports as other apps i.e. Purchase or Account Forward-Port-Of: odoo/odoo#241255
This update resolves a problem where Odoo incorrectly displayed a "Resume" prompt after successfully importing large CSV files in batches. The fix ensures the 'Resume' prompt disappears automatically when the import process is truly complete, improving the user experience. This prevents unnecessary prompts and streamlines the import process.
Original PR description
When importing a large file in multiple batches , Odoo incorrectly displays a "Resume" prompt at the end of the process, even though all records have been successfully imported. Steps to reproduce:…
When importing a large file in multiple batches , Odoo incorrectly displays a "Resume" prompt at the end of the process, even though all records have been successfully imported. Steps to reproduce: 1. Create a CSV file with enough records to trigger at least 2 batches 2. Go to any list view and select "Import records". 3. Upload the file and click "Import". 4. Wait for the import to complete. 5. Observe that despite an "X records successfully imported" notification, a warning "Click 'Resume' to proceed..." appears. The issue occurs because the `importRes.nextrow` state variable is updated during intermediate batches but is not cleared when the final batch completes. * In `_executeImportStep`, if `nextrow` is returned (intermediate batch), `importRes.nextrow` is updated. * If `nextrow` is falsy (final batch), the loop is stopped, but `importRes.nextrow` retains the value from the previous batch. * `executeImport` checks `importRes.nextrow` to decide whether to show the `"Resume"` message, leading to a false positive caused by the stale value. This commit fixes the issue by explicitly setting `importRes.nextrow` to `0` in `_executeImportStep` when the server indicates completion (returns a falsy `nextrow`). opw-5343837 Forward-Port-Of: odoo/odoo#241490
This update corrects inaccuracies in the Spanish balance sheet reports, specifically for Pymes and Completo versions. The fix addresses missing figures and ensures that section totals are correctly calculated, improving the reliability of financial reporting.
Original PR description
Waking up a test that check the balancedness of balance sheet, we check again the Spanish ones: pymes: - subsections were not taken into account into the sum of the section - 296/596 are specific to pymes, but it goes into the overall section - 473 was included. It is not included in documentations because it needs to be emptied at closing, but we want balanced all the time. - 5585 was missing completo: - 200/280/290: research should be expenses at closing, but in the meantime we add it to the other accounts assoc: - 178/189: to deudas a largo plazo can caracteristicas especiales Translation for deudas a largo plazo was changed. Forward-Port-Of: odoo/enterprise#97875
This update resolves an issue where demo data in the stock barcode module incorrectly packed items into existing demo packages instead of new ones. The fix ensures a unique package name is created during demo data installation, preventing this conflict and maintaining accurate inventory tracking.
Original PR description
The test `test_put_in_pack_in_new_created_package` does a simple thing: 1. We scan a product then put it in pack; 2. We scan a second package than scan the package created during previous put in pack. To be sure we scan the package created in 1., we reset the package sequence so we're sure the created package will have 'PACK0000001' as name. The issue is: when demo data are installed, a package with this name is already created, which means when we scan 'PACK0000001' in step 2., instead of packing the second line into the newly created package, we pack it into the demo data package. To avoid that, this commit sets the package's sequence to 42 so we're sure the created package will be named 'PACK0000042'. runbot-build-error: [98126575](https://runbot.odoo.com/odoo/runbot.build.error/237802) Forward-Port-Of: odoo/enterprise#104623
This update corrects a technical issue that was preventing the generation of accurate invoice reports for Mexican EDI (l10n_mx_edi) transactions. The fix prevents an error that occurred when multiple invoices with the same payment method code were processed, ensuring consistent report output.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#103460A test used to occasionally fail due to a timing issue with notification messages during inventory adjustments. This commit resolves the problem by automatically closing the success notification after the first adjustment, ensuring the subsequent adjustment runs correctly. This improves the reliability of the inventory packaging test.
Original PR description
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The…
Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert: ```python self.assertEqual(self.product1.qty_available, 15.0) ``` The error message is: `AssertionError: 16.0 != 15.0` In the tour, we do a first inventory adjustment where we set the `proquct1` qty to 16, then we do a second inventory adjustment where we set its qty to 15. Now, the assert sometime fails because in the tour, the last step check the success message is visible: ```javascript trigger: ".o_notification_bar.bg-success", ``` The issue with that is that we already do a first inventory adjstment and its success notification is still visible while processing the second inventory adjustment, creating a race condition. To fix that, we just need to close the first notification message, and to do so, this commit back-ports and uses the step utils' method `checkNotificationMessage` (see [1]) since this method checks a notification message is there and close it. [1]: https://github.com/odoo/enterprise/pull/101495 runbot-build-error: [227692](https://runbot.odoo.com/odoo/runbot.build.error/227692) Forward-Port-Of: odoo/enterprise#104614 Forward-Port-Of: odoo/enterprise#104481
This update resolves an issue where the inventory forecast view incorrectly linked to stock picking records when using manufacturing reservations. The fix ensures the correct manufacturing production record is displayed, preventing duplicate links and inaccurate reporting for products with manufacturing processes.
Original PR description
**Issue:** The forecasted inventory view assumed that line.reservation was always a `stock.picking`. In manufacturing flows, the reservation can be an `mrp.production`, which caused incorrect…
**Issue:** The forecasted inventory view assumed that line.reservation was always a `stock.picking`. In manufacturing flows, the reservation can be an `mrp.production`, which caused incorrect navigation to a `stock.picking` record. Fix this by comparing both model and id when checking if the reservation differs from the outgoing document, and by opening the reservation using its actual model. This ensures the correct document is shown and avoids duplicate or invalid links in the "Used by" column. **Steps to reproduce:** - Create a v19 db with sale,mrp,sale_stock with `--demo-true`. - Go to products -> search for 'FURN_0269' product and open form view. - open forecasted smart button for forecasted reeport. - check the used by column for mrp reservation - i.e,: `WH/MO/00001 - WH/MO/00001` appears twice. - clicking on first, opens correct record of `mrp.production` where the units is reserved. - clicking on the second, navigate to false record of `stock.picking` by taking the id of `mrp.produciton` as the reserve is having `_name: "mrp.production"` **Screenshots from UI:** - Product page: <img width="1253" height="572" alt="stock_1" src="https://github.com/user-attachments/assets/13cd7f0a-34b0-48ea-a8d5-5337cbf9f5a5" /> - Forecasted report for that product: <img width="1908" height="994" alt="stock_2" src="https://github.com/user-attachments/assets/ce0af8a3-9f37-469c-8119-36b6e7be9c4a" /> - Clicking on First `WH/MO/00001` button: <img width="1265" height="568" alt="stock_3" src="https://github.com/user-attachments/assets/a8cb8a08-5c24-45f7-ad2e-5e3987f9ee70" /> - Clicking on second `WH/MO/00001` button, navigating to incorrect `stock.picking` by taking id of `mrp.production` even though there is no picking avaiable: <img width="1264" height="519" alt="stock_4" src="https://github.com/user-attachments/assets/3a2d1613-ccbb-4994-898c-c885690c507e" /> **Final view Before and After the Fix:** - For final view, In order to check the reservation done by `stock.picking`, I have created a `sale.order` having delivery for the same product to showcase both of them are working. - **Before Fix:** <img width="1907" height="994" alt="stock_5" src="https://github.com/user-attachments/assets/4441910e-348b-4270-ab1b-db903b334c97" /> - **After Fix:** <img width="1905" height="940" alt="stock_66" src="https://github.com/user-attachments/assets/ba288e6b-b2c9-47ed-b752-233ff876fb55" /> opw-[5481220](https://www.odoo.com/odoo/70/tasks/5481220?debug=1) upg-[3804157](https://upgrade.odoo.com/odoo/upgrade.request/3804157?debug=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244222
Features or functions removed from Odoo
This pull request removes a previously identified, unused piece of code within the Odoo Enterprise VoIP module. The code was introduced but never utilized, streamlining the system and reducing potential maintenance overhead. This change improves the overall efficiency of the application.
Original PR description
The `onCountrySelectorStateChanged` method was introduced at [1] but it was already dead code at the time. [1]: https://github.com/odoo/enterprise/commit/708aea78760392207f9148c31c67212dacaf3294 Related to task-5366961
This update removes unnecessary code related to barcode functionality. Previously, a check for a dataset was included as a leftover from a recent update. This cleanup improves the efficiency of the barcode system without impacting its core functionality. It's a minor technical adjustment.
Original PR description
This code was introduced in [1] with the new views but part of the code was legacy and was removed in [2]. We can safely remove this leftover line. [1]: https://github.com/odoo/odoo/commit/920df597d3d7174723736a395e94dc8ff413c70b [2]: https://github.com/odoo/odoo/commit/49297bc7bba75541ca139e6c84e0d3b311765145 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
12 changes
New functionality added to Odoo
This update introduces a new system for modifying website design elements, specifically shapes within images and backgrounds. It allows plugins to directly adjust these elements, providing greater control and customization options for website builders. This improves the ability to tailor website designs to specific business needs.
Original PR description
This commit defines `image_shape_groups_providers` and `background_shape_groups_providers` as new plugin resources. These resources return functions that receive the current shape groups, allowing plugins to mutate them directly or return groups to be merged into the final configuration.
Resolved issues and error corrections
This update fixes an issue where Odoo was creating duplicate vendor contacts due to differences in how VAT numbers were formatted. Now, Odoo correctly identifies and merges contacts even when VAT numbers have or don't have dots, ensuring accurate record-keeping for vendor bills. This improves data consistency and simplifies reporting.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing Spanish reports from correctly displaying translations. The previous method of executing translations within the Markup frame resulted in a lack of necessary context and data, failing to retrieve the correct language. By changing the translation process, the reports now display accurate Spanish translations.
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
This update corrects a bug where free product rewards in the loyalty program were incorrectly displaying 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. This fix ensures accurate pricing for free loyalty rewards.
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
This update fixes a critical issue with how strings are processed in the Odoo web framework, specifically related to template substitution. The changes improve accuracy and consistency, and streamline translation management for better flexibility and maintainability.
Original PR description
### [[FIX] web: cleanup string-related utils](https://github.com/odoo/odoo/pull/241068/changes) This commit cleans up several utility files relating to string-parsing and translations. Main changes…
### [[FIX] web: cleanup string-related utils](https://github.com/odoo/odoo/pull/241068/changes) This commit cleans up several utility files relating to string-parsing and translations. Main changes are: - fixed `sprintf` and related functions: before this commmit, string substitutions were incorrectly inserted in the template string, and it was actually reflected in a test (template : `"<p>%s</p>%s"` => test incorrectly asserted that both strings were inserted in the first "%s" and "undefined" was inserted in the second); - to replicate the Python homonymous behaviour: "%s" characters can now be escaped in "sprintf-ed" strings by adding an additional "%" sign before the expression; - unification of translations via a TranslatedString class (which will also simplify external overrides); - unified API for some utility functions sharing the same purpose (typically: accepting an iterable instead of a list, etc.); - filling missing docstring, re-ordering functions and constants for clarity; - added "headless" tag to some utility functions' tests, when UI is not needed. --- 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 l10n_mx_edi module was encountering a 'singleton error' when generating invoices with similar payment information. The fix ensures that the system correctly handles multiple invoices using the same payment method, improving invoice generation stability. This prevents errors and ensures accurate invoice creation.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#103460This update resolves a minor issue within the email invite tour process. Previously, the tour's speed caused conflicts with the automatic opening of the channel member list. This fix ensures the tour waits for the member list to open, preventing a rare but disruptive behavior. This improves the overall user experience for inviting new members to channels.
Original PR description
The `test_01_invite_by_email_flow` test ensures we can invite partners to a channel using their email. The tour opens the invitation panel, then sends an email. However, it conflicts with the auto-open of the member list. Sometimes, the member list opens after clicking on the invite panel button. This only occurs because the tour runs very fast. It's very unlikely that this occurs to a real user. This commit fixes the tour in order to wait for the member list to open initially. runbot-237994 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 fixes a performance issue in the translation sidebar. By preloading translated elements, the sidebar now renders fully before tests begin, preventing delays and ensuring tests pass consistently. This improves the reliability of our translation testing process.
Original PR description
When opening the sidebar in translation mode, translated elements must be preloaded before the sidebar renders. Without preloading, the fetch requires an extra tick to complete, causing tests that immediately check sidebar content to fail because the sidebar isn't fully open yet. runbot-237540 Forward-Port-Of: odoo/odoo#242490
This update resolves an error preventing branch companies from registering for Peppol. The change allows users to send from the parent company when Peppol is activated in both the main and branch companies. This ensures proper Peppol registration functionality for branch operations.
Original PR description
1. Activate Peppol in the main company for both sending and receiving; 2. Create a branch company; 3. Activate Peppol in the branch and select "Send from parent company"; => Error message: "Cannot register a user with a receiver application". opw-5725278 --- 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 kiosk system wasn't correctly receiving payment information from IoT payment terminals in version 19.0. The fix ensures the kiosk retrieves payment responses from the correct 'result' key within the terminal's data, improving the reliability of the self-order kiosk payment process.
Original PR description
In v19.0, IoT Boxes respond with a dict containing a `result` key holding the actual response of the action. The kiosk couldn't get the terminal answer as it was reading directly in the response dict, instead of its `result` key.
This update prevents unnecessary WebRTC testing when the IoT Box record is a stable version, which doesn't support this feature. This avoids a potential performance issue and ensures the 'Test' button functions correctly for the intended use case. It's a minor fix improving the user experience.
Original PR description
We now avoid testing WebRTC when pressing "Test" button on the IoT Box record, when the IoT Box is a stable IoT Box (which does not support it). Task: 5490291
This update resolves a technical issue that was preventing embedded actions from functioning correctly in our web interface. The fix involved adjusting a test to accurately simulate user interaction and ensure the action is correctly triggered. This improves the reliability of embedded actions for users.
Original PR description
In this commit, we fix an embedded action test that failed because when clicking on the sliders to show the top bar, the dropdown was directly opened as there is only one visible action (since this commit: https://github.com/odoo/odoo/pull/208005/commits/a5709e870e033b83d50a2f581c81cceb2a98d91b). We then adapt the test to wait for the dropdown to open automatically, and then when it's the case, create the new custom embedded action. runbot error~237752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
4 changes
Enhancements to existing features
This change updates the source of lead mining data within Odoo from Clearbit to Dun & Bradstreet. This aligns with existing data usage for partner autocomplete and ensures we're leveraging a reliable provider for improved lead insights. This update is part of a larger IAP migration.
Original PR description
Before this commit: - Lead mining data was fetched from `clearbit` provider on IAP which is now going to be removed for discovery service After this Commit: - Data will now be fetched from `dun_and_bradstreet` provider on IAP which we are already using for the `partner_autocomplete` IAP PR: https://github.com/odoo/iap-apps/pull/1274 task-4873238 Forward-Port-Of: odoo/odoo#235521
Resolved issues and error corrections
This update corrects a limitation in how Odoo updates electronic invoices for Mexico (l10n_mx_edi). Previously, updates were limited, leading to inaccurate tracking. Now, the system is forced to update the document's write date, ensuring accurate record-keeping and compliance.
Original PR description
Before the commit 8b118a7, the search of the documents to update has been limited and ordered. With the actual domain the records to update will be most of the time the same because is not being updated. To fix this issue we force to update it. OPW-5368047
This update resolves an issue that occurred when users attempted to 'Show', 'Force CFDI', or 'Retry' actions on MX electronic invoices. The problem stemmed from a payment being deleted or cancelled, leading to an error. This fix ensures a smoother process for generating and submitting CFDI invoices.
Original PR description
When user is clicking any of the `Show`, `Force CFDI`, or `Retry` buttons in l10n_mx_edi.document error occurs. Steps to reproduce: - Install `l10n_mx_edi` module > Switch to `MX Company` - Setup `MX Electronic invoicing` in settings - Create a New Invoice > Send > Select `CFDI` > `Pay` > `Update Payments` - Payment > Cancel that Payment > Back to Invoice > CFDI(Notebook page) > Click on `Show` or `Force CFDI` or `Retry` Traceback: `ValueError: Expected singleton: account.move()` This error occurs when a payment is created and later deleted or cancelled, which results in an empty `move_id` in l10n_mx_edi.document. sentry-7113267386
This update resolves an issue where the l10n_mx_edi module was encountering a 'singleton error' when generating invoices with similar payment information. The fix ensures that the system correctly handles multiple invoices sharing the same payment details, preventing errors and improving invoice generation reliability. This ensures consistent invoice creation for users.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#1034606 changes
Enhancements to existing features
This update adds support for the recently implemented 11% and 21% VAT rates in Romania. The changes ensure that Odoo correctly calculates and manages these new tax rates within fiscal positions, aligning with updated Romanian VAT regulations.
Original PR description
The new 11% and 21% taxes introduced with the updated Romanian VAT law were added with this commit https://github.com/odoo/odoo/commit/2026212d0f7ffc217be3c6a2ff2abe5288c18afb , but some tax mappings were missing. This commit completes the setup by adding the required tax mappings, ensuring the new rates work correctly with fiscal positions. task-5480159
Resolved issues and error corrections
A test was failing in the website sale module due to a sale order not requiring payment. This update forces the sale order to always require a payment, resolving the test failure and ensuring consistent functionality. This ensures the website sale process functions correctly.
Original PR description
version: 17.0+e Why ? --------------- test_payment_provider_visibility_with_portal didn't pass on runbot because the sale order used doesn't reqire payment. The fix --------------- Force the sale order to require a payment. runbot-237786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a discrepancy in how holiday allocations are calculated when employees have different working schedules. Previously, the system produced inconsistent hour counts for related allocations. The fix ensures that all child allocations accurately reflect the total hours defined in the parent allocation, improving allocation accuracy and reporting.
Original PR description
### Steps to reproduce: - Create two employees with two different working schedule - Create a multi employee allocation for the created employees with 40 hours - Validate the allocation you created - Notice the number of hours is differenc between the two allocations ### Cause: When validating the multi employee allocation and while creating the children allocations we compute the number_of_hours_display and since we calculate it with number of days * hours per day it will result into two different values for the number of hours as the hours per day is different for each working schedule. ### Fix: To fix this we check if the allocation is an hourly one we change the number of days depending on the number of hours that we already got from the parent allocation. So when computing the number of hours for the children allocations we get the same value opw-5232797
This update resolves an issue where the UBL export incorrectly interpreted VAT information represented with a forward slash ('/'). The change ensures that VAT is properly handled when a partner doesn't have VAT, and the CompanyID field is correctly required in those cases, aligning with PEPPOL standards. This improves the accuracy of electronic invoices.
Original PR description
To signify that you know a partner does not have vat, we advise using '/'. But we should take care of that in the UBL export, to not consider it a real vat Also, in the cases where we don't have the vat, the CompanyID is supposed to be mandatory. https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-TaxRepresentativeParty/cac-PartyTaxScheme/ So, remove the whole PartyTaxScheme if vat is not present. Zatca does not override that rule (except enforcing that seller must have vat, which raises a constraint), so we modify the tests for the simplified documents. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an error in the Swiss VAT reporting (figures 382a and 383a) for transactions with foreign vendors using reverse charge. The fix ensures accurate VAT calculations by correctly handling negative tax rates associated with reverse charges, preventing negative report figures.
Original PR description
**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or *…
**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or * **7.7% R C** (figure **382a**). * Confirm the vendor bill. * Go to **Accounting → Reporting → Tax Report**. * Generate the VAT report for the relevant period. **Observed behavior:** * Figure **383a** (8.1% reverse charge) is reported as **negative**. * Figure **382a** (7.7% reverse charge) is reported as **negative**. * This results in incorrect VAT reporting. **Cause:** * Reverse charge taxes use **negative tax rates** to model the reverse mechanism. * The base amounts were tagged with **positive** signs, leading to negative values in the report. **Fix:** * Invert the base tax tag signs for reverse charge taxes: * **382a**: change base tag from `-382a` to `+382a`. * **383a**: change base tag from `-383a` to `+383a`. * Reverse charge base amounts now appear as **positive** values in the VAT report. opw-5257445
This update resolves an issue that prevented users from correctly selecting a company after it had been unarchived. The problem stemmed from a timing conflict in the system's data processing, which caused incorrect company access permissions. This change ensures a smoother and more reliable unarchiving process.
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