Daily updates from Odoo
Monday, May 4, 2026
31 changes · saas-19.1
Enhancements to existing features
This update adds the delivery address to the TicketScreen in Point of Sale. This allows sales teams to quickly view and confirm the correct delivery address while scheduling deliveries, streamlining the order fulfillment process. It's a small change designed to improve efficiency and reduce errors.
Original PR description
In this commit: =============== - Added address details on the TicketScreen when the order preset identification type is `address`. - This helps to easily see the delivery address while scheduling the delivery. Task-5974595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251389
This update automatically sets the first available printer as the default for Point of Sale transactions. This simplifies the setup process for users and ensures that receipts are always printed without requiring manual selection. Additionally, quick creation of printer settings has been restricted to improve data consistency.
Original PR description
Following this commit: ===== - Set first printer as default printer from the list configured. - Updated the help tooltip. - Added placeholder "None" to field product_categories_ids. - Restrict quick create for `receipt_printer_ids` and `default_receipt_printer_id` for pos.config and res.config.settings views task-5494313
Resolved issues and error corrections
This update simplifies the selection of tax rates on invoices for Saudi Arabia (l10n_sa). Previously, incorrect tax selections led to compliance issues. This change ensures the correct tax rates are applied based on supply characteristics, resolving a potential regulatory problem.
Original PR description
This commit aims to make the invoice line tax drop-down cleaner and more straightforward. The tax `15% PH PE HS` is already handled through the `0% PE` and `0% PH` taxes and `0% Not Subject to VAT`…
This commit aims to make the invoice line tax drop-down cleaner and more straightforward. The tax `15% PH PE HS` is already handled through the `0% PE` and `0% PH` taxes and `0% Not Subject to VAT` is visible with the other `0%` taxes such as `0% EX G`, etc. The users were incorrectly selecting the `0% Not Subject to VAT` instead of the actual `0%` taxes according to the characteristics of the supply; leading to non-compliance with the ZATCA rules. Before this commit: - `15% PH PE HS` tax was `active`. - `0% PE & 0% PH` had distribution for invoices: `base tax grid = 3(B)` and distribution for refunds: `base tax grid = 3(B)`. - `0% Not Subject to VAT` tax was `active` and had distribution for invoice: `base tax grid = 3(B)` and distribution for refunds: `base tax grid 3(B)` - `0% IT G and 0% QT` taxes were `active`. After this commit: - `15% PH PE HS` tax is `inactive`. - `0% PE & 0% PH` taxes have distribution for invoices: `base tax grid = 2(B)` and distribution for refunds: `base tax grid = 2(B)` - `0% Not Subject to VAT` tax is set to `inactive`, `sequence = 17` and tax grid has been removed. - `0% IT G and 0% QT` taxes have been set to `inactive`. task-5959979 Forward-Port-Of: odoo/odoo#253598
This update enhances the accuracy of write-off reconciliation within the accounting module. It now filters reconciliation models to only display those that are manually created or directly linked to the statement lines' journal, preventing errors caused by unrelated journal associations. This ensures reconciliation reports are more reliable and trustworthy.
Original PR description
In the account reconciliation wizard: - Only show manually created reconciliation models. - Only display reconciliation models that are not linked to any journal or are specifically linked to the journal of the statement lines. task-6059342 Forward-Port-Of: odoo/enterprise#111644
This update fixes an issue where applying a global discount and a gift card resulted in an incorrect order total. The system was incorrectly adding back a portion of the gift card amount as a discount. The fix ensures gift card deductions are handled properly, preventing this calculation error.
Original PR description
Applying a global order discount and then paying with a gift card (or eWallet) caused the POS to recompute the global discount as if the gift card deduction were part of the taxable merchandise base.…
Applying a global order discount and then paying with a gift card (or eWallet) caused the POS to recompute the global discount as if the gift card deduction were part of the taxable merchandise base. The negative reward line was included in `isGlobalDiscountApplicable()`, so the percentage discount shrank and the order total increased by “global_discount% × gift card amount” (e.g. 10% of $50 → $5 added back). Steps to reproduce: ------------------- * Open PoS with global discount and a gift card / eWallet program. * Add a product (e.g. $100), apply a global discount (e.g. 10%). * Apply a gift card for part of the balance (e.g. $50). > Observation: Total is wrong (e.g. $45 instead of $40): the gift card amount is reduced, then a fraction of that amount is added back via the recomputed global discount line. Why the fix: ------------ `pos_discount` only skips tip and discount-product lines; gift card reward lines use another product and were still “discountable”. The fix belongs in `pos_loyalty`: override `isGlobalDiscountApplicable()` to return false only for gift card and eWallet reward lines (`isGiftCardOrEWalletReward()`), and fall to `super` otherwise so promotion/loyalty reward behavior stay correct. opw-6104090 Forward-Port-Of: odoo/odoo#259577
This update fixes a critical issue preventing the correct import of PINT invoices for Australia, Japan, Malaysia, Singapore, and New Zealand. By adding logic to identify these specific UBL document types, the system now accurately processes and imports these invoices, ensuring data integrity and compliance.
Original PR description
## PINT modules (`l10n_*_ubl_pint`)
The UBL module wasn't able to import PINT documents because there was no logic to detect the type of UBL document for PINT invoices (`urn:peppol:pint:billing-1@{anz, jp, my, sg}-1`). This PR adds the methods to detect PINT UBL documents and provide appropriate EDI decoder model names. Along with the fix, test cases are added to verify proper import of the said UBL's.
## Base EDI module (`account_edi_ubl_cii`)
Additionally, `_correct_invoice_tax_amount` in the base UBL import is fixed to only process TaxSubtotal nodes in the document currency. Previously it iterated over all `TaxTotal/TaxSubtotal` nodes regardless of currency, which caused the JP PINT import to pick up the company-currency tax amount instead of the document-currency one. JP PINT is the only format that includes TaxSubtotal in both TaxTotal nodes.
Forward-Port-Of: odoo/odoo#258017This update resolves an issue preventing users from canceling invoices through the ECPay integration. The fix adds necessary permissions to access a key configuration field, ensuring the cancellation wizard functions correctly for all user roles. This prevents a disruption in invoice processing.
Original PR description
Before this commit, the invoice cancellation wizard failed when clicking "Request Cancel" because l10n_tw_edi_ecpay_staging_mode lacked sudo access, while similar fields had it. The cancel wizard (l10n_tw_edi.invoice.cancel) needs to read this field to determine the API endpoint, but non-superuser accounts couldn't access it, causing a permission error. This commit adds sudo() when accessing staging_mode, consistent with other ECPay API configuration fields. Steps to reproduce: - Install l10n_tw modules with ECPay staging credentials (MerchantID: 2000132) - Use valid Tax ID (10430481) to create and send invoice - As Accounting/Administrator user, cancel the invoice - Access error occurs on button_request_cancel opw-6101478 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the namespace for DIAN credit notes was incorrectly configured, causing errors when submitting to the DIAN tax authority. The change ensures the correct namespace is applied to the credit note, resolving a recurring problem identified in previous development. This ensures accurate and compliant electronic filing of credit notes for Colombian companies.
Original PR description
Issue: Incorrect `sts` namespace raises several issues when sent to dian Steps to reproduce: - On a Colombian company - Create a credit note - Send to DIAN Current Behavior: - Credit note have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1` while their Extension node has another `sts` namespace to `http://www.dian.gov.co/contratos/facturaelectronica/v1/Structures` Expected Behavior: - Only the top level Node should have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1`. It was forgotten that Credit Note were part of the Invoices in the last refactor. As it's the second time(odoo/enterprise#68619 3rd commit) it happens, I updated the test. opw-6077050 Forward-Port-Of: odoo/enterprise#114725 Forward-Port-Of: odoo/enterprise#113643
This update fixes an issue where closed Helpdesk tickets were sending out emails with the ticket's database ID instead of the reference number. This ensures that customers receive consistent and accurate information about their ticket status, improving communication and transparency. The change updates a key email template to use the correct ticket reference.
Original PR description
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the…
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the "Helpdesk: Ticket Received" mail template; Observe that the correct reference (100) is used. (Open the full composer to use "Load template") 4. Now send a message using the "Helpdesk: Ticket Closed" mail template and Observe that it displays the database ID (e.g., 1) instead of the reference. Cause: ------ `new_ticket_request_email_template` uses the ticket reference(`object.ticket_ref`) correctly. https://github.com/odoo/enterprise/blob/d39e291ba89ad018ba6f5f9591d280a834822f27/helpdesk/data/mail_template_data.xml#L18-L19 However, the `solved_ticket_request_email_template` uses the database ID (`object.id`) instead of the actual ticket reference (`object.ticket_ref`), leading to inconsistent references in customer communications. related commit: 3ed5273 Solution: --------- Update `solved_ticket_request_email_template` to use `object.ticket_ref` instead of `object.id` opw-6087466 Forward-Port-Of: odoo/enterprise#114852 Forward-Port-Of: odoo/enterprise#113932
This update corrects a previous issue where loyalty point transactions in a single POS order were only recorded as a net difference. Now, the system accurately tracks both the points earned and the points spent, providing a complete and precise history of loyalty card activity. This ensures accurate reporting and better customer understanding of their loyalty points.
Original PR description
When a loyalty card both earned and spent points in the same POS order, the history entry only reflected the net difference instead of the gross amounts. The root cause was that the JS payload sent only a single `points` field representing the net change. Fix by tracking `points_earned` and `points_spent` separately in `couponData` and sending them to the server. opw-6041420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261399 Forward-Port-Of: odoo/odoo#256022
This update addresses a user experience issue where a lingering Point of Sale session remained active after a user closed their browser tab or navigated away. This caused confusion for users. The fix ensures that sessions are properly terminated when the Point of Sale is no longer in use.
Original PR description
When the user closes the browser tab or navigates away after a session in opening_control, the session is not deleted and it causes confusion. opw-6114420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261207 Forward-Port-Of: odoo/odoo#258933
This update corrects a problem where lingering Point of Sale sessions in the opening_control module persisted after a user closed their browser tab. This prevented proper session cleanup, leading to potential confusion for users. The change ensures sessions are automatically terminated when a user navigates away, improving the overall user experience.
Original PR description
When the user closes the browser tab or navigates away after a session in opening_control, the session is not deleted and it causes confusion. opw-6114420 Forward-Port-Of: odoo/enterprise#115056
This update optimizes how prices are calculated in Point of Sale, resolving a previous issue that caused unnecessary and costly calculations. By using a smarter system, we've significantly reduced the strain on our system and improved the speed of order processing. The changes also ensure price data is handled efficiently in production environments.
Original PR description
Calling triggerRecomputeAllPrices() synchronously on every orderline mutation (create, merge, delete) caused the full tax/price computation to run 3 times per addLineToOrder call when a merge occurred, and triggered an expensive JSON.parse/JSON.stringify of the price data on each of those calls via logPosMessage. Replace the eager synchronous recompute with a microtask coalescer: the first call within a synchronous operation schedules a single Promise.resolve().then() microtask; subsequent calls within the same tick are no-ops. Because the microtask is queued before the outer await continuation (updatePrograms), _updatePrograms still reads fresh prices when it accesses line.prices. Also guard the args serialization in logPosMessage behind odoo.debug so the JSON deep-clone of the price data object is skipped entirely in production. opw-6091501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260436
This update resolves an issue where the system incorrectly skipped remuneration declarations in certain scenarios, particularly when employees had no worked days but still received a bonus. The fix ensures that all remuneration amounts are accurately declared, preventing potential discrepancies in payroll reporting for Belgian employees. This improves the reliability of the payroll process.
Original PR description
Forward-Port-Of: odoo/enterprise#106689
This update addresses a change in Sendcloud's API, ensuring continued delivery functionality for our users. We've added a key to requests, allowing our system to communicate with Sendcloud using the older, maintained API version. This ensures a seamless transition and continued delivery service.
Original PR description
Sendcloud pass their api v2 to maintenance and only provide new api V3 key to the new customers. In order to make a smooth transition for the user we add the partner key, so they know that the customer are coming from odoo and they use the v2 api. Future work will be done to upgrade our module and support the v3. API key. Forward-Port-Of: odoo/enterprise#114441
This update resolves an issue where duplicate Odoo databases would retain active connections to ARCA web services. This prevented users from properly testing in a development environment, potentially leading to production connections being used. The fix ensures ARCA connections are cleared when database credentials are updated.
Original PR description
Problem and Cause: When duplicating a database with existing ARCA connections, the connections to ARCA webservices are not cleared. Users using the duplicate database may not realize that the ARCA connections are still present. This may lead to production connections getting used while users are testing. Solution: Clear connections to ARCA webservices when updating the credentials. Forward-Port-Of: odoo/enterprise#115068
This update corrects a visual issue where positive time remaining values in task timesheets were incorrectly displayed in red, misleading users. The fix ensures that positive values are shown with the correct styling, and also addresses misalignment of time remaining data on sales orders. This improves the clarity and accuracy of timesheet reporting.
Original PR description
_* = sale_timesheet **Steps to reproduce:** - Open form view of any task. - Go to the Timesheets tab. - Observe the Time Remaining value. - Observe the Time remaining on SO. **Issue:** - The Time Remaining value becomes red even when the value is positive, which incorrectly suggests a warning. - The Time remaining on SO is not properly aligned. **Issue from :** - https://github.com/odoo/odoo/pull/192366 **Fix:** - Adjusted the logic to ensure the Time Remaining value is highlighted in red only when the value is negative. - Positive values now display with normal styling. - Adjusted the logic to ensure Time remaining on SO is displayed properly. **Task-id: 5404009**
This update adds logging of Amazon's request identifiers to the SP-API responses. Previously, this information was missing, making it harder for support teams to troubleshoot issues with Amazon. Logging this ID will significantly improve the speed and efficiency of support investigations.
Original PR description
Each response from Amazon's SP-API includes a request identifier used by their support team for debugging. This identifier was not previously logged, making support investigations more difficult. Forward-Port-Of: odoo/enterprise#114483
This update automatically allows users to reconcile bank statements from a parent company with related payments and invoices from its branches. Previously, reconciliation was limited to matching statements directly with company records. This enhancement streamlines the bank reconciliation process, making it easier to manage financial data across multiple locations.
Original PR description
The aim of this commit is allowing in the automatic reconciliation of bank reconciliation widget the possibility to reconcile statement lines from a parent company with moves (payments and invoices) from a branch. To do that, we are not only checking that the company between the AML and the statement line is the same, we are checking that there is a parent relation between the company of the AML and the statement line. opw-6056320 Forward-Port-Of: odoo/enterprise#114850
This update fixes a visual issue in the Timesheets section of the project shared form. Previously, the Time Remaining value wasn't highlighted in red when the amount was negative. This change ensures that negative time values are clearly indicated, improving accuracy and clarity for users.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** - Adjusted the logic to ensure the Time Remaining value is highlighted in red when value is negative **Task-id: 5404009** Forward-Port-Of: odoo/odoo#240489
This update corrects a visual inconsistency in the project timesheet interface. Previously, the 'Time Remaining' value wasn't highlighted in red when negative, even though the label was. The fix ensures that negative time remaining values are correctly displayed with a red color, improving clarity and accuracy for users.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** In hr_timesheet, the remaining_hours field has a decoration-danger applied In sale_timesheet_enterprise, this field is overridden as portal_remaining_hours So, Added the corresponding decoration-danger on portal_remaining_hours. task-5404009 Forward-Port-Of: odoo/enterprise#113632
This update resolves an issue where the full composer in the chatter didn't display the default email template's body. The fix ensures that the correct template body is loaded automatically, regardless of whether the user manually enters content in the composer. This improves the consistency and usability of email sending within Odoo.
Original PR description
**Issue:** - When opening the full composer from the chatter, the body of the default email template is not loaded. Only the subject line from the template appears, while the body remains empty or…
**Issue:** - When opening the full composer from the chatter, the body of the default email template is not loaded. Only the subject line from the template appears, while the body remains empty or contains only the user's signature. **Steps to reproduce:** 1. Install `contact` 2. Open any contact form. 3. In the chatter, click 'Send message' and then expand button 4. Write a something in body, then save this as a new template. 5. Set this new template as the default (using Debug Mode > Set Default Values). 6. Click 'Send message' in the chatter, 7. Click the 'Full composer' (expand) button without typing anything. **Observed behavior:** - The full composer opens with the correct subject from the default template, but the body is empty. **Cause:** - The `onClickFullComposer` method always passes a `default_body` value in the context to the mail.compose.message wizard. Even if the chatter input is empty **Solution:** - Forward isBodyEmpty in the context from onClickFullComposer. If the user typed content, do nothing. If the body is empty and a default template is available, allow the backend to apply the default template by removing default_body. opw-5405056 Forward-Port-Of: odoo/odoo#257277 Forward-Port-Of: odoo/odoo#239851
This update speeds up the process of writing to reconciliation models, a key task for managing financial records. By optimizing how the system handles large numbers of bank statement lines, the change significantly reduces processing time and memory usage, leading to a smoother and faster user experience.
Original PR description
When writing on reconcile models, the ORM fetches all the unreconciled bank.statement.lines then calls filtered on `unreconciled_statement_lines.line_ids`. In databases with a lot of unreconciled…
When writing on reconcile models, the ORM fetches all the unreconciled bank.statement.lines then calls filtered on `unreconciled_statement_lines.line_ids`. In databases with a lot of unreconciled statement lines scattered across multiple models, this `filtered` can be heavy, both in memory (fetching all the amls fields) and in time. This commit fixes this by using a search to prefilter the amls using the reconcile models in self. Then we filter the result on `suspense_account_id`. This greatly reduces the number of lines loaded up in memory and speeds up writing on reconcile models. ### speedup In a customer database with 484 042 statement.lines, 141 000 unreconciled statement.lines, 37 account.reconcile.model. Time to write on a reconcile_model. | Nbr linked unreconciled lines| Before PR | After PR | |:----------------------------:|:---------:|:--------:| | 702 | 40s | 3s | | 2000 | 40s | 4.47s | | 10000 | 40s | 11.28s | Since most of the slowness comes from the `filtered` call, the number of unreconciled statement lines linked to the reconcile.model being updated has no impact on the timing before this patch. ### memory For the 702 unreconciled lines case, the memory consumption goes - 2.2 Gb -> 200Mb. Forward-Port-Of: odoo/enterprise#115583
This update resolves an issue where the tax return dashboard wouldn't expand all groups, leaving some sections empty. The fix adds a setting to ensure all groups are initially displayed, providing a more complete and user-friendly experience when reviewing tax returns. This improves usability for users generating and analyzing tax returns.
Original PR description
When navigating to the tax return list view from the accounting dashboard, only the first few groups were expanded, leaving subsequent groups appearing empty with only a date header visible. Steps to reproduce: - Generate several tax returns. - Open the main Accounting dashboard. - On a Tax Return card, click one of the generated buttons. - Scroll down the resulting list view. Issue: After 10 groups, following sections appear empty, showing only the header Analysis: By default, the web client limits the number of automatically opened groups. This change adds 'max_number_opened_groups' to the buttons context, aligning the behavior with the primary 'Tax Return' button action. https://github.com/odoo/enterprise/blob/1a2afda205c41773747ed5f174d75843effbbe9f/account_reports/views/account_return_views.xml#L183 opw-5769978 Forward-Port-Of: odoo/enterprise#114673 Forward-Port-Of: odoo/enterprise#113332
This update corrects an issue where the EC Sales Report exported to KVR (a key reporting tool) displayed values with decimal places, which is not permitted for Swedish reporting requirements. The fix ensures all values are rounded to integers, aligning with local regulations and improving data accuracy for financial reporting. This resolves a previous reporting discrepancy.
Original PR description
**PROBLEM** EC Sales Report in Sweden needs to be reported with integer values. **STEP TO REPRODUCE** 1. Install l10n_se 2. On the se company, create a invoice with lines with EU tax and confirm it. 3. Go to Accounting/Reporting/EC Sale List and export to KVR. 4. Notices the KVR uses numbers with decimals places. opw-6045289 Forward-Port-Of: odoo/enterprise#115459 Forward-Port-Of: odoo/enterprise#114292
This update corrects a bug where invoices rejected by the Italian tax system (SdI) were incorrectly marked as 'sent,' preventing users from resubmitting them. The change automatically clears the 'is_move_sent' flag when an invoice is rejected, allowing invoices to be properly resubmitted after the issue is resolved. This improves the efficiency of invoice processing for Italian businesses.
Original PR description
When an invoice is rejected by the SdI or by a PA partner, the move remained flagged as sent, preventing the user from resending it after fixing the underlying issue. Override write() on account.move to clear is_move_sent whenever l10n_it_edi_state transitions to 'rejected' or 'rejected_by_pa_partner', so the invoice can be re-submitted. task-4490454 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#262075 Forward-Port-Of: odoo/odoo#260591
A previous issue prevented custom loyalty domains from functioning properly when using the Point of Sale (POS). This fix expands a system function to correctly handle many2many fields in loyalty domains, resolving a bug that blocked reward usage. This ensures loyalty programs are fully operational within the POS environment.
Original PR description
When you set many2many fields in a custom loyalty domain, when opening the pos a popup will open saying that the domain must be compatible with the POS.
Steps to reproduce:
-------------------
* Setup a loyalty program, as the reward it should be something like: 10% discount on specific products.
* Set a discount product domain: [("product_tag_ids", "not ilike", "test")]
* Open the pos
> Observation: A popup appears saying that the domain is not compatible with
the pos.
As a result this reward can never be used.
Why the fix:
------------
There's already a function responsible for chnaging `ilike` and `not ilike` with compatible pos operators `in` and `not in`. However this was only applied to `many2one` fields. We extand that.
opw-5990415
Forward-Port-Of: odoo/odoo#258560This update resolves an issue preventing correct December pay calculations within the Belgian payroll module. The migration to a new data structure caused a missing link in how pay information was recorded, leading to incorrect calculations. This fix ensures accurate December pay processing.
Original PR description
Purpose: after migrating to property inputs, the inputs for december pay weren't added to the properties definition so when you use `action_validate` in the december pay wizard, the values weren't written to these inputs as they don't exist in the definition task-id: 6103779
This update resolves an issue causing excessive logging within the Documents module, specifically when handling attachments. The change prevents unnecessary error handling and log spam related to URL type attachments, primarily impacting integrations and workflows that create attachments directly. This improves system stability and reduces unnecessary log volume.
Original PR description
Return None when datas is empty alongside the existing mimetype check. Avoids unnecessary exception handling leading to logspam for URL type attachments where binary data is unavailable. This issue is only reproducible programmaticaly as the mimetype is not available with url type attachment in Odoo. Thus, it's a problem that only impact third party integrations, EDI connectors or any workflow that creates ir.attachment records directly. opw-6010528 Forward-Port-Of: odoo/enterprise#113396
This update fixes an issue where invoices created in a branch environment with tax-included products didn't correctly calculate the unit price after applying a fiscal position. Previously, the price remained unchanged. This change ensures accurate tax calculations on branch invoices, improving financial reporting and compliance.
Original PR description
When operating in a multi-company branch environment, the unit price of a product with price-included taxes is not correctly recalculated when applying a fiscal position. Steps to reproduce: - Create a tax that is included in the price (e.g., 10% incl). - Assign this tax to a product (e.g., Product A). - Create a fiscal position that maps this 10% tax to a different tax. - Create a branch (child company) of your main company. - Create an invoice in the new branch using the fiscal position and add an invoice line for Product A. Issue: The unit price of the product on the invoice line remains the full tax-included amount rather than being reduced to exclude the original 10% tax. opw-5931302 Forward-Port-Of: odoo/odoo#262190 Forward-Port-Of: odoo/odoo#256897
This update prevents image uploads from failing due to excessively long filenames. The system now truncates filenames to a safe length (255 characters) to avoid exceeding server buffer limits, ensuring images load correctly. This resolves a previous issue where long descriptions caused 502 errors during image uploads.
Original PR description
## Problem: When generating a filename for a related studio image field, if the `name` is excessively long, the response header may exceed nginx's buffer size of 4kb, causing the request to fail. ## Solution: We will truncate the assigned filename for binary streams to the first 255 characters of whatever the assigned name would have been. ## Steps to reproduce (Runbot 18): 1. Open Studio editor on a Sales Order 2. Edit List View on Sale Order Lines 3. + Related Field, Product > Image, image widget 4. Make the description very long (close to 4000 characters) 5. Note the image will not load for that SOL, and the network tab shows a 502 error opw-5360952 Forward-Port-Of: odoo/odoo#258498