Daily updates from Odoo
Wednesday, June 17, 2026
14 changes · 18.0
New functionality added to Odoo
This update adds new invoice types specifically for Jordan's export regulations, including 'transit,' 'foreign trade,' and 'free zone transfer.' The system now ensures these types are only accessible to registered Jordanian taxpayers, aligning with local tax requirements. This improves compliance and streamlines export invoicing processes.
Original PR description
Extend l10n_jo_edi_invoice_type with JoFotara scope codes (3-5): transit (3), foreign trade (4), and free zone transfer (5). Validate that scope codes 3-5 are only available to registered taxpayers. task-4769255 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268839
Resolved issues and error corrections
This update enhances the stability of the French PDP (Point of Departure) registration process. The code was refactored to move a key function to the company record, addressing a previous issue where the registration model was frequently deleted. This ensures a reliable and consistent registration process.
Original PR description
The aim of this commit is to move _get_iap_url on res.company model instead of pdp.regitration. This move is made for 2 reasons: 1. PDP registration is a transient model which means that the object could be deleted in the time. 2. PDP registration implementation was using the model (api.model) and the record (self.edi_mode) which is a bad implementation. So by moving this function on company, we ensure that we always have a record to call the function and then the function is no longer an api.model. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents errors when generating e-Waybills when the dispatch and delivery locations share the same pin code. Previously, the system couldn't automatically calculate the distance in these cases, leading to incomplete requests. This change ensures a distance is always provided, improving e-Waybill generation reliability.
Original PR description
Prevent sending incomplete e-Waybill requests to the GSP server when the dispatch and delivery pincodes are identical. In such cases, the distance cannot be automatically determined and must be provided explicitly. This commit adds a validation to ensure a distance is set before generating the e-Waybill, avoiding incomplete requests and subsequent server-side errors. task-6234343 Forward-Port-Of: odoo/odoo#270155 Forward-Port-Of: odoo/odoo#268497
This update resolves an issue preventing users with appropriate Sale access from inserting data into Quotation templates through the spreadsheet management feature. The change adds a setting to ensure the necessary flag is activated when the module is installed and the user has the correct permissions, streamlining the process.
Original PR description
Current behavior before PR: - The `can_insert_in_spreadsheet` session flag was not set by the spreadsheet_sale_management module. - Users with proper Sale access rights still could not insert into Quotation templates. Desired behavior after PR is merged: - Added logic to set `can_insert_in_spreadsheet` when the module is installed and the user has the required access rights. Task: [5960761](https://www.odoo.com/odoo/project/2328/tasks/5960761)
This update addresses a bug fix within the Odoo spreadsheet component. Specifically, it resolves an issue with finding and replacing text selections after cell updates, ensuring data integrity within spreadsheets. This change improves the reliability of spreadsheet functionality.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/18d4601b09 [REL] 18.0.71 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e4e0c90ddc [FIX] Find and replace : selection after an UPDATE_CELL [Task: 4818132](https://www.odoo.com/odoo/2328/tasks/4818132) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
A recent update to our Weblate translation system unexpectedly reverted some code changes. This pull request corrects this issue by restoring the original code. This ensures that future translation updates don't unintentionally disrupt existing functionality.
Original PR description
The regular Weblate translation update reverted some code changes. This should normally not happen. We're reverting it back to the previous state. This partially reverts commit 6cce5fdde972634cdceb4ff573c0f9b67297cd1f.
This update corrects a visual bug where the 'jump to present' button appeared incorrectly when the chat window was hidden behind a long form. The fix ensures the button is only visible when the thread itself is visible, preventing a confusing flicker and ensuring the button functions as intended.
Original PR description
### Description `Thread.updateShowJumpPresent()` (`addons/mail/static/src/core/common/thread.js`) sets `showJumpPresent` from the present-sentinel visibility only, without checking that the thread…
### Description
`Thread.updateShowJumpPresent()` (`addons/mail/static/src/core/common/thread.js`) sets `showJumpPresent` from the present-sentinel visibility only, without checking that the thread itself is on screen:
```js
this.state.showJumpPresent =
this.props.thread.loadNewer || this.presentThresholdState.isVisible === false;
```
In a form chatter, when the user is at the **top of a long form**, the whole chatter is below the fold. The present sentinel is therefore not visible, so the `position-fixed` jump-to-present button shows up even though the thread is off-screen — and clicking it does nothing useful (the scrollbar flickers, no jump).
### Fix
Gate `showJumpPresent` on the thread's own visibility (`this.visibleState`), exactly as on **saas-18.3+/19.0/master**. The 18.0 port of the jump-to-present rework (460d066817, #246299) brought the threshold/position changes but dropped this guard, so 18.0 (and saas-18.2) are still affected.
### Steps to reproduce (standard, runbot)
1. Open a record with a chatter and a long form (e.g. a CRM lead / Sales order).
2. Scroll to the **top** of the form (chatter below the fold).
3. The round jump-to-present button appears at the bottom; clicking it does nothing.
With this patch the button is hidden while the thread is off-screen, matching saas-18.3+.
<img width="5152" height="1926" alt="84359" src="https://github.com/user-attachments/assets/a16dbb74-c5c4-440a-8a94-ec7c5693904e" />This update resolves a problem where the automated tour for restaurant order placement would sometimes fail due to asynchronous communication with the kitchen. By adding a brief delay, the tour now ensures all order requests are fully processed before proceeding, preventing duplicate requests and improving the reliability of the test.
Original PR description
The tour could fail because `sendOrderInPreparationUpdateLastChange` is asynchronous when sending the order to the kitchen. The test was continuing to the next steps before the request was fully resolved, which could lead to sending the order again while the previous call was still in progress. This commit updates the tour to explicitly wait for the async call to complete before continuing, by adding a delay step after clicking the order button. This prevents race conditions during the test. --- Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/181846 Forward-Port-Of: odoo/enterprise#110909
This update corrects a bug in the Outlook calendar synchronization process. Previously, events could include the same attendee multiple times due to a missing check for existing attendees. This fix ensures accurate attendee lists are synchronized, preventing potential confusion and improving the reliability of event scheduling.
Original PR description
In the Outlook calendar sync, it's possible to have the same attendee twice. That's because the normalized email wasn't used to check for preexisting attendee. To reproduce, sync event with the organizer, also an attendee, using high case in the email such as: ORGANIZER: Mike@organizer.com ATTENDEE: Mike@organizer.com ATTENDEE: John@attendee.com opw-6186606 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an access error that occurred when creating RFQ approval requests with supplier pricelists where some vendors were inaccessible to the user. The fix ensures that the system correctly handles scenarios with multiple vendors, preventing errors related to accessing vendor information.
Original PR description
**Issue** Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request. **Steps to reproduce** - Have two…
**Issue** Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request. **Steps to reproduce** - Have two companies A and B and two users u1 and u2 - user u2 only have access to company A - With user u1: - Create two vendors v1 and v2 without any company assigned - Create vendor pricelists for a product for each vendor and assign the company A to the pricelist - Add the company B for the vendor v2 - With user u2: - Open approval application - Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected) - Save it -> An access error is thrown **Cause** Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 Which filtered the right seller https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 By preparing the sellers: https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers: https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`. opw-6203910
This update resolves an issue where creating approval requests could trigger access errors when using suppliers with inaccessible vendors. The fix ensures that the system correctly handles vendor access restrictions, preventing errors during the approval process. This improves the reliability of the approval workflow.
Original PR description
**Issue** Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request. **Steps to reproduce** - Have two…
**Issue** Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request. **Steps to reproduce** - Have two companies A and B and two users u1 and u2 - user u2 only have access to company A - With user u1: - Create two vendors v1 and v2 without any company assigned - Create vendor pricelists for a product for each vendor and assign the company A to the pricelist - Add the company B for the vendor v2 - With user u2: - Open approval application - Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected) - Save it -> An access error is thrown **Cause** Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 Which filtered the right seller https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 By preparing the sellers: https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers: https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`. opw-6203910
This update resolves an issue where Odoo could incorrectly process direct debit mandates for partner banks. The change adds a constraint to ensure the correct bank is associated with the mandate, improving the reliability and accuracy of direct debit transactions. This ensures compliance and prevents potential payment errors.
This update fixes an issue where the CFDI payment rate was incorrectly displayed when payments were made in foreign currencies (like USD). The fix ensures the correct payment amount and rate are shown on the generated CFDI documents, improving accuracy for Mexican tax reporting. This resolves a discrepancy between the payment and invoice amounts.
Original PR description
The rate and payment amount shown on the CFDI document generated after updating payments was wrong when the payment was made in a foreign currency. Steps to reproduce: ------------------- * Create a journal that use USD as currency and set the rate to 20 MXN for 1 USD * Create an invoice in MXN and make sure it is set to PPD * Add any product to the invoice for 300$ and post it * Send the invoice to CFDI (a first document should be generated) * Create a payment of 15 USD in the new journal and reconcile it with the invoice * Go back to the invoice and click on "Update payments" to generate the second CFDI document > Observation: The payment document shows an amount of 300 USD with a rate of 1 instead of 15 USD with a rate of 20. Why the fix: ------------ We make sure to use the amount from the statement line when there is one. opw-5974519
Miscellaneous changes
This pull request completes the final translation updates for Odoo 18.0, ensuring all user-facing strings are accurately translated across multiple languages. This improves the overall user experience and supports our global customer base. The changes are focused on polishing and finalizing the translation process.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr