Thursday, October 23, 2025
9 changes · saas-18.3
Resolved issues and error corrections
This fix ensures Argentine foreign vendor bills consistently default to the proper document type for invoices and receipts from abroad. It also aligns foreign supplier handling on customer invoices with foreign customer behavior, reducing document selection errors in invoicing workflows.
Original PR description
Description of the issue/feature this PR addresses: In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del…
Description of the issue/feature this PR addresses: In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del Exterior' which are both AFIP responsabilities for foreing supplier and customer respectively. In this [commit](https://github.com/odoo/odoo/commit/7e45c6ec768950b6296d991a8375577aed45c4dd), we added the possibility to create 'B' invoices for foreign partners. With this PR we are fixing the logic to suggest the correct document type for foreign vendor bills so it has a similar behavior as for customers. Current behavior before PR: In customer invoices the document type suggested by default depends on the journal: --> Expo journal will suggest 'Expo invoices' for Foreign Customers but 'B Invoices' for Foreign Suppliers --> Local electronic journal will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers In vendor bills the document type suggested by default will be 'INVOICES AND RECEIPTS FROM ABROAD' for Foreign Customers and 'B Invoices' for Foreign Suppliers Desired behavior after PR is merged: In customer invoices the document type suggested by default depends on the journal: --> Expo journal will suggest 'Expo invoices' for both Foreign Customers and Suppliers --> Local electronic journal will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers In vendor bills the document type suggested by default will be always 'INVOICES AND RECEIPTS FROM ABROAD' as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228635
Self-ordering now separates orders between devices when customers pay after each order, preventing people at the same table from seeing or changing each other's orders. When paying after the meal, devices at the same table can still collaborate on one shared order as intended.
Original PR description
Before this commit orders were always shared between multiple devices using the same QR code. This could lead to issues when multiple customers were using self-ordering at the same table, as they could see and modify each other's orders. When multiple devices are used for self-ordering with the same QR code, there is now two mode possible: - Pay after each: orders are not shared, and the table isn't linked to the order when synchronizing. Instead the table number is in the floating order name. - Pay after meal: orders are shared, and the table is linked to the order when synchronizing. That's means that multiple devices can add products to the same order. taskId: 5187089
This fix prevents an error when users post work-in-progress accounting entries for a manufacturing work order that is still running. The wizard now opens as expected, helping manufacturing and accounting teams continue cost tracking without interruption.
Original PR description
Issue: - Traceback when calculating the cost of a workorder Step to reproduce: - with apps: mrp, accountant - create a MO for a product - add a WO - confirm - start the WO - Action > "Post WIP Accounting entry" Current Behavior: - get a traceback Expected behaviour - open the WIP wizard Cause of the issue: - to calculate the cost of production, wizard use all WO including the one still running. However as it is still running its end date is registered as `False`. It raises a traceback when it compares the end of the WO with a limit date because `bool` and `datetime.datetime` are not compatible for '<'. Solution: - check if the end date of the WO is defined Test: - in module mrp_workorder an override of button_start change how work order are launched. Therefore, the test should be launched on an Enterprise run. opw-4961873 Forward-Port-Of: odoo/enterprise#97558 Forward-Port-Of: odoo/enterprise#93812
Fixes an issue where online shoppers could get stuck after a successful payment when extra accounting controls were enabled. The change ensures the payment confirmation process can complete reliably for public website users while preserving accounting restrictions.
Original PR description
Error in backend while public user payment confirmation Steps: - Install `website_sale` - Activate `restrict_mode_hash_table` on sale journal - From an incognito window, Make an order in ecommerce and pay it -> we get stucked on 'Your payment has been successfully processed' page because of an acces error in the backend This is because when posting a new move, we either to access or modify moves we get from `chain['moves']`, however these moves are returned with `sudo(False)` by `AccountMove._get_chain_info()`. opw-5128189 Forward-Port-Of: odoo/odoo#232143
This fixes a display issue where portal pages in right-to-left website languages could show excessive blank horizontal space. Dynamic website styling now uses the active website language, so pages render correctly for users browsing in languages such as Arabic.
Original PR description
Scenario to reproduce from 18.0: - install right-to-left (eg. arabic) language on website - open a portal record with chatter (eg. /my/invoices/1) - switch to right-to-left language - scroll…
Scenario to reproduce from 18.0: - install right-to-left (eg. arabic) language on website - open a portal record with chatter (eg. /my/invoices/1) - switch to right-to-left language - scroll horizontally to the left Result: there is a huge amount of whitespace scrollable to the left. Cause: In 18.0, the chatter has an hidden textarea .o-mail-Composer-fake with position "left: -10000px; top: -10000px;". But the chatter assets (portal.assets_chatter_style) are called dynamically with getBundle which is using the session lang instead of the website lang. So the bundle is gotten with the wrong lang and the CSS is not rtlcss'ed and this create big whitespace to the left of the page. Fix: set the website request language when getting bundle for the frontend. Note: this PR also create a TestLangUrlCommon to prevent TestLangUrl tests of being run a second time in TestControllerRedirect. opw-5013485 Forward-Port-Of: odoo/odoo#232671 Forward-Port-Of: odoo/odoo#223575
Large PNG images uploaded to Odoo are now resized without being converted to a limited web color palette. This prevents visible image quality loss on websites and other areas using uploaded attachments, so users no longer need to resize images manually before uploading.
Original PR description
When uploading a png image ir_attachment, the image is not modified if its resolution is under the maximum 1920x1920. However, if the resolution is bigger, it both gets resized and is converted to a WEB palette, which visibly degrades the quality of the image. A workaround for this is to resize the image locally to be max 1920 on either dimensions and then upload it, which effectively bypasses this special treatment. Steps to reproduce: - Go to the website app - Add a Text - Image snippet - Double click the image - Upload a .png image of a resolution strictly greater than 1920 in either width or height Old behavior: the png is visibly degraded New behavior: the png is not visibly degraded opw-3935533 Forward-Port-Of: odoo/odoo#173508
The scheduled check for Mexican electronic invoice status will no longer get stuck reviewing the same first batch of documents repeatedly. This helps ensure all eligible received invoices are checked with the SAT over time, improving reliability for compliance monitoring.
Original PR description
Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return…
Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return l10n_mx_edi_documents that have been imported from somewhere and whose invoice has been posted. This is because Odoo needs to always checked the value of the originator of an EDI document, in case it has been cancelled from the SAT Portal for instance.
Both `state = 'invoice_received'` and `'move_id.state = 'posted'` are mostly fixed value. The state needs to stay `invoice_received` as Odoo needs to always check the originator document's value. And once an invoice is posted, it's stays as so except in the case of cancellation.
This leads to an issue when the database contains more than 100 documents that are both `invoice_received` and `move_id.state = 'posted'`. In this case, the cron `_fetch_and_update_sat_status` will always process the same 100 documents. Once the limit of 100 is reached, the cron retriggers itself before terminating. Then on the next execution, the search call with the domain coming from `_get_update_sat_status_domain` will return the same 100 documents again.
This commit fixes this issue by ordering the documents in the cron method by `write_date asc`. Even if the SAT value of the documents does not change, the `write_date` should be updated as their is still a write that is triggered via `_update_document_sat_state`. This prevents the cron from always processing the same documents over and over again.
Forward-Port-Of: odoo/enterprise#93205This fix ensures Spanish Facturae e-invoicing tax classifications are loaded correctly for mainland Spain and the Canary Islands. It also prevents unrelated taxes from receiving an incorrect default value, reducing the risk of inaccurate electronic invoice tax reporting.
Original PR description
Currently the tax data defined in l10n_es_edi_facturae is incomplete and never loaded. This commit makes sure that the l10n_es_edi_facturae_tax_type is loaded correctly and adds the appropriate templates for es_common_mainland and es_canary_common. The default is also removed on the field l10n_es_edi_facturae_tax_type to avoid the value being assigned for unrelated taxes. task-4981325 Forward-Port-Of: odoo/odoo#231277
This update prevents crashes that could occur when users quickly drag and drop multiple cards in large grouped Kanban views. It makes the interface safer during heavy screen refreshes, reducing interruptions for users working with many records.
Original PR description
On a grouped kanban view displaying a lot of records (i.e. with a lot of columns and a lot of records by column), drag and drop several records from the same column quick multiple times. Before this…
On a grouped kanban view displaying a lot of records (i.e. with a lot of columns and a lot of records by column), drag and drop several records from the same column quick multiple times. Before this commit, different crashes could occur. The first category of crashes concern the sortable hook. It called the onDrop callback even if the dragged element was no longer in the DOM (which occurs if there's a re-rendering while the user is dragging). This has been fixed in the hook, and tested. Another crash could arise in kanban (in the model). If the user dropped the card while there was a scheduled/ongoing re-rendering, i.e. at a specific moment where the model isn't synchronized with the DOM, the dropped card was still in the DOM, but it's associated datapoint was no longer referenced in hte model. In that case, we can do nothing but cancel the d&d. Note that this couldn't be tested, as reproducing the exact behavior (typically having a slow rendering due to the number of cards to render) isn't possible in a unit test, where user interactions are done programmatically. Task~5167650 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#231886