Daily updates from Odoo
Wednesday, July 16, 2025
9 changes · 18.0
New functionality added to Odoo
Adds Uruguay-specific ecommerce support so customers can provide required local identification details during checkout and on their account page. It also makes DNI the default identification type for Peruvian addresses, helping reduce checkout friction and improve local compliance.
Original PR description
This commit add Ecommerce related bridge module for Uruguay country to add Uruguay related field in address checkout form and `my/account` page. Also set DNI as default `ID type` for peru address. task-4404637 upgrade PR - https://github.com/odoo/upgrade/pull/7930 Forward-Port-Of: odoo/odoo#195198
Resolved issues and error corrections
This change ensures Odoo respects the setting that prevents missing standard records from being recreated during accounting setup or upgrades. It helps avoid upgrade failures and incomplete tax group records with missing account information, especially in localization scenarios such as Pakistan.
Original PR description
**Description** - The `force_create` attribute was added to `try_loading` in odoo/odoo@a3c57b4f0198236b04486d336d56b25de74677b8 allowing control over whether missing standard records should be…
**Description** - The `force_create` attribute was added to `try_loading` in odoo/odoo@a3c57b4f0198236b04486d336d56b25de74677b8 allowing control over whether missing standard records should be created. However, this wasn't respected for `account.tax.group`. As a result, tax groups could still be created even when `force_create=False`, leading to null values in accounts fields like `tax_payable_account_id` and `tax_receivable_account_id`. **The issue which prompted this patch:** - A recent patch in upgrade: odoo/upgrade@d2d16a2321abb525fe3fe2c403f89009f51c1394 This patch was made to update the `reconcile` and `non_trade` flags on standard accounts due to recent changes across localizations. During the upgrade, we overrode the `write` method of `account.tax.group` to conditionally update these flags. However, in a client’s database, `account.tax.group` records were missing for the `l10n_pk` module, while the standard account records were present. When `try_loading` was triggered at the end, it attempted to `create` the missing tax groups. But since the create method is called during creation and does not include the conditional update logic for `reconcile` and `non_trade` the upgrade failed with the same error that the original patch aimed to resolve. - To avoid such errors and prevent tax groups from being created with null account fields when `force_create=False`, this patch ensures `force_create` is respected for `account.tax.group`. **Steps to reproduce:** - Create a `v17` DB and install `l10n_pk` - Delete the standard tax groups - Upgrade to `v18` OPW-4915394 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where point of sale sessions with a payment difference could generate incorrect accounting entries. Payment amounts now remain accurate, helping businesses keep reliable sales and reconciliation records.
Original PR description
When a payment difference was created in the PoS, it was introducing errors in the accounting entries. Steps to reproduce: ------------------- * Make sure bank payment method has an outstanding account * Open PoS and make a sale paid by bank for 100$ * Close the session and introduce a payment difference of -10$ * Check the accounting entries created for the PoS session > Observation: The difference is correctly recorded but the payment appears as a payment of 80$ instead of 90$. Why the fix: ------------ We revert this fix (https://github.com/odoo/odoo/pull/196253) that was wrongly modifying the payment amount to fix the session report. opw-4723227
This fixes a calendar issue where privacy-related filtering could use the wrong kind of internal data, causing event visibility rules to break in some cases. Calendar privacy checks now receive the expected list of users, helping ensure events are shown or hidden correctly.
Original PR description
Using `_search()` was returning a query object, which broke the domain logic when checking `user_id.res_users_settings_id`. Replaced with `search(...).ids` to ensure a proper list of IDs is passed. `_get_default_privacy_domain` timing: before is always the same since it doesn't execute the sql query | Number of users | Before PR | After PR | |:------------------:|:-----------:|:--------:| | 10k | 0.1 ms | 8 ms | | 30k | 0.1 ms | 14 ms | | 50k | 0.1 ms | 20 ms | | 70k | 0.1 ms | 28 ms | | 90k | 0.1 ms | 35 ms | opw-4841266 bug introduced in:[#5f55544][1] [1]:https://github.com/odoo/odoo/commit/5f5554460c61d3e715e71dd7c946b77083411ae7
Survey questions that require a numerical answer now properly reject text or incomplete number entries across browsers. This prevents invalid responses from being mistakenly treated as skipped questions, improving answer accuracy and respondent guidance.
Original PR description
_______________________________________ ## Short functional explanation of the error On a survey, when answering a question that requires only a numerical answer, there's a different behavior…
_______________________________________ ## Short functional explanation of the error On a survey, when answering a question that requires only a numerical answer, there's a different behavior observed based on the navigator used: 1. On chrome, characters other than numerical characters are rejected, except 'e' (for scientific notation). This causes a problem if the answer simply consists of 'e' and not an actual scientific number. 2. On firefox, every character is accepted. This causes the answer to be set as "skipped" instead of registering a result. ## Reproduction Steps 1. Go to the survey module. 2. Click on new. Add a title, Click on the 'survey' radio button and add a question. 3. Set a title and the type of the question to Numerical value. 4. Click on share and copy the link obtained. 5. Open a new incognito window and paste the link in it. 6. Start the survey and, if you're on chrome, enter 'e'; if you're on firefox, enter anything except a normal number. Then, hit submit. ### Expected behavior The answer shouldn't be submitted, and a red message saying "This is not a number" should appear. ### Unexpected behavior The answer is accepted, and when reviewing your answers, you'll see that the question has been skipped. ## Origin of the issue In the corresponding XML, the input type has been set to numerical. However, in that case, Chrome sets restrictions for writable characters but still accepts the 'e' character for scientific notations. However, if only the 'e' character is entered, when clicking on submit, nothing is sent as an answer. On Firefox, the issue is similar: nothing is sent except if the answer is a well formatted number, but there are no restrictions on what users can enter. As nothing is sent, the answer is considered as skipped. Note: if you setup the question as mandatory, only entering 'e' on Chrome or random characters on firefox will trigger the error message 'This question requires an answer.' _________________________________________ opw-4883341 --- --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
IoT boxes now keep their existing drivers when a driver download fails or returns an invalid file. This prevents devices from losing working handlers when the connected database is unavailable, improving reliability for IoT operations.
Original PR description
Before this commit, if the IoT box was connected a DB which then went offline (e.g. expired runbot), and it tried to download drivers, the request would fail but it would still delete the old handlers. After this commit, we avoid this problem in two ways. Firstly, we check that we received an OK HTTP status before trying to process the response body. Secondly, we check that the reponse we have received is a valid zip file BEFORE deleting the old handlers. This way we only delete them if we are sure we have something to replace them with. task-4933638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218163
Mercado Pago payments that return a processing status are now treated as still in progress rather than failed. This prevents unnecessary “unknown payment status” errors at the point of sale and lets the normal retry flow continue until the payment is confirmed.
Original PR description
The Mercado Pago 'PROCESSING' payment status was not handled. As a result, when receiving this status, the payment was treated as failed and the user saw an 'Unknown payment status' message. This fix treats 'PROCESSING' as an in-progress state, just like 'OPEN' and 'ON_TERMINAL'. It triggers the same retry mechanism. opw-4918455 Forward-Port-Of: odoo/odoo#218990
Vendor bills using the Saudi 15% reverse charge tax now create the expected reverse charge accounting entry. This ensures the tax amount is reflected in the correct account and appears properly on the VAT filing report.
Original PR description
Steps to reproduce: - With a SA Company setup - Create a Vendor Bill - Add a Service product and apply 15% R C tax - Confirm Issue: The reverse charge account is not hit by the tax amount, no reverse charge entry is created and it does not show on the VAT filling report opw-4755993 Forward-Port-Of: odoo/odoo#218897 Forward-Port-Of: odoo/odoo#217384
This fix prevents appointment pages from breaking after users add slideshow content to an appointment description with the website editor. It keeps the page editable and allows richer description content such as forms or slideshow navigation controls.
Original PR description
Scenario: - in 18.0, insert a slideshow in the appointment.type().message_intro with the website editor - reload the page Result: a traceback is shown, the page becomes not editable Cause: the appointment.type().message_intro field is sanitize_form=True which removes the button used to navigate in the slideshow, this itself causes a JS error (that expects to have the buttons). Fix: several fixes are being investigated, one of which is allowing button even if sanitize_form=False is set, but meanwhile the issue is still happening for that particular case. This PR proposes to allow form tags in the field message_intro so people could add form in it or not have an error when inserting a slideshow. opw-4844700 __PR note:__ a general solution is proposed in `https://github.com/odoo/odoo/pull/215445` but it's not sure when and if it will be merged, so this PR proposes just handling the particular case of this ticket.