Tuesday, October 7, 2025
16 changes · saas-18.4
Enhancements to existing features
Bank reconciliation now creates the accounting entry as soon as an XML file is uploaded. This lets the imported transaction details be linked directly to the bank statement line, making reconciliation smoother and more complete.
Original PR description
When uploading a xml from the bank rec widget, the move will be created directly so we can put the move lines in the bank statement line. task-5107112 Forward-Port-Of: odoo/enterprise#95345
Resolved issues and error corrections
This fix prevents the HTML editor from getting stuck and showing an error when users remove formatting from colored table cells. It makes table color handling more consistent, so formatting can be cleared safely without interrupting editing work.
Original PR description
Problem: When having a `table` with `color` and selecting a cell to remove format, we get a traceback: "Infinite Loop in removeAllColor()." Cause: The color is applied on `table`, but we only process `td` for color removal. As the color remains on `table`, each attempt to remove it keeps reapplying, leading to an infinite loop. Solution: When removing color, also remove it from the `table`. Then apply the color to all child `td`. This ensures `td` colors are later removed automatically if selected, avoiding the loop. Steps to reproduce: 1. Add a `color` property to a `table` and `td`. 2. Select the `td`. 3. Click "remove format" from the toolbar. 4. Observe traceback. opw-5112088 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229878
Live chat visitors are now prevented from starting calls or inviting additional guests from chat threads. This keeps visitor capabilities aligned with intended support workflows and reduces unwanted or confusing actions during live chat sessions.
Original PR description
This commit removes the possibility for live chat visitors to start a call and invite guests. task-4849019 Forward-Port-Of: odoo/odoo#229796 Forward-Port-Of: odoo/odoo#228531
Reordering rules now calculate purchase quantities correctly when product packaging uses multiples that create repeating decimals. This prevents Odoo from generating purchase orders with slightly inflated quantities, such as 1.02 instead of 1, helping keep purchasing accurate.
Original PR description
**Steps to reproduce:** - enable "units of measure & packagings" settings - navigate to "units and packagings" and create a new one called "pack of 2" - set a quantity of 2 and the reference unit as…
**Steps to reproduce:** - enable "units of measure & packagings" settings - navigate to "units and packagings" and create a new one called "pack of 2" - set a quantity of 2 and the reference unit as "units" - create a new storable product - next to "sale price" change the unit to "pack of 6" - in the sales tab add "pack of 2" in the packagings - in the purchase tab add a vendor - click on the reordering rule smart button and create a new one - set the min and max to 0 and set the replenishment multiple to "pack of 2" (you might have to make this column visible using the filters) - create and confirm a quotation for 1 pack of 6 **Current behavior:** a new Purchase Order is created for a quantity of 1.02 **Expected behavior:** it should be a quantity of 1 **Cause of the issue:** qty_multiple is rounded (in _compute_quantity) before the computation of remainder. https://github.com/odoo/odoo/blob/7a0a246016d50ae80e49f3502a97e82d414ab0b0/addons/stock/models/stock_orderpoint.py#L373-L376 In cases of repeating decimal numbers (like 0.3333333 in our example), this leads to the remainder not being 0 even though it should be 0. opw-5040144 Forward-Port-Of: odoo/odoo#228014
This fix keeps a cashier’s manually selected tax setup when validating a Spanish point-of-sale order. It prevents incorrect tax amounts from appearing as change on receipts, improving accuracy for shops using Spanish simplified invoicing.
Original PR description
Currently, when you use a default fiscal position in the pos, if you switch to no fiscal position, upon order validation the tax amount is counted as change. Steps to reproduce: ------------------- *…
Currently, when you use a default fiscal position in the pos, if you switch to no fiscal position, upon order validation the tax amount is counted as change. Steps to reproduce: ------------------- * Install l10n_es_pos, switch to es company * In the config of a shop, use fiscal position, set some as available, one as default * Open shop session * Add a product that has taxes * Switch fiscal position to one that has 0% taxes * There should not be taxes in the cart at this point * Go to pay the order (cash or bank) > Observation: On the receipt the previous tax value is counted as change Why the fix: ------------ The issue happens because of the simplified invoice mechanism present in the ES localization. When you validate an order and that order can apply for simplified invoice, if there is no customer on the order the partner is set with the simplified partner. When setting a partner on the order we update the fiscal position and pricelist. https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/point_of_sale/static/src/app/models/pos_order.js#L929 The fiscal position is updated with the partner's fiscal position or the default one if none on the partner. https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/point_of_sale/static/src/app/models/pos_order.js#L986-L995 Instead of the fallback on the default fiscal position in the case it is not set on a partner we fallback on the order current fiscal position. If it is different than the default one is means that it was changed intentionally and there's a high chance we want to keep it, otherwise it will already be the default fp. opw-5051231 Forward-Port-Of: odoo/odoo#229237
Self-order customers will no longer see or select time slots that have already reached their allowed capacity. This prevents overbooking and fixes time zone handling so availability is calculated against the correct slot time.
Original PR description
**Steps to reproduce:** - Have a preset that requires time slots - Make the slots_per_interval 1 and the interval_time long enough - Go to the self order, make a purchase and select a slot - Make…
**Steps to reproduce:** - Have a preset that requires time slots - Make the slots_per_interval 1 and the interval_time long enough - Go to the self order, make a purchase and select a slot - Make another purchase - The slot we chose before is still showing and available **Why the fix:** Once the capacity of a time slot has been reached, we should not allow customer to chose it. This behavior occured for 2 reasons: - In the xml file where we declare this select, we did not take the fact that a slot could be full into account, leading to it always being showed. This is now done using the isFull attribute, like it is done in the regular PoS. - This same isFull was not correctly set, as there was a mismatch in slots timezone and format. When we retrieved them from the server, they were in UTC timezone, but the current slot we were working with was in the locale timezone. It is now converted to UTC to check if we already hit max capacity. Before this, selecting a timezone was actually selecting the one that was two hours earlier (for Belgium). With this commit, the values that reached max capacity will not be displayed on the select for the time slots anymore. opw-5092888 Forward-Port-Of: odoo/odoo#228441
The Unrealized Currency Gains/Losses report now correctly creates draft adjustment entries even when users customize how report lines are grouped. This prevents a misleading “No adjustment needed” error and helps finance teams complete currency revaluation workflows reliably.
Original PR description
**Steps to reproduce** - Edit "Unrealized Currency Gains/Losses" report configuration as follows: - Lines > Accounts To Adjust, set GroupBy to 'currency_id, partner_id, account_id, id' - Lines > Excluded Accounts, set GroupBy to 'currency_id, partner_id, account_id, id' - In Options, check 'Unfold All' - View the report > Click 'Adjustment Entry' **Issue** Instead of creating a draft journal entry an user error "No adjustment needed" will block the action **Solution** The issue occurs because when retrieving the lines we assume they are grouped as per default, by 'currency_id, account_id' In case users modify the expression line default grouping to something else, like 'currency_id, partner_id, account_id', we no longer collect values correctly. In order to fix the issue we can unfold all and manually group values by currency_id, account_id opw-4792502 Forward-Port-Of: odoo/enterprise#90894
Users who can print and send SEPA direct debit mandates can now generate and access the related PDF attachments. This removes a permission mismatch that could block sending mandate emails or prevent users from opening attachments they had created.
Original PR description
Removing the groups restriction from the `mandate_pdf_file` field in model `sdd.mandate` because it was causing issues when using the `sdd.mandate.send` wizard. Any user who has access to the `sdd.mandate` model can use this wizard to print and send the record. During this process, the system generates a PDF and stores it in the `mandate_pdf_file` binary field, linking the resulting attachment to the record. The previous group restriction prevented users who were not part of the `account.group_account_readonly` group from sending the email with the attachment. Even if the email was somehow sent, those users still couldn’t access the attachments they themselves had generated and sent. With this change, any user who is allowed to send and print `sdd.mandate` records will also be able to generate and later access the corresponding attachments. Forward-Port-Of: odoo/enterprise#96119
This fixes an issue where an IoT device could pair successfully but then immediately lose its server configuration because an old clear message was processed. The system now ignores stale clear requests right after reconnecting, making re-pairing more reliable for users.
Original PR description
Steps to reproduce: 1. Pair your IoT 2. From the IoT homepage, clear the server configuration 3. From the DB, delete the IoT box record 4. Pair your IoT again EXPECTED BEHAVIOUR: - IoT pairs succesfully ACTUAL BEHAVIOUR: - IoT pairs but then immediately clears the server configuration This commit introduces a simply sanity check to workaround the issue, by simply ignoring a `server_clear` message if it was received less than 5 seconds after connecting to the websocket. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Recruitment users can now add applicants to a talent pool without being blocked by employee access restrictions. This prevents an unexpected error in the hiring workflow for users who have Recruitment permissions but limited HR employee access.
Original PR description
Steps to reproduce: ==================== 1. Grant admin access for Recruitment to demo user. 2. Go to the Recruitment app. 3. Open Applications > Talent Pool. 4. Select a talent pool. 5. Click "Add to pool". Problem: ========= If the user lacks read access on Employees, an access error occurs. This happens because `_add_applicants_to_pool` tries to access `proposed_contracts`, https://github.com/odoo/enterprise/blob/95b9942316c962950ace6b899faa6f1e6c8fee9a/hr_contract_salary/models/hr_applicant.py#L17 which triggers a read on `hr.version`. Since `hr.version` uses `_order`, https://github.com/odoo/odoo/blob/f0eb0c792b77fbaf0ef3738ea88d9c2bae880a85/addons/hr/models/hr_version.py#L28 it tries to sort the result, leading to a access rights error. Fix: ==== Use `sudo` when calling _add_applicants_to_pool. opw-5074018
This fix prevents the emoji picker from crashing when Odoo is used in non-English languages. Users can now open and use the emoji picker in Discuss even when translations contain special line breaks or emoji data is unavailable.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ In some non-English translations, emoji strings include `\n`, which breaks JSON parsing in `emoji_data.js`. This causes `emojis.length === 0`, so the empty state is displayed instead of the main emoji picker UI. Some UI logic still executes on missing DOM elements, which triggers errors. **Current behavior before PR:** --------------------------------- - Switch to a non-English language - Open the emoji picker in Discuss - Errors are triggered due to missing DOM elements **Desired behavior after PR is merged:** ----------------------------------------- - Emoji JSON parses correctly - The emoji picker opens without errors in non-English languages - The emoji picker still opens when `emojis.length === 0` **Task:** 4978824 Forward-Port-Of: odoo/odoo#229795 Forward-Port-Of: odoo/odoo#223564
This update refreshes Odoo's spreadsheet component with several bug fixes that make spreadsheet editing more reliable. Users should see fewer issues with format handling, sheet renaming, header creation, mobile formula editing, and pivot table calculations.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d4df70e06e [REL] 18.4.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d4df70e06e [REL] 18.4.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5952c992b5 [FIX] format: wrong internal format conversion [Task: 5126306](https://www.odoo.com/odoo/2328/tasks/5126306) https://github.com/odoo/o-spreadsheet/commit/cf2dc7fd11 [FIX] spreadsheet: prevent sheet name edit from losing focus [Task: 5109129](https://www.odoo.com/odoo/2328/tasks/5109129) https://github.com/odoo/o-spreadsheet/commit/5d90de9d07 [FIX] Evaluation: remove spread relations [Task: 5105030](https://www.odoo.com/odoo/2328/tasks/5105030) https://github.com/odoo/o-spreadsheet/commit/4b990f1c47 [FIX] headers: can add lots of headers [Task: 5092626](https://www.odoo.com/odoo/2328/tasks/5092626) https://github.com/odoo/o-spreadsheet/commit/32118777ef [FIX] composer: show FX icon in inactive mobile composer [Task: 5092659](https://www.odoo.com/odoo/2328/tasks/5092659) https://github.com/odoo/o-spreadsheet/commit/697ee86139 [FIX] pivot: add deferred calculated measure [Task: 5096156](https://www.odoo.com/odoo/2328/tasks/5096156) 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: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@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>
Incoming Chilean electronic invoice emails with accented characters could fail to process and show an error. This fix allows those XML invoices to be read correctly, reducing manual follow-up for affected documents.
Original PR description
### Issue:
The invoice XMLs having special characters like "Ó" received in DTE emails will trigger a traceback.
### Cause:
`.decode('utf-8')` will try decoding the bytes in utf-8 but Ó is not UTF-8, so there is a traceback:
```
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcd in position 1734: invalid continuation byte
```
In any case, it crashes at the next line: `xml_content = etree.fromstring(xml_dte)` because the XML specifies the encoding (i.e. unicode) but the true encoding is `utf-8` so an error is raised:
```
ValueError: Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration.
```
### Solution:
Remove `.decode('utf-8')` when decoding. The method `fromstring` accepts bytes and will use the encoding specified in the XML.
opw-5124661This update prevents UK tax report submissions from reusing invalid saved device identifiers when contacting HMRC. If an incorrect value is found in the browser, Odoo clears it so a valid identifier can be used and requests are less likely to be rejected.
Original PR description
There are still Odoo requests that are sent to hmrc with invalid 'Gov-Client-Device-ID' header. They are showing this error: "Submit a UUID which is 128 bits or 32 hex characters long". A possible explanation, is that some users have some garbage value in the localStorage for 'hmrc_gov_client_device_id', that does not correspond to a uuid. This value would then be sent each time in the headers, and get rejected. The fix here is to clear the localStorage value if it is not a uuid. task-4627086 Forward-Port-Of: odoo/enterprise#96409 Forward-Port-Of: odoo/enterprise#87335
This update ensures IoT drivers correctly prepare information before sending it to the Odoo database. It prevents failures when using connected payment terminal libraries, helping devices continue to communicate reliably after recent platform changes.
Original PR description
This PR fixes the bytestrings being sent as such when using ctypes C/C++ libraries in iot drivers. After the PR https://github.com/odoo/odoo/pull/206903 the bytestrings are not supported anymore in the requests sent to the database from the iot and need to be decoded first. Related PR for v19 -> master: https://github.com/odoo/enterprise/pull/96537 opw-5129596
The German Datev export now handles sales and purchase receipts even when no customer or vendor is entered. This prevents export failures and helps businesses keep accounting data flowing correctly for receipt-based transactions.
Original PR description
Since 18.4, there are purchase receipts as a function for vendor bills, where you can choose to put no vendor in the vendor field, the same is true for invoices with sale receipts. Making sure that partners are not Null task-5114562