Daily updates from Odoo
Wednesday, January 14, 2026
49 changes · saas-18.4
New functionality added to Odoo
This update adds support for payment channels in Thailand (TH), Malaysia (MY), and Vietnam (VN) through Xendit. This expansion allows Odoo to process payments from these key markets, broadening our customer base and improving payment flexibility.
Original PR description
Xendit has expanded to TH, MY and VN supporting the local payment channels. This commit is to add the supported pamyent channels according to what they have added. task-4334511 Forward-Port-Of: odoo/odoo#189527
This update allows businesses to seamlessly handle self-billed invoices, a key requirement for Peppol integration. It enables the export of vendor bills as compliant self-billed invoices and the import of Peppol-provided invoices into Odoo, streamlining accounting processes and facilitating international trade.
Original PR description
Self-billed invoices are invoices which are created by the customer on behalf of the vendor. These can be used in certain business flows, typically when the customer needs to create an invoice…
Self-billed invoices are invoices which are created by the customer on behalf of the vendor. These can be used in certain business flows, typically when the customer needs to create an invoice internally for accounting purposes. Peppol provides the ability for customers to send self-billed invoices to the vendor over the Peppol network. This way the vendor can verify whether the invoice is correct. See the Peppol documentation at https://docs.peppol.eu/poacc/self-billing/3.0/bis-sb/ #### This PR provides (1) the ability to export vendor bills as self-billed invoices conformant to the BIS3 standard (2) the ability to import BIS3 self-billed invoices as customer invoices (3) the ability to send vendor bills as self-billed invoices over Peppol (4) the ability to receive self-billed invoices from Peppol in a specified Sales journal. #### Configuration Purchase journals now have a `Is Self Billing` boolean field. Self-billing journals have a per-partner sequence, and can send vendor bills as self-billing invoices via Peppol if the option is activated in the Peppol configuration. We also add the self-billed invoice Peppol document type IDs in the list of documents which the user can select or deselect to allow/prevent reception of those document types. Backport of https://github.com/odoo/odoo/pull/222658 Enterprise PR: https://github.com/odoo/enterprise/pull/97803 Upgrade PR: https://github.com/odoo/upgrade/pull/8886 task-5153851 Forward-Port-Of: odoo/odoo#232548
Enhancements to existing features
This update adds three new fields to invoices generated within the Chorus Pro system: Buyer Reference, Contract Reference, and Purchase Order Reference. These fields ensure invoices comply with Chorus Pro requirements, improving data accuracy and facilitating seamless integration with the Chorus Pro platform.
Original PR description
This commit: - Add three reference fields to invoice PDF for Chorus Pro compliance: Buyer Reference, Contract Reference, and Purchase Order Reference. These fields appear in the invoice header when set on the invoice. task-5410836 Forward-Port-Of: odoo/odoo#240494
This update allows system administrators to customize the main Odoo Enterprise home menu with a targeted message. Administrators can set a message via a database configuration, such as a maintenance notice, which will then be displayed to all users. This provides a flexible way to communicate important information directly to users within the system.
Original PR description
Display a message on home menu based on an ir.config_parameter that can be added directly in the database by the system administrator.
The ir.config_parameter is sysadmin.message and should be a json loadable. The format shoud be something like this:
{
"type": "warning",
"replace": false,
"warning_type": "user",
"message": "`<span>A maintenance operation is planned on your server on <strong>2026-01-15</strong> between 14h and 15h</span>`"
}
Forward-Port-Of: odoo/enterprise#103831
Forward-Port-Of: odoo/enterprise#102239Resolved issues and error corrections
This update resolves an issue preventing receipt printing when multiple payment methods were used in the Italian POS (l10n_it_pos) module. The fix backports a change from another Odoo project, ensuring accurate receipt generation for all payment types. This improves the user experience for Italian POS users.
Original PR description
Backports of https://github.com/odoo/enterprise/pull/96353. References: See page 36 in the [official docs](https://download4.epson.biz/sec_pubs/bs/pdf/ePOS%20Fiscal%20Print%20Solution%20Development%20Guide%20Rev%20T.pdf). Ticket [link](https://www.odoo.com/odoo/project.task/5376242) opw-5376242 Forward-Port-Of: odoo/enterprise#103710
This update resolves an issue where users without specific group permissions would encounter errors when pinning or unpinning embedded actions, particularly within superuser mode. By adding a check for superuser status, the system now correctly allows superusers to perform these actions, ensuring stability for automated processes and installation scripts.
Original PR description
Prior to this commit, an AccessError would be raised when pinning or unpinning embedded actions if the current user did not belong to the 'documents.group_documents_user' group. This could cause issues during operations running in superuser mode (e.g., automated actions, installation scripts, or sudo() calls) because the check strictly validated the user's groups without considering the environment's superuser flag. This commit adds a check for `self.env.su` to ensure the AccessError is not raised when the environment is in superuser mode. Task-5380727 Forward-Port-Of: odoo/enterprise#104043 Forward-Port-Of: odoo/enterprise#101106
This update resolves an issue where Odoo incorrectly searched for proxy users when a branch company had the same VAT/Codice Fiscale as its parent. This prevented users from correctly configuring Electronic Invoicing (IT EDI) for branch offices. The fix ensures the correct company is identified during proxy user searches, improving EDI processing reliability.
Original PR description
Fix issue when saving a branch company sharing the same VAT and Codice Fiscale as its parent. The proxy user search fails because `account_edi_proxy_client.user` is looked up in the branch company instead of the parent one. The same applies when searching the demo user to remove. Steps to reproduce: - Install `account` and `l10n_it_edi` - Set up the company's VAT and Codice Fiscale - Create a branch company with the same VAT and Codice Fiscale - Enable the Electronic Invoicing processing through the SDI in the settings - Select only the branch company and try to save the settings - Observe error since we will try to create a proxy user on the IAP server for an already existing company (the parent one). Ticket [link](https://www.odoo.com/odoo/project.task/5391668) opw-5391668 Forward-Port-Of: odoo/odoo#241443
This update fixes a technical issue that prevented Odoo from properly exporting code translations for the new odoo.orm package. By specifying the package name in the framework's export process, Odoo can now accurately capture and manage code translations, ensuring consistent localization across the platform. This improves the quality and accuracy of our translated applications.
Original PR description
New package odoo.orm was added in PR https://github.com/odoo/odoo/pull/182727 The new package's name must be specified in ``TranslationModuleReader._export_translatable_resources`` to allow the framework to export its code translations. 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#243584
This update resolves a rare error in tax calculations that occurred due to the unpredictable order in which a set of allowed tokens is processed. The fix ensures that tax formulas are consistently evaluated, preventing calculation failures. This improves the reliability of tax processing within Odoo.
Original PR description
…me tokens greedily. Fixes issue #241004 and is a cleaned up version of a previous PR https://github.com/odoo/odoo/pull/241033 This is a hard to reproduce bug because it depends in what order the…
…me tokens greedily. Fixes issue #241004 and is a cleaned up version of a previous PR https://github.com/odoo/odoo/pull/241033 This is a hard to reproduce bug because it depends in what order the FORMULA_ALLOWED_TOKENS set is iterated. Since the set is an unordered structure, this bug will happen just sometimes. The issue is this: There might be taxes that do a different calculation depending on the base. So for example, we might need to do a formula like this: (base >= 100) and (base * 0.05) or (base * 0.07) <img width="1302" height="651" alt="Captura de pantalla 2025-12-26 a la(s) 11 17 02" src="https://github.com/user-attachments/assets/7ce16272-56a4-452b-8eba-e797442f68c2" /> This formula multiplies the base by a certain value depending on whether the base is greater or equal than 100. This formula will work sometimes, but sometimes, it will fail with this error. <img width="1302" height="615" alt="Captura de pantalla 2025-12-26 a la(s) 11 18 48" src="https://github.com/user-attachments/assets/5527ff5d-6747-4221-b54f-085e0603aa5a" /> The position of the error is the '=', because the '=' is not a valid token in this list: https://github.com/odoo/odoo/blob/18.0/addons/account_tax_python/models/account_tax.py#L10. The formula is not using just the '=' token in this formula. The formula is using the '>=' token and '>=' is an allowed token. So why this error appears sometimes? So here is the important thing and why this bug appears only sometimes: FORMULA_ALLOWED_TOKENS is not a tuple. It is a set. And sets iterate randomly (it is an unordered list). So the loop in this line: https://github.com/odoo/odoo/blob/18.0/addons/account_tax_python/models/account_tax.py#L127 sometimes sees the token '>=' first, and sometimes sees the token '>' first in its cycle. When the '>=' is first in the set of allowed tokens, the loop goes through the formula, trying to match substrings to each token in the set. It matches the '>=' first so it advances 2 positions. In this scenario, the validation does not fail. But when the '>' is first in the set of allowed tokens, the loop goes through the formula, trying to match substrings to each token in the set. It matches the '>' first so it advances 1 position. It has consumed only the '>' of '>='. Now, it will try to match the lone '=' to any of it tokens in the set of allowed tokens, but this '=' will not match any of the allowed tokens, so it will fail. You can reproduce this bug using the above formula, and restarting Odoo if the error does not appear. Eventually, after restarting, the FORMULA_ALLOWED_TOKENS will have the '>' first and trigger the error. The important part to understand here is that FORMULA_ALLOWED_TOKENS is unordered, so, the order of the loop is not guaranteed and sometimes this error is triggered and sometimes it is not, depending on the order the loop is done. 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#242661
This update fixes an issue where a distracting helper element appeared in the bank reconciliation journal when there were no entries. The change hides this element when the quick-create view is open and empty, resulting in a cleaner and more user-friendly experience, particularly on mobile devices.
Original PR description
Before this PR, in the bank reconciliation journal, the no-content helper remained visible when the quick-create view was opened and there were 0 entries. This was unexpected behavior and caused overlapping issues, especially on mobile views. With this PR, the no-content helper is hidden whenever the quick-create view is open and there are 0 entries either isGrouped or not. task-5470591 Forward-Port-Of: odoo/enterprise#103776
This update fixes a limitation in the portal's canned response feature, allowing internal users to properly access and utilize available responses. The previous fix was removed and replaced with a more appropriate solution, preparing for future support of the `::` delimiter within the portal. This enhancement ensures a smoother experience for users interacting through the portal.
Original PR description
*: im_livechat, portal, project, test_mail_full PR #192953 introduces a composer action for canned responses. The feature is available in portal for internal users but since `suggestion` is disabled in portal, this feature doesn't work properly. In preparation for supporting `::` delimiter in portal, the incorrect fix in PR #231360 has been reverted. `inFrontendPortalChatter` is specific to portal frontend and should not be set to `true` in the project sharing environment. Instead of the mentioned fix, a similar fix from PR #231441 has been backported. task-5262349 Forward-Port-Of: odoo/odoo#235551
This update ensures that the correct warehouse location is linked when manufacturing merged production orders. Previously, the system incorrectly defaulted to the warehouse's default location, causing issues with multi-location workflows. This fix guarantees accurate tracking of materials throughout the manufacturing process.
Original PR description
Situation ----- When applying a push rule after manufacturing a merged MO, there is an odd case where the link between the merged MO's transfer and the demand move breaks in…
Situation ----- When applying a push rule after manufacturing a merged MO, there is an odd case where the link between the merged MO's transfer and the demand move breaks in https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1054 because of the `m.location_id == move.location_final_id` part being false in https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1090-L1097 This is because, during the merge, `location_final_id` is not propagated to the new MO https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L2416-L2424 so when the new MO's `move_finished_id` gets computed https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L822 it gets the MO's `location_final_id` https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L1202 which is false. This leads to to the move getting the warehouse's default stock location thanks to https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/mrp/models/stock_move.py#L456-L457 This is problematic for complex use cases with multi-locations and custom routes. It should be safe to propagate the `location_final_id` of the merged MOs if they all share the same one. Use case example ----- <details> <summary>Full use case</summary> - Enable multi-step routes - Create location "WH/Stock/L1" - Create location "WH/Stock/L2" - Create Operation Type "MO child" - Type of Operation: Manufacturing - Sequence Prefix: MOCHILD - Source Location: L1 - Destination Location: L2 - Create Operation Type "Push Transfer" - Type of Operation: Internal Transfer - Sequence Prefix: L2L1 - Source Location: L2 - Destination Location: L1 - Create Route "MO child" - Create Rule "Manufacture" - Action: Manufacture - Operation Type: MO child - Source Location: False - Destination Location: Stock - Create Route "2-step" - Warehouse: Main WH - Create Rule "L1 -> Virtual/Production" - Action: Pull from - Operation Type: MO child - Source Location: L1 - Destination Location: Virtual/Production - Create Rule "Push: L2 -> L1" - Action: Push To - Operation Type: Push Transfer - Source Location: L2 - Destination Location: L1 - Unarchive MTO - Edit MTO route - Create Rule "L1 -> Virtual/production (MTO)" - Action: Pull - Operation Type: "My Company: Manufacturing" - Source Location: L1 - Destination Location: Virtual/Production - Supply Method: Trigger another rule - Create product "Main product" - Create product "Child product" - Routes: "MO child" & MTO - Create product "Material" (consumable) - Create BOM - Product: "Main product" - Component: "Child product" - Create BOM - Product: "Child product" - Component: "Material" - Create MO for "Main product" - Misc/Component Location set to L1 - Duplicate the MO - Merge child MOs & produce - Validate merged MO transfer to L1 - Go back to one of the "Main product" MO > Component quantity is 0 </details> ----- Ticket: opw-5144196 Forward-Port-Of: odoo/odoo#242373 Forward-Port-Of: odoo/odoo#240695
This update resolves an issue where Odoo encountered errors when processing emails with attachment content types incorrectly identified as '*/*'. To ensure emails are processed reliably, the system now defaults to 'application/octet-stream' for these cases, minimizing disruption. The change is a temporary workaround until email senders adhere to standard MIME type specifications.
Original PR description
In some rare cases it would seem that some systems construct emails with attachments reporting `*/*` as the Content-Type. While trying to parse such content in Odoo, it causes issues with the…
In some rare cases it would seem that some systems construct emails with attachments reporting `*/*` as the Content-Type. While trying to parse such content in Odoo, it causes issues with the standard CPython email library, as no standard handler exists for '*/*' content-types: Example error: ``` File "/usr/lib/python3.13/email/contentmanager.py", line 25, in get_content raise KeyError(content_type) KeyError: '*/*' ``` This is not compliant with valid MIME types defined in RFC2046/section-3, but in real life scenarios, blocking the processing of an incoming email in Odoo because of this might be excessive. While not a perfect solution, we will assume that attachments falsly reported as `*/*` are to be processed as 'application/octet-stream' content types. This should cover most use-cases, and if it still fails, we will consider that it's up to the original email sender to be RFC compliant. OPW-5425093 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242193
This update fixes an issue where clicking links in the Odoo portal triggered a false 'page view' event for customers. A simple adjustment was made to the request headers sent from the link preview, ensuring accurate tracking of customer portal activity. This improves reporting and analytics related to customer engagement.
Original PR description
When a link to the portal is sent from the chatter via message or log note, the preview of the link triggers that the page was viewed by customer. As a solution a variable was added to the request headers coming from the previewer. opw-5237785 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243061
This update resolves a bug that occurred when switching fiscal localizations (like Jordan) within the Hair Salon industry module. The system was incorrectly attempting to delete and recreate journals, leading to a database error. This fix ensures a proper cascade delete process, preventing the error and maintaining data integrity.
Original PR description
Steps to reproduce: - Install industry Hair Salon - Settings > Invoicing > Fiscal Localization - Switch to Jordan fiscal localization Issue: Action will fail with error ``` ERROR: update or delete on table "account_journal" violates foreign key constraint "pos_payment_method_journal_id_fkey" on table "pos_payment_method" DETAIL: Key (id)=(6) is still referenced from table "pos_payment_method". ``` Analysis: It occurs because, when switching CoA, the system attempt to delete and re-create journals. However, the hair salon industry initialize a PoS configuration that will create a default payment method based on one of those journal, thus the system will raise a constraint error on delete. A solution is to manually enforce cascade delete when we are switching CoA. opw-5145235 Forward-Port-Of: odoo/odoo#243381 Forward-Port-Of: odoo/odoo#239433
This update resolves an issue where FrontDesk hosts with limited access were unable to check out visitors via email. The fix allows the checkout process to run with elevated permissions, ensuring all hosts can successfully complete the visitor checkout. This improves the user experience for FrontDesk staff.
Original PR description
Steps to reproduce: * Create a visitor record with a host who has only FrontDesk user access. * Ensure Notify with Email is enabled on the station. * Click Check Out Visitor from the received email → access error appears. Issue: * Hosts with only FrontDesk user access received an access error when clicking the “Check Out Visitor” button from the email notification. * They were unable to complete the visitor checkout process. Fix: * Run the checkout action with sudo() so the host can successfully check out the visitor from the email link. Impact: * Hosts can now check out visitors without encountering permission errors. task-5373026 Forward-Port-Of: odoo/enterprise#101179
This update corrects a bug where delivery fees weren't accurately calculated when sales orders and company currencies differed. The fix ensures that delivery fees are correctly priced based on the sales order's currency, preventing discrepancies in pricing displayed to customers. This improves financial accuracy and reduces potential billing errors.
Original PR description
Issue ----- When the SO and the company use different currencies, the picking currency is correctly set to the SO's but the amount is still computed using the company's currency. Example: Sale in…
Issue ----- When the SO and the company use different currencies, the picking currency is correctly set to the SO's but the amount is still computed using the company's currency. Example: Sale in EUR, Company in USD and 1.5 EUR = 1 USD rate. Sell for 15 EUR of products => the delivery picking shows 10 EUR Steps to reproduce ----- - Activate EUR currency at 1.5 EUR = 1 USD rate - Setup company in USD - Setup INTL FEDEX delivery method - Create a dummy product with a 10 USD sale price - Create a pricelist using the EUR currency - Create a sale for some INTL client - set pricelist to EUR - add dummy product - add INTL FEDEX shipping - confirm the sale - Confirm the linked delivery > Message in chatter shows a price of 10 EUR instead of 15 EUR Cause ----- The problem is with the `carrier_price` field of `stock.picking`. https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L21 The value is set by https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L155 which gets its' value from the response of https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/delivery_fedex.py#L157 We then go through https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L382 where we call https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L484 The problem is that in `_decode_pricing` we take the first line matching the `rateType` with no regard to the currency of the rate https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L594-L598 we should also filter to ensure the rate matches the order's specified currency. ----- Ticket: opw-5419724 Forward-Port-Of: odoo/enterprise#103737 Forward-Port-Of: odoo/enterprise#103232
This update automatically updates the IoT box's database when a new version is released. Previously, manual restarts were required, which was disruptive. Now, the IoT box will seamlessly restart and update its database when it receives a notification of a new version change, ensuring it always uses the latest data.
Original PR description
Before this commit, when the DB was upgraded to a new version, the IoT box had to be manually restarted so that it would checkout and align with the new version. After this commit, we check the DB branch whenever we receive a `bundle_changed` message on the websocket. If it has changed then the IoT will restart and checkout the new version. task-5463520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242195
This update resolves an issue where enabling integer rounding on Aged Receivable reports caused a crash. The fix prevents a type error that occurred when the system attempted to round values that were 'None'. Now, users can safely enable integer rounding without encountering this error.
Original PR description
Currently, enabling the Integer Rounding option (e.g. 'Nearest') on accounting reports like Aged Receivable/Payable causes a crash when expanding lines if any column value evaluates to None. Steps to…
Currently, enabling the Integer Rounding option (e.g. 'Nearest') on accounting reports like Aged Receivable/Payable causes a crash when expanding lines if any column value evaluates to None. Steps to reproduce: 1) Install 'account_reports' module with demo data and enable developer mode. 2) Navigate to Accounting > Reporting> Partner Reports > Aged Receivable. 3) Click on 'gear icon' to navigate advance options. 4) Click on the Options tab and set Integer Rounding to 'Nearest', click save and close adv options. 5) Expand a partner line. Error: `TypeError: unsupported operand type(s) for /: 'NoneType' and 'int'` Root Cause: When integer rounding is enabled, the system iterates over formula results to round them using `float_round`(see[1]). However, specific report columns (such as totals for empty periods) may return None. The `float_round` function attempts to perform arithmetic on this value, failing because it cannot divide NoneType. FIX: Skip the rounding if the value received at [1] is None. [1]- https://github.com/odoo/enterprise/blob/9b517564d95424836da1e8368f6b5dc52ae45d1a/account_reports/models/account_report.py#L3329 opw-5392883 Forward-Port-Of: odoo/enterprise#102417
This update fixes an issue where components added to manufacturing orders through the product catalog weren't correctly transferred to the pre-production warehouse. The fix adds a warehouse ID to these moves, ensuring proper inventory tracking and fulfilling multi-step manufacturing processes. This improves the accuracy of stock levels and streamlines production workflows.
Original PR description
Issue
-----
In multi step manufacturing, components added to MO through the catalog don't get transfered to the pre-prod location.
Steps to reproduce
-----
- 2 step manufacturing
- Create 2 products
- Create a MO for the first product
- Open the product catalog
- Add some qty of the second product
- Go back to the MO & confirm it
> No procurement transfer for the second product from stock to pre-prod
Cause
-----
The move created by the catalog has no `warehouse_id` so in `adjust_procure_method` we don't find any rule which means it gets set to MTS
https://github.com/odoo/odoo/blob/6ecd271ff34313d900a0ad14b1c20679808ba9b8/addons/stock/models/stock_move.py#L2366-L2368
-----
Ticket:
opw-5221418
Forward-Port-Of: odoo/odoo#243036
Forward-Port-Of: odoo/odoo#239265This update fixes a problem where incorrect credentials caused confusing error messages when sending invoices. The change adds a test to specifically handle this scenario and ensures a clearer error display for users. This improves the reliability of invoice processing.
Original PR description
Fixing incorrect error display that occurred while trying to send an invoice to MER with incorrect credentials set up. (no task/error ID) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243489
This update fixes an issue where GS1 barcodes weren't accurately reflecting the quantity of products in manufacturing orders. Previously, the system only recorded a single unit regardless of the barcode's specified quantity. Now, the system correctly uses the barcode quantity to update the product's completed quantity, ensuring consistency and accurate tracking of manufactured goods.
Original PR description
Description of the issue/feature this PR addresses: The quantity of GS1 barcodes was not taken into account when scanning the final product of a manufacturing order. More details of this issue can be found in https://www.odoo.com/odoo/project.task/4817418 Current behavior before PR: When scanning a GS1 barcode with a quantity defined (e.g. 0120250524135700310210000010LOT887766 ) as the final product of a manufacturing order, the quantity is not taken into account in the call to produceQty(), so the line will have a qty_done of 0 regardless of the quantity specified in the barcode Desired behavior after PR is merged: The qty_done of the final product line should be the one specified in the barcode, in order to make the behaviour consistent with other usages of GS1 barcodes. Forward-Port-Of: odoo/enterprise#104024 Forward-Port-Of: odoo/enterprise#95174
This update resolves a display problem in the General Ledger report when using analytic accounting. Previously, the report showed incorrect information and linked to the wrong journal entries. The fix ensures the General Ledger accurately reflects analytic distributions and provides correct links to the relevant journal entries.
Original PR description
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report ->…
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report -> General Ledger -> Options - Activate "Analytic Group By" - Create an invoice - add a line with an analytic account - Confirm the Invoice - Duplicate the invoice - Confirm the second invoice - Go to the General Ledger - Group By the analytic account you used Current Behavior: General Ledger display 2 lines per journal entry being part of the analytic distribution used for the group by. The first line displays the part related to the analytic group by, while the second line display infos for global general ledger. Clicking on the dots of the first line -> "View Journal Entry" send you to an unrelated entry. Expected behavior: - "View Journal Entry" should send to the right entry Proposed Solution: To proceed to the group_by, `_prepare_lines_for_analytic_groupby` create a temporary SQL table. This table uses the account_analytic_line.id as if it was the account_move_line.id. This commit fixes this and goes back to account_move_line.id. However, lines are merged into only one single line. opw-5267981 Forward-Port-Of: odoo/enterprise#103169
This update resolves a minor performance issue in a test related to loading menus within the Odoo web application. The change optimizes a query number used in the test, resulting in faster and more reliable test execution. This improves the overall stability and responsiveness of the web module.
Original PR description
Forward-Port-Of: odoo/odoo#243298
This update corrects a flaw in a VoIP contact search test. Previously, the test could produce incorrect results due to using demo data. The fix ensures the test only evaluates data created within the test environment, leading to more reliable and accurate search results.
Original PR description
In the test, we suppose to find no phone number matched result when search term length is shorter than `_phone_search_min_length`. However, it can still match `name` or `email` if possible. In this fix, we change the test to only consider the data created in the test, to avoid the wrong result from demo data. backport odoo/enterprise#101200 Forward-Port-Of: odoo/enterprise#104120
This update fixes an issue where loyalty programs with pricelist restrictions weren't consistently applied in the POS. Previously, if a POS session's pricelist didn't match a loyalty program's restrictions, the program wouldn't be applied. Now, loyalty programs with restrictions will correctly filter applicable discounts in the POS, ensuring accurate pricing.
Original PR description
Before this commit, if a loyalty program had pricelist restrictions, the POS would not consider them when loading the applicable loyalty programs. This could lead to scenarios where a loyalty program was applied in a POS session even if the session's pricelist was not allowed by the program. This happened when the pricelist was also not available in the POS configuration and program.pricelist_ids was empty. opw-5467990 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242279
This update fixes several issues within the o_spreadsheet component, ensuring it's aligned with the latest version of Odoo 18.4. The changes improve the spreadsheet's performance and functionality, particularly related to calculations and data selection. This ensures a stable and reliable spreadsheet experience for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0364f563a [REL] 18.4.24 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0364f563a [REL] 18.4.24 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/b456055e0 [FIX] Pivots: Recompute measure on indirect dependency update [Task: 5349782](https://www.odoo.com/odoo/2328/tasks/5349782) https://github.com/odoo/o-spreadsheet/commit/cfc56f825 [FIX] demo: add import osheet [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/060d8d456 [FIX] f&r: the searched range should follow the active sheet [Task: 5423885](https://www.odoo.com/odoo/2328/tasks/5423885) https://github.com/odoo/o-spreadsheet/commit/efe0d5b6f [FIX] Composer: Capture the correct selection on `F2` [Task: 5462713](https://www.odoo.com/odoo/2328/tasks/5462713) 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>
This update fixes a scheduling issue in the autovacuum cron job that was causing delays in database maintenance. The change ensures the cron job correctly reports partial progress, allowing for timely rescheduling. This improves the efficiency and reliability of database upkeep.
Original PR description
**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. Have…
**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. Have a ir cron action with the following code: time.sleep(MIN_TIME_PER_JOB) self.env['ir.cron']._commit_progress(remaining=1) return The code looks stupid, but we tracked down a bug we had in the autovacuum cron in 18.3, and the minimum code to reproduce the problem is that above line of code. Since there are remaining stuff to do, the cron worker should report a `PARTIALLY_DONE` status, and reschedule to call the cron action asap. But the system currently determine a `FULLY_DONE` status and reschedule the cron action *later* (next day for a cron with an interval of 1 day). It is pretty bad for the autovacuum cron in 18.3 We used the opportunity to rework the `status` computation to one big match-case, for extra readability. 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
This update resolves a problem where clients were incorrectly using outdated number ranges when syncing data with DIAN. The fix ensures that the latest, valid number range provided by DIAN is always used, preventing invoice errors and improving data accuracy. This impacts invoice processing with Colombian DIAN regulations.
Original PR description
**PROBLEM** When a client has exhausted a number range for a prefix, if he request a new one, when trying to sync the DIAN data the old range will be use instead of the new one. **STEP TO REPRODUCE**…
**PROBLEM** When a client has exhausted a number range for a prefix, if he request a new one, when trying to sync the DIAN data the old range will be use instead of the new one. **STEP TO REPRODUCE** According to the DIAN documentation, the GetNumberRange service is only available in the production environment. So i'm not sure if we can safely test this. The repro steps would be something like: 1. Request a range. 2. Exhaust all number from this range by sending invoices to DIAN. 3. Request a new range. 4. sync with DIAN. (notice the range selected is still the old one). 5. Try sending a new invoice to DIAN and notice there is an error. **CAUSE** In `l10n_co_dian/models/account_journal.py` the function `_l10n_co_dian_get_journal_values()` loops on all the xml `NumberRangeResponse` node and store the last range values encountered for each prefix. We don't check if the this last range is still valid, if it's the newest created (could be checked with the xml field `ResolutionDate`, but the date could be the same if the range were created the same day), if it's the latest in term of number range (DIAN start with range 1-100, then 101-something etc.). Forward-Port-Of: odoo/enterprise#103943
This update corrects a minor issue in the demo data for the recruitment module. Previously, the system was incorrectly referencing user records instead of partner records, which caused problems with the demo data. This fix ensures the demo data accurately reflects the expected data structure, improving the usability of the demo.
Original PR description
author_id expects a res.partner record. In this commit: Replace the user record with the corresponding partner record to avoid passing an incorrect recordset in demo data. Forward-Port-Of: odoo/odoo#241260
This update resolves an issue where users could incorrectly modify attendance records for employees they didn't manage. The change ensures that unauthorized updates are blocked, preventing data inconsistencies and maintaining accurate attendance tracking. Test coverage has been added to guarantee this fix.
Original PR description
Closes [odoo/odoo#226007](https://github.com/odoo/odoo/issues/226007). Description of the issue/feature this PR addresses: Prevents a user from updating their attendance record by changing the employee to the one whose attendance is not managed by the current user. Current behavior before PR: - Assign the Officer Group of Attendance group to a user. - Assign the user as the attendance manager of itself. - Login with that user. - Create an attendance record for the employee and save it. - Try to change the employee and save; an error will be thrown as expected. - Go to the Attendance menu; the record will still be saved. Desired behavior after PR is merged: This commit ensures that un-allowed write does not take place + test coverage added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243573 Forward-Port-Of: odoo/odoo#226335
This update corrects a bug that occurred when a leave request was linked to a refused allocation and the system's automated cleanup process ran. Specifically, an error was triggered due to an empty data structure, preventing the system from correctly processing leave requests. This fix ensures the system handles refused allocations without causing errors.
Original PR description
When a leave is linked to a refused allocation and the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs. Steps to reproduce the error: - Install ``hr_holidays`` without demo data -…
When a leave is linked to a refused allocation and
the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs.
Steps to reproduce the error:
- Install ``hr_holidays`` without demo data
- Create a new Time Off Type > Time Off Requests, Approval: No Validation >
Allow Negative Cap: True > Maximum Excess Amount: 2
- Create an Accrual Plan using default values
- Create a New Allocation
- Allocation Type: Accrual Allocation
- Set the Time Off Type and Accrual Plan created above
- Allocation: 1 day > Approve
- Create a new Time Off in the near future (in the current month) and select the Time Off Type created above
- Go back to the Allocation > Refuse
- Run the cron ``Time Off: Cancel invalid leaves``
Traceback:
``IndexError: list index out of range``
https://github.com/odoo/odoo/blob/bc5f24195a486112574900015ecbcf0e3ba32145/addons/hr_holidays/models/hr_leave.py#L1535-L1536
Here, ``leave_type_data`` becomes ``defaultdict(<class 'list'>, {})``
because when the allocation is refused and the cron runs,
the ``get_allocation_data`` method returns an empty defaultdict.
As a result, accessing the index leads to the above traceback.
sentry-6874651972
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243505
Forward-Port-Of: odoo/odoo#227201This update corrects a bug where menu entries were incorrectly linked to the last created page, even when multiple pages with the same name were created. Now, menu entries are only updated when a new page is created, ensuring accurate page linking and a consistent user experience. This prevents confusion and ensures correct navigation.
Original PR description
With commit 19302cd40347065fcd937bd54e6dce27fe4940cc, when a page is created, menu entries with a url corresponding to the created page are updated to set their `page_id` to the new page. The update may also be triggered when creating several pages with the same name in a row. This commit updates a menu entry on page creation only if no page were already associated to the menu. Steps to reproduce: - Create a new page, call it "test" (will be available on `/test`) - Create a new page, call it "test" (will be available on `/test-1`) - Go to editor menu - Bug: both entries point to `/test-1` - Create a new page, call it "test" (will be available on `/test-2`) - Go to editor menu - Bug: the first one (and the new one) is pointing now to `/test-2` task-5186653 Forward-Port-Of: odoo/odoo#243312
This update corrects a potential issue with how payroll data is locked for tax reporting in Switzerland (ELM transmission). By using a reference date, the system now accurately reflects the period for which data is secured, ensuring compliance and reliable reporting. This change enhances the accuracy of Swiss tax filings.
Original PR description
Forward-Port-Of: odoo/enterprise#104269
A recent update to Odoo's website functionality caused a test to fail intermittently. This fix ensures that snippets dropped during a tour are properly removed from popups, preventing errors and improving the stability of the tour experience. This was triggered by a performance optimization introduced in a previous release.
Original PR description
**Problem** Before this commit, the tour `test_03_snippets_all_drag_and_drop` could fail with the error `Element (:iframe .o_snippet_preview_wrap[data-snippet-id="s_popup"]) has not been found`. The…
**Problem** Before this commit, the tour `test_03_snippets_all_drag_and_drop` could fail with the error `Element (:iframe .o_snippet_preview_wrap[data-snippet-id="s_popup"]) has not been found`. The failure was reproducible locally and appeared non-deterministically on runbot. **Cause** The tour steps could occasionally execute too quickly, leading to non-determinist behavior where snippets were dropped inside a popup that had been inserted but not yet closed. When the dropzone is inside an open popup, some snippets (e.g. `s_popup`) are excluded from the Snippet Viewer, resulting in the error reported above. **Solution** The tour flow is modified such that popup snippets are removed after being dropped, as already happens for every other snippet category. This completely removes the risk that new snippets are dropped into a popup. **Note** This bug was already fixed starting from version 19.0 by [1]. The performance boost indroduced by [2] made the same bug appear also on 18.4, thus the need for this commit. [1]: https://github.com/odoo/odoo/pull/242231 [2]: https://github.com/odoo/odoo/pull/243102 runbot-233328
This update fixes an issue where follower list menus displayed avatars with incorrect aspect ratios, particularly for non-square images. The change utilizes a standard Odoo class for avatars to ensure consistent and proper image scaling, improving the visual appearance of follower lists. This ensures all user avatars look their best.
Original PR description
Before this commit, follower list menu had avatar that do not preserve ratio of avatars. This is noticeable for avatars that have ratio quite different from 1:1, like 3:2 or 2:3 or even less squarish. This happens because of missing `.o_object_fit_cover`, that [1] erroneously removed from REF of follower template part into its own component. This commit uses an equivalent but more official solution: `.o_avatar`, which is a classname dedicated for avatars, which has `.o_object_fit_cover` property. Task-5412078 Before / After <img width="638" height="526" alt="Screenshot 2026-01-12 at 17 23 54" src="https://github.com/user-attachments/assets/b8d3a921-52a8-48b7-a0d0-5fbfdd33a92c" /> <img width="640" height="528" alt="Screenshot 2026-01-12 at 17 23 33" src="https://github.com/user-attachments/assets/8070420c-f341-4085-bcb2-2fba060765f0" /> [1]: https://github.com/odoo/odoo/pull/200382 Forward-Port-Of: odoo/odoo#243328
This update fixes an issue where the original invoice information wasn't correctly displayed when reversing invoices. Previously, the 'Source Document' field in the invoice list was blank after a reverse move. This change ensures that the correct source invoice is always visible, improving accuracy and traceability of financial transactions. It resolves a regression introduced in a previous update.
Original PR description
### Issue: Reverse moves miss `invoice_origin` field. #### To reproduce: 1- Create a SO. 2- Create an invoice and confirm. 3- In invoice list view make the `Source Document` visible. 4- Create a credit note and reverse the move. From invoice list view, you can observe that `Source Document` is empty for reverse move. ### Cause: This is a regression introduced by #236656. opw-5362055 Forward-Port-Of: odoo/odoo#240439
This update corrects a bug where manually changed currency rates on invoices weren't updating correctly, leading to lost data. Now, the system only recalculates rates if the user hasn't modified them, preserving user input. This ensures invoices with different dates accurately reflect the intended currency rates.
Original PR description
in case the user would enter manually a different rate than the default one, but does not fill the invoice date; odoo was setting today as the invoice date, which was changing the rate and recomputing all the lines... Effectively losing everything the user just encoded. So now, we only recompute the rate and the lines if the user didn't change it. Fix: https://github.com/odoo/odoo/pull/226124/changes/1b48d141d7260a262075555c4ab9cedc691d3551 Issue with Fix: Invoices posted on dates different from their creation date do not update their currency rates, even though they should. Comparing `invoice_currency_rate` to the expected rate at creation is a better guess. task-5477481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243126 Forward-Port-Of: odoo/odoo#242800
This update corrects a bug where matching a partner by bank account could be overwritten by a subsequent match found through the partner's name. This ensures that the correct partner is always associated with bank statements, improving data accuracy and reliability. It addresses a potential issue with duplicate partner records.
Original PR description
Ensure the retrive partner from partner name doesn't override the retrieve partner from bank account. When retrieving a partner on an st_line, we first check for a match based on the bank account, and then on the partner name. However, we fail to check if a match was already found before searching by name. This means that if a partner is matched via bank account, and subsequently another match is found via name, the first match gets overridden by the second one. This commit adds a check for st_line.partner_id before attempting further matching, preventing the previous result from being overridden. no-task Forward-Port-Of: odoo/enterprise#103648
This update fixes a dashboard warning issue where employee data wasn't being displayed correctly in payroll exports. The changes ensure that all employee data, including version codes, is accurately reflected, resolving a previous omission of the 'acerta' code and improving data consistency.
Original PR description
\* = {acerta, group_s}
Dashboard warnings opened a contract template containing the version data of the employee, while not showing employee's name or id, this commit changes the redirected view to a list of employees that do not have the version id's export code. This commit also solves an issue of not showing acerta code of the version
task: 5212681This update ensures salary configuration personal information is automatically populated using the employee's most recent version, regardless of whether it's a standard offer or a contract template. This eliminates manual data entry and ensures accurate salary settings for all employees, streamlining the offer creation process.
Original PR description
The personal informations in the salary config is prefilled using the version selected in the offer. When making a new offert for an already employed person, the default version is the last active version, the address and other personal info are already set on that version and the salary has the last up-to-date data. But when selecting a contract template in an offer, the version does not have the personal info from the employee (as it's a template). In this commit, we force to use the employee itself (from the active version of the employee, or the employee linked to the contract template copy - created during the offer creation). may it be an applicant or an existing employee, when an offer is generated, an employee is created (or re-used) and set on the contract template. So it works in every case. Taks-5162703
This update corrects an issue where payslip names were not being generated accurately for the Swiss (l10n_ch_hr_payroll) module. The fix ensures that payslip names now display correctly, improving the accuracy of payroll reporting and data for Swiss users. This ensures consistent and reliable payroll information.
This update resolves an issue where failed IoT driver actions were incorrectly recorded, preventing them from being re-executed. By only registering successful actions, we enhance the reliability and efficiency of the IoT driver system. This change improves the overall stability of the Odoo platform.
Original PR description
We currently reject an action if it has the same id of a previous one. If the action failed, we still registered it, making it impossible to be executed again. We now only register if the action succeeds.
This update resolves an issue where payment reports were inconsistently using different export formats (NACHA or last installed module). The fix ensures that payment reports now automatically use the correct format based on the company's localization, improving report accuracy and usability for users. The change is being backported to version 18.0.
Original PR description
\* = l10n_{ae, au, ch, in, sa, us}_hr_payroll + hr_payroll_account_iso20022
Issue:
The current behavior looks deterministic: when clicking on "Create Payment Report" it -sometimes- shows the current company's export format by default, other times it shows the "NACHA" type. Or it could be the last installed module's export format value for the other companies.
Solution:
I fixed it in this PR: https://github.com/odoo/enterprise/pull/93683 and now backporting the changes to version 18.0
task-5189295
Forward-Port-Of: odoo/enterprise#103864
Forward-Port-Of: odoo/enterprise#100126This update resolves a technical problem preventing order details from being correctly saved in the Odoo POS system for the Swedish localization. The fix involves renaming related fields in the user interface to ensure data is properly recorded in the database. This ensures accurate order tracking and reporting.
Original PR description
In commit 807420a, the `pos.order` fields in `pos_l10n_se` were renamed to add `sweden_` at the start. However, these fields were not renamed in the JS code. The result is that the fields were not being saved to the DB. This commit fixes the issue by renaming the fields in the frontend. It also adds some fixes to ensure compatibility with the newest IoT box image. opw-5253585 Forward-Port-Of: odoo/enterprise#104218 Forward-Port-Of: odoo/enterprise#104180
This update fixes an issue where customer statements incorrectly showed an outstanding balance after a payment was made on an invoice. The fix ensures the system accurately considers partially reconciled amounts when determining follow-up actions for invoices and payments. This improves the accuracy of customer statements and reporting.
Original PR description
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the…
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the payment 5. Go to the customer record. 6. The Customer Statement smart button shows an amount due, but the followup status in the Accounting tab shows "No action needed". [Video (with different values, same result)](https://drive.google.com/file/d/1MFg-tUos-oGbk7SKn92OE8w0-PnObae7/view?usp=sharing) **Cause:** - The query in `_get_followup_data_query` checks an account.move.line's `balance`, ignoring amounts partially reconciled. [1](https://github.com/odoo/enterprise/blob/da8a0fb49861a5cfb366c85da459876ad1556924/account_followup/models/res_partner.py#L404) - In the example above, the sum of unreconciled balances is 100 - 120 = -20 due, where the amount_residual shows 100 -20 = 80 due. **Solution:** Use `amount_residual` instead of `balance` in `_get_followup_data_query`. This fix was applied last year to 17.0, but was never forward-ported to master. [2](https://github.com/odoo/enterprise/pull/77679) [opw-5216007](https://www.odoo.com/odoo/project.task/5216007) Forward-Port-Of: odoo/enterprise#101874
This update resolves an issue where the height of image gallery snippets would unexpectedly reset when images were reordered. The fix ensures users can set and maintain custom heights for gallery snippets, providing consistent control over their appearance. Additionally, minor template issues have been addressed.
Original PR description
Steps to reproduce Scenario A 1. Go to Website → drop an Image Gallery snippet → A default height value appears in the `"Height"` input. 2. Select an image → change its order in the carousel → The…
Steps to reproduce Scenario A 1. Go to Website → drop an Image Gallery snippet → A default height value appears in the `"Height"` input. 2. Select an image → change its order in the carousel → The snippet height is automatically reset to `70%` of the screen height. Scenario B 1. Change the height value of the snippet from the `"Height"` option. 2. Select an image → change its order in the carousel → The snippet height is again reset (and the option value is overridden). Issue The original height behavior was introduced in [1] to make the slideshow mode auto-adapt to `70%` of the viewport height. This diff also removed height CSS for other modes where the height should depend on the content [2] Subsequent adaptations: [3] added a default height (`500px`) in XML, [4] removed it during a design refactoring, [5] restored the possibility to control the height of the image gallery snippet using the `"Height"` option. Keeping the same JS logic that forces the snippet height, led to the behavior explained above: even when the user manually sets a height, any action triggering `slideshow()` (e.g., image reorder) forces the height back to 70% of `window.innerHeight`. Fix 1. Remove the outdated JS code that automatically updates the height. 2. Keep the slideshow behavior consistent with [2] by excluding it from the height CSS removal logic. The snippet now starts with a default height and only changes when edited through the `"Height"` input. Additional fixes This commit also fixes a few minor issues in the new carousel items template introduced in [4]: items having an `"undefined"` class, and a missing margin style in the main snippet template. [1]: https://github.com/odoo/odoo/commit/239b6bc0b5a2a644486737f2b0b71e7e6c0a2edf [3]: https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7 [4]: https://github.com/odoo/odoo/commit/9042b1cae7b630b20e0670788b7a4ed9e4c97609 [5]: https://github.com/odoo/odoo/commit/d5d138e833344e857a420d865d4b12f1acdb0e7c task-3414281 Forward-Port-Of: odoo/odoo#242385 Forward-Port-Of: odoo/odoo#126766
This update simplifies the process of generating UBL invoices for Colombia and Mexico by refactoring internal code and streamlining the UBL 2.0 builder. The changes ensure correct customer/supplier order for vendor bills and improve the flexibility for future updates to these specific tax modules.
Original PR description
For the Self-billing backport, we made two modifications which entail a small change in the l10n_co_dian and l10n_mx_edi code: - `_check_move_constrains` has been refactored to call a new `_get_move_constraints` method, which is more easily extensible. We perform the same modification in l10n_mx_edi. Note `_check_move_constrains` is still there, so any overrides will still work. - The customer and supplier are now swapped by default when exporting a vendor bill UBL, so it's no longer needed to do this specifically for the DIAN UBL. Community PR: https://github.com/odoo/odoo/pull/232548 Backport of https://github.com/odoo/enterprise/pull/92205 task-5153851 Forward-Port-Of: odoo/enterprise#97803
This update ensures that the print wizard always closes correctly, regardless of whether a custom report handler (like for IoT) is used. Previously, using a custom handler would prevent the wizard from closing after a report download, leading to unexpected behavior. This fix maintains a consistent user experience across all report printing scenarios.
Original PR description
Problem: When an alternate ir.action.report handler is used (such as for IoT), the logic to close the wizard after the report is downloaded (printed) is skipped, so the wizard stays open. Steps to Reproduce: - Go to "Acoustic Bloc Screens" product and click "Print Labels" - Select "ZPL labels" and confirm - The report downloads and the wizard closes as expected - Go to Settings > Technical > Reports and select "Product Label (ZPL)" - Set an IoT device on the report - "Print Labels" again, selecting a printer and the IoT toasts in the top right appear after the wizard closes - Refresh the page, and try printing again - The wizard stays open (wrong) and the IoT toasts appear Solution: When returning from the custom handler, check if close_on_report_download and close the wizard. opw-5153139 Forward-Port-Of: odoo/odoo#242045 Forward-Port-Of: odoo/odoo#238247