Daily updates from Odoo
Tuesday, October 7, 2025
31 changes · saas-18.4
Resolved issues and error corrections
The message shown when fetching bank transactions finds no results now displays correctly instead of showing raw formatting tags. This makes the banking workflow clearer and more professional for users when filters or transaction fetches return no matches.
Original PR description
Before this commit : - The help message shown when no transactions were fetched by the 'Fetch Transactions' button in the 'Bank' journal contained raw html tags, as markup was not getting applied. - Also, removing a filter (without reloading) and applying another filter that resulted in no matches, the same issue occurred. After this commit: - The help message is now consistently rendered with markup applied. task-4942234 Forward-Port-Of: odoo/enterprise#95514
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
The website profile email validation banner now remains hidden after a user closes it. This prevents confusing repeat messages about email validation and creates a smoother account experience.
Original PR description
### Issue 1: The validated email success banner wasn’t triggering the RPC call because Bootstrap’s `data-bs-dismiss="alert"` removed the element from the DOM before the handler could run. ### Issue 2 Closing the banner previously triggered `/profile/validate_email/close` RPC, which reset `validation_email_done` to false. This mistakenly caused the “email sent” banner to reappear, confusing users. ### Solution - Overwrite Bootstrap’s `close.bs.alert` event to trigger the RPC when the success banner is dismissed. - Set `validation_email_sent = False` so the banner stays hidden after being closed. Task-5049533 Forward-Port-Of: odoo/odoo#229913 Forward-Port-Of: odoo/odoo#225872
Fixes Belgian EC Sales List reporting when a company's VAT number was entered without the country prefix. This prevents incorrect trimming of VAT numbers and ensures Belgian reports consistently use Belgium as the country code.
Original PR description
It could happen that the user set his vat number without the country code before the number. In this case, we removed the two first digits of the vat number. Also changing other occurrence using the company_vat to get the country, since we are in the belgian ec sale list, the country_code should be 'BE' everytime task-5039969 Forward-Port-Of: odoo/enterprise#93377
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
This fix makes Mail channel mention suggestions more reliable when replying in channel threads. It corrects a test setup and mock response format so the issue is consistently covered and future regressions are easier to catch.
Original PR description
Back-port of https://github.com/odoo/odoo/pull/230157 https://runbot.odoo.com/odoo/runbot.build.error/233201 Problematic line introduced: https://github.com/odoo/odoo/pull/209240 Test introduced: https://github.com/odoo/odoo/pull/226563 Test adapted to be more deterministic: remove current user from channel to ensure the channel is always found through the suggestion route. Fixed returned format of mock server.
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
Employees with flexible working hours will no longer see weekends automatically marked as unavailable in the timesheet grid. This prevents misleading greyed-out days for people who can choose when they work, making time entry clearer and more accurate.
Original PR description
To reproduce: ============= 1- Update employee worktime to be flexible 2- Go to timesheets -> saturday & sunday are marked grey Problem: ======== Can't apply https://github.com/odoo/odoo/blob/ce2d134d3e8e5c0d96529c1d0490f1e0c5e28294/addons/resource/models/resource_calendar.py#L511 This logic cannot be applied when an employee's work time is flexible, since they can work whenever they want. Fix: ==== When employee work time is flexible we just return empty list for the unavailable dates. opw-5031144 Forward-Port-Of: odoo/enterprise#96181 Forward-Port-Of: odoo/enterprise#94346
Odoo now handles Gelato cancellation updates without crashing when a removed email template is no longer available. Instead of trying to send that missing notification, it records the cancellation status in the sales order chatter so teams can still see the update.
Original PR description
After an order is canceled on Gelato, we receveive a webhook with an `fulfillmentStatus` of `cancel` and while processing it, it crash with: ``` ValueError: External ID not found in the system: sale.mail_template_sale_cancellation ``` The mail template used to notify the status change has been removed in odoo/odoo@2c858ed15e50, so instead we simplify log the information on the sale order chatter. opw-5110226 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230121
Opening the Helpdesk ticket list with no tickets now works correctly instead of crashing. This improves reliability for teams starting with an empty ticket queue or after clearing all tickets.
Original PR description
When accessing the Helpdesk ticket list view with zero tickets, the view previously crashed due to improper handling of folded sample data. This commit ensures that sample data folding does not trigger errors when the view is empty, improving overall stability. Steps to reproduce: 1. Navigate to Helpdesk > Teams > Tickets. 2. Ensure there are no tickets. 3. Switch to list view. Task-4971510
Users can now create automated actions in Documents that generate journal entries for credit card journals. This fixes a blockage that prevented credit card statement workflows from being set up correctly.
Original PR description
We are unable to create an action to create a credit card statement on a journal with type credit card Allow to create a Server Action to create Journal Entries in journals of type "Credit Card" in Documents. task-5123868 Forward-Port-Of: odoo/enterprise#95905
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
This fixes an issue where users could paste text into protected, non-editable areas while editing website content. The change helps preserve locked content and prevents accidental modifications in the website builder.
Original PR description
When the selection is on text inside an element which is not `contenteditable` and is a inside the editable root, the user could paste text that would get inserted. This commit prevents that by ignoring `paste` events when selection is in a `contenteditable=false`. Steps to reproduce: - On `form/help-1`, open website builder - Select the text of "Help" title - Paste text - Bug: text is inserted task-4367641 Forward-Port-Of: odoo/odoo#228149
This fix makes an automated test for signed document cleanup reliable by avoiding timing edge cases around deletion dates. It helps prevent false test failures without changing how users work with documents.
Original PR description
Steps to reproduce
==================
Launch the test `test_gc_clear_bin` a few times
It will eventually fail:
documents.document(544,) is not false :
trash document should be deleted after gc_clear_bin
Cause of the issue
==================
The domain for wether a record should be deleted contains `('write_date', '<=', fields.Datetime.now() - relativedelta(days=deletion_delay)`
The tests fails when the write_date is in the same second as the test run.
This is because fields.Datetime.now() replaces microseconds by 0.
https://github.com/odoo/odoo/blob/14073faf1fa272b8d3411b4fe6f42c279058459d/odoo/fields.py#L2378
Solution
========
Since records needs to be at least "deletion_delay" old, we add a margin of 30 seconds to make sure they match
runbot-224207
Forward-Port-Of: odoo/enterprise#95926The 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
A test setup for Peruvian electronic invoicing now gives the test user the needed sales permission when demo data is disabled. This prevents false test failures and helps keep invoicing quality checks reliable.
Original PR description
Issue: - user is missing a group to create sale order for `test_invoice_down_payment_foreign_currency` without demo data Step to reproduce - run odoo enterprise with : `-i sale,l10n_pe_edi --without-demo=True --test-tags test_invoice_down_payment_foreign_currency` Solution: - add corresponding group to user related [to PR](https://github.com/odoo/enterprise/pull/93885) runbot-233038
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
Moving an opportunity into an empty CRM pipeline stage no longer triggers an error when recurring revenue is enabled. This keeps the sales pipeline usable and prevents interruptions during normal drag-and-drop work.
Original PR description
**Steps to reproduce:** 1.Install crm 2.Enable 'Recurring Revenues' from settings 3.Go to CRM > 'My pipeline' > Create a record here 4.Enable debug mode 5.Either create a new stage or move records from any stage to make an empty stage 6.Move created record to an empty stage **Issue:** This Traceback accurs : "Uncaught Promise > Invalid props for component 'AnimatedNumber': 'value' is not a number" **Cause:** https://github.com/odoo/odoo/blob/5ade756227abf58769ff904651628a3ccaf8e19a/addons/web/static/src/views/view_components/animated_number.js#L8-L21 AnimatedNumber expects a numeric value for its value prop. When moving to an empty stage, the aggregate value is false, which is not a valid number for the component. **Solution:** Check for the rrmAggregate value to render the component. opw-4972672
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
Users can now open the overview for completed manufacturing orders even when no bill of materials is linked. This prevents an erroneous unit-of-measure error and helps teams review production records without interruption.
Original PR description
Steps to reproduce: - Create a storable product “P1” - Create a manufacturing order to produce one unit of P1: - add any component - Mark the MO as done - Try to open the MO overview Issue: An error is raised because the MO has no BoM. But in the function we try to compute the missing quantity in the BoM's UoM, but since no BoM is linked, there is no UoM available. Error message: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure %(product_unit)s defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category." Fix: Skip the computation of missing BoM quantities when no BoM is linked, allowing the MO overview to be opened without error. opw-5112132 Opw-5105544 Opw-5119897 Forward-Port-Of: odoo/odoo#229707
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 fix ensures manufacturing shop floor screens handle removed BoM components without showing duplicate material lines or crashing. It adds test coverage so the issue does not return, helping operators continue work smoothly after production setup changes.
Original PR description
### Steps to reproduce: 1. Create a BoM with two components to be consumed in an operation 2. Create a Manufacturing Order with this BoM and confirm it 3. On the BoM, remove one of the products and save 4. Go to the Shop Floor 5. Select the workcenter used in step 1 6. Got duplicate key in t-foreach ### Before this commit: Stock moves without quality checks, that are linked to a workorder but not linked to a BoM line, are included twice in the view, resulting into a traceback. ### After this commit: Include only once the stock moves, removing duplicates from the view. opw-5029970 Forward-Port-Of: odoo/enterprise#93482
This change fixes an unreliable automated test for bus notifications that could fail randomly depending on how notification batches were read. It helps keep the release process stable by ensuring the test checks all received notifications instead of accidentally ignoring some.
Original PR description
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. However, the listener only consider the first notification of the batch (`conn.notifies.pop()`) and ignore the rest. When the expected notifications come as part of a bigger batch, they can be ignored thus making the test fail. This commit ensures we read every notification received. fixes runbot-233185 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#230117 Forward-Port-Of: odoo/odoo#230054
This 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 fixes an issue where certain remote procedure calls could fail when request parameters used names that conflicted with internal fields such as model or method. The change improves reliability for integrations and web requests without changing user workflows.
Original PR description
Backport of odoo/odoo#227801 in saas-18.4 X-Original-Commit: 1bb69de64165b18fca7d00164c5299e58c48d40f
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