Daily updates from Odoo
Friday, May 22, 2026
44 changes · saas-19.1
New functionality added to Odoo
This update adds a new test to ensure the structure of payment data sent to our payment processor, Odoofin, remains consistent. This proactive step helps prevent unexpected changes on Odoofin's side and ensures we're always aware of any necessary updates to our system. It's a small change designed to improve reliability.
Original PR description
Add a test asserting the payment payload structure sent to Odoofin. The goal is to safeguard against unintended payload changes that are not handled on Odoofin's side by making such changes explicit during testing, and reminding developers that corresponding updates may also be required there. No task ID Forward-Port-Of: odoo/enterprise#117537 Forward-Port-Of: odoo/enterprise#117260
Resolved issues and error corrections
This update optimizes PDF report generation by compressing files after merging, reducing file sizes and memory usage. This addresses a previous memory leak and leverages newer PDF library versions for better performance, particularly with large reports. The result is faster report generation and smaller file sizes.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/odoo#264451 Forward-Port-Of: odoo/odoo#261879
This update optimizes PDF generation within Odoo by compressing merged documents, reducing file sizes and improving performance. It addresses a previous memory leak issue and leverages newer PDF library versions for better results. The change results in significantly smaller PDF files and faster processing times, particularly with large documents.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/enterprise#117308 Forward-Port-Of: odoo/enterprise#115550
This update resolves an issue where users without specific accounting permissions would encounter an error when loading certain knowledge article templates. The fix delays access to sensitive audit reporting data, ensuring that only authorized users can perform this action. This improves the stability and usability of the knowledge article feature.
Original PR description
Steps to reproduce: 1. Install `accountant_knowledge` with `demo data` 2. Remove demo user from bookkeeper access right and give some lesser right 3. Open knowledge and create a new artical with demo user 4. Click on Load template for example `Meeting Minutes` Issue: It gives a access error: `This operation is allowed for the following groups: - Accounting/Bookkeeper` Cause: - accountant_knowledge was doing accounting-only work during generic template loading. Immediately calling `target_article._get_inherited_audit_report()` that returns `inherited_audit_report_id`, which is a computed relation to audit report. `audit.report` is only readable by `account.group_account_user` Solution: - delay that access until it is actually needed, - only if the template contains data-embedded="accountReport" opw-6067390 Forward-Port-Of: odoo/enterprise#112946
This update corrects a bug where tax calculations were incorrectly split on discount lines, particularly when orders were set to the Quebec fiscal position. The fix ensures that taxes are applied correctly, avoiding duplicate tax displays and maintaining accurate financial reporting. This improves order accuracy and reduces potential accounting errors.
Original PR description
Steps to produce: --- - Install `website_sale`, `l10n_ca` & `accountant` modules with demo data. - Switch to a `Canadian (CA) company.` - Go to Settings and enable` Discounts, Loyalty & Gift Cards`.…
Steps to produce: --- - Install `website_sale`, `l10n_ca` & `accountant` modules with demo data. - Switch to a `Canadian (CA) company.` - Go to Settings and enable` Discounts, Loyalty & Gift Cards`. - Go to` Website > eCommerce > Loyalty > Discount & Loyalty.` - Create a new program > Set Program Type to Discount Code > Under Conditional Rules, set Minimum Purchase to 0 > Under Rewards, choose Discount on Order. - Go to `website > configuration > websites` > Create a new website for the CA company > Set it as default (first in sequence). - Create new product > Set Sales Taxes to` 14.975% GST + QST` > Publish the product. - Open the website in an incognito window > Add the product to the cart > Apply the discount code. - In the main tab > Go to Website > eCommerce > Orders > Open the corresponding order > In the Other Info tab, change the fiscal position to Quebec (QC) > Click to update taxes. Issue: --- - The tax on the discount line is split into: 14.975% GST + QST & 9.975% QST. Root cause: --- - When a discount is applied in the cart, the discount line initially carries split taxes: 5% GST and 9.975% QST. - After changing the fiscal position to Quebec (QC), the system replaces 5% GST with 14.975% GST + QST because 5% GST is present in replace of 14.975% GST. so at [1] it replaces 5% GST with 14.975% GST and do nothing for 9.975% QST. - In 17.0, the discount line directly uses 14.975% GST + QST (no tax splitting), so this issue does not occur. - In 18.0, at [2], taxes are explicitly split and added to the base line, and the same split taxes are reused during grouping. This leads to multiple taxes being displayed on the sale order line. Fix: --- - Avoid splitting taxes on the discount line in the sale order. - Keep the original tax structure intact to prevent duplication after fiscal position changes. [1]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/account/models/partner.py#L151-L156 [2]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/sale_loyalty/models/sale_order.py#L296 opw-6145674 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265233 Forward-Port-Of: odoo/odoo#262147
This update fixes an issue where the Point of Sale system incorrectly applied AvaTax fiscal positions even when AvaTax wasn't activated in the POS. The system now correctly ignores AvaTax fiscal positions when a customer doesn't have a configured fiscal position, ensuring accurate tax calculations. This prevents unintended tax application and improves POS functionality.
Original PR description
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make…
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one - Go to the settings of a point of Sale - Activate "Flexible Taxes" and configure "Default" and "Allowed" - Make sure that AvaTax fiscal position is not allowed - Do not activate "AvaTax PoS Integration" - Open a POS session - Select a customer with an address in the US and without fiscal position - Check the fiscal position **Issue:** The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS. **Cause:** We force the use of a fiscal position if it is configured on a customer. In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected. **Solution:** When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax. opw-6154089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263342
This update fixes an issue where the POS system incorrectly applied AvaTax fiscal positions even when AvaTax wasn't activated in the POS settings. The system now correctly ignores AvaTax fiscal positions when a customer doesn't have a defined fiscal position, ensuring accurate tax calculations for Point of Sale transactions. This improves the reliability of the POS tax functionality.
Original PR description
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make…
**Steps to reproduce:** - Install Accounting and Point of Sale - In Accounting settings, activate "AvaTax" - Configure the AvaTax fiscal position and activate "Detect Automatically" option - Make sure that the other fiscal positions don't have that option set or that they are ordered after the AvaTax one - Go to the settings of a point of Sale - Activate "Flexible Taxes" and configure "Default" and "Allowed" - Make sure that AvaTax fiscal position is not allowed - Do not activate "AvaTax PoS Integration" - Open a POS session - Select a customer with an address in the US and without fiscal position - Check the fiscal position **Issue:** The selected fiscal position is the AvaTax one even though AvaTax is not activated in the POS. **Cause:** We force the use of a fiscal position if it is configured on a customer. In this case, as no fiscal position is configured on the customer, we try to retrieve one that matches the condition and the AvaTax one is selected. **Solution:** When searching for the fiscal position of a customer, if AvaTax is not configured in the POS and if its fiscal positions are not allowed in POS, we ignore the fiscal positions using AvaTax. opw-6154089 Forward-Port-Of: odoo/enterprise#116626
This update ensures that event tickets are automatically created when an offline POS sale is later synced to the system. Previously, a page reload would cause the ticket creation to fail. The fix corrects a logic error in how the system manages offline order data, guaranteeing accurate ticket generation.
Original PR description
When selling event tickets in POS while offline, the order could be synced later but without creating event registrations (tickets) after a page reload. Steps to reproduce: ------------------- * Open…
When selling event tickets in POS while offline, the order could be synced later but without creating event registrations (tickets) after a page reload. Steps to reproduce: ------------------- * Open a POS session with `pos_event` * Sell an event ticket * Switch to offline mode * Validate payment while offline (order becomes paid but unsynced) * Reload/close and reopen POS, then reconnect * Let the order sync > Observation: The `pos.order` is created on the backend, but `event.registration` and `event.registration.answer` are missing so tickets are not generated. Why the fix: ------------ `pos_event` used `order.finalized` as IndexedDB cleanup condition for `event.registration` and `event.registration.answer`. For paid-but-unsynced orders, `finalized` is already true, so those records can be removed from IndexedDB too early. After reload, the order is restored/synced but without its event registration payload. Implementation: --------------- Use `order.canBeRemovedFromIndexedDB` instead of `order.finalized` for `event.registration` and `event.registration.answer` retention rules, so records are kept locally until the order is truly synced (server id assigned) or canceled. Test Note: --------------- Use case is hard to simulate exactly. Add a basic unit test to assert both registration models are kept for paid unsynced orders and only removable once synced. opw-6056079 Forward-Port-Of: odoo/odoo#265201 Forward-Port-Of: odoo/odoo#256615
This update resolves an issue where signed PDFs lost their original bookmarks and links, disrupting navigation and document integrity. The fix ensures that signed documents retain their original structure and functionality, allowing users to easily navigate and access information within the signed PDF.
Original PR description
Version - 18.0 Steps to reproduce: 1. Upload a PDF document containing bookmarks and internal/external links. 2. Sign the document and download the signed PDF. 3. Open the downloaded file and check the bookmarks and links. Issue: When a signed document was downloaded, the original PDF bookmarks And the links were not working. This broke structured navigation and affected document integrity. Fix: The PDF signing process has been updated to preserve the original bookmarks and ensure internal and external links remain functional after signing. Impact: - Signed documents remain navigable and consistent with the original PDF. - Preserves document structure and integrity. Task- 4915124 Forward-Port-Of: odoo/enterprise#117881 Forward-Port-Of: odoo/enterprise#108684
This update fixes an issue where Peppol-imported invoices weren't automatically shown in the chatter window alongside their attachments. The change ensures that the XML invoice files generated from Peppol are correctly linked to the chatter message, providing better visibility for users. This improves the tracking and management of these invoices.
Original PR description
**Steps to reproduce:** 1) Install l10n_be and configure Peppol demo mode. 2) Open debug mode, search for 'Peppol: retrieve new documents' in scheduled action. 3) Open the generated vendor draft…
**Steps to reproduce:** 1) Install l10n_be and configure Peppol demo mode. 2) Open debug mode, search for 'Peppol: retrieve new documents' in scheduled action. 3) Open the generated vendor draft bill. 4) Observe that the imported XML is present in attachments but not in chatter. **Cause:** In the (`_import_ubl_invoice_post_processing()`) https://github.com/odoo/odoo/blob/27cc9b920ad6818563b471dd3391548913790ef3/addons/account_edi_ubl_cii/models/account_edi_ubl.py#L3344 chatter attachments were built from: `self._import_attachments(invoice, collected_values['tree'])` This only includes embedded extra documents and emits the source imported XML attachment. As a result, the XML remained stored on the move (ubl_cii_xml_file) but was not linked to the chatter message. **Solution:** Include the source attachment when building the chatter attachment set. opw-6197738 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264399
This update fixes an issue where discounted UBL invoice lines were being incorrectly removed during import. Previously, lines with a zero total amount were filtered out, even if the supplier had applied a discount, leading to lost data. Now, the system correctly retains lines with zero totals or discounts, ensuring accurate reconciliation with original invoices.
Original PR description
`_import_ubl_invoice_add_base_lines` filters out every imported line whose `total_included_currency` is zero, on the assumption that a zero-amount line carries no useful information. This is correct for truly empty rows, but wrong for 100%-discounted lines, an ecotax or excise row, or a returnable-packaging entry nets to zero precisely because the supplier discounted it entirely, and the line still carries data the customer needs to reconcile the bill against the original document opw-6176349 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265284
This update fixes an issue where calls were not accurately reflecting the number of open tickets associated with their parent partners. Previously, open tickets on child partners weren't counted. Now, all open tickets linked to a call's parent partner are correctly displayed, providing a more complete view of support requests.
Original PR description
Unlike most of *_count fields on res.partner, for example ticket_count, open_ticket_count didn't take into account of its child partners. To reproduce: 1. create parent parent P and child partner C 2. create a ticket for partner C and put it in a unfold stage 3. call partner P and open form view of this call the open ticket count on the smart button is 0 instead of 1 In this commit, we change it that when a child partner has open tickets, they will also be counted as parent partner's. Forward-Port-Of: odoo/enterprise#115303
This update fixes a visual issue in the termination fees report, ensuring payslips have a clean and properly aligned layout. The previous design used a fixed row count that caused misalignment when fewer lines were present. The fix dynamically adjusts the layout for better readability and consistency.
Original PR description
**Steps to Reproduce:** 1. Generate a termination slip for an employee 2. The generated payslip pdf layout looks clumsy and misaligned. **Bug Cause:** 1. The notice duration has rowspan="3" expecting 3 lines. When there are less than 3 lines, the following rows are affected and misaligned. 2. The border is missing. **Solution:** Added dynamic sizing for notice duration instead of static rowspan="3". Used index instead of line_count for both notice duration and banks to stay consistent and simple. Added table-bordered class as borders are not automatically applied like in previous versions. **Task:** 6193558
This update fixes an issue where alternating row colors were incorrectly applied, often resulting in the table header and first row having the same background color. The change ensures alternating row colors are consistently applied to odd rows, improving the visual clarity and readability of tables within the HTML editor.
Original PR description
### Purpose of this PR: Previously, alternating row colors were applied on even rows. When a table header was enabled, the header row and first body row could end up sharing the same background color. This PR updates the alternating row logic to apply colors on odd rows instead. task-6204622 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where applying a combo to an order already sent to the backend would cause the original order items to reappear after a page refresh. The fix ensures that the order is synchronized with the backend after a combo is applied, providing a consistent and accurate view for the user.
Original PR description
Steps to reproduce: - Make an order that could be a combo - Send the order to preparation - Apply the combo - Refresh page => A new combo appears and the original orderlines are still there. Issue: When applying a combo to an order that has already been sent to the backend it is not synched with the backend so when you refresh the original orderlines are fetched from the backend. Fix: If the orderlines have been sent to the backend sync the order after applying the combo. 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 fixes a problem where Point of Sale orders weren't correctly calculating payments and invoices, leading to errors. The fix ensures that order details are properly updated during the validation process, resolving the 'No cash statement found' error and preventing 'entry not balanced' issues when generating invoices. This improves the reliability of the POS system.
Original PR description
### Steps to reproduce: - Download 'Point of Sale' and 'Contacts' app - Create a customer with a pricelist that includes a percentage discount - Create a shop with the following properties: - Default…
### Steps to reproduce:
- Download 'Point of Sale' and 'Contacts' app
- Create a customer with a pricelist that includes a percentage discount
- Create a shop with the following properties:
- Default preset = 'Takeout' with a standard 40hr/week schedule
- Payments = 'Card' and 'Customer Account'
- Pricelists = a 'Default' and the discounted pricelist
- Create a POS order (without choosing a customer)
- Add products to the order, and select 'Customer Account' payment method
- Select the created customer
* Pricelist applies → Order total decreases.
* Payment now exceeds total → Negative change shown.
- Disable 'Invoice' checkbox.
- Click 'Validate' → Show popup 'No cash statement found for this session.'
- Again click 'Customer Account' → Add another payment line (negative).
- Process the order payment
- Close Session
- Try to create an invoice for the order
> Error: Entry not balanced
### Cause of Issue:
When 'Validate' is clicked for the first time and `syncAllOrders()` is called, `serializeForORM()`
clears the `_dirty` state tracking after the serialization. https://github.com/odoo/odoo/blob/418b103dab782d81a33d2a7afd8ec3767d7a82df/addons/point_of_sale/static/src/app/services/pos_store.js#L1501-L1534
When the 'No cash statement found' error occurs, the backend rolls back the changes made to the
order lines.
Then, since the `order.lines` weren't marked as dirty (no changes occured to them) and `payment.ids`
were marked as dirty, when 'Validate' is clicked for the second time, the js side doesn't send the
`order.lines` again, so the backend uses the existing, undiscounted lines.
The mismatch happens because while the product lines are undiscounted, the `payment.ids` are
correct (because a new 'Customer Account' line was added, so `payment.ids` were sent again).
Hence, `amount_total` and `amount_paid` were calculated with discounts applied, while individual
`line.price_unit` values remained at list price, resulting in invoice line amounts not matching
the amount paid and causing "entry not balanced" errors during invoice generation.
### Fix:
Preserved the `_ dirty` state commands, ensuring that when the order is reserialized on retry,
the line data are included in the second `sync_from_ui` payload.
opw-6080597
Forward-Port-Of: odoo/odoo#259636This update resolves an issue where the delivered quantity for dropship products was incorrectly set to 1 before order confirmation. The fix ensures the quantity accurately reflects stock availability and triggers the necessary calculations when a purchase order is created, improving dropship order accuracy.
Original PR description
### Steps to reproduce: - In the settings enable dropshipping - Create a storable product P, enable the dropshipping and set a vendor - Create and confirm a sale order for a field service - Open the…
### Steps to reproduce: - In the settings enable dropshipping - Create a storable product P, enable the dropshipping and set a vendor - Create and confirm a sale order for a field service - Open the related task > Products > Add 1 unit of P - Go back to the sale order > an RFQ has been created #### > The delivered quantity of P is set to 1 ### Cause of the issue: Since 2361368acfe7fecbffde2ca26392eb89aecdc9e1 the `_inverse_fsm_quantity` method manually adapts the delivered quantity based on the fact that the `product.service_type` is `manual` rather than the `qty_delivered_method` of the line or future line is. In particular, because these lines: https://github.com/odoo/enterprise/blob/8f4fe902cb71c49bdb3caf9915f9a5abfe6f237f/industry_fsm_sale/models/product_product.py#L82-L83 provide a value of the `qty_delivered` to the created purchase order line and since the `qty_delivered_method` is a precomputed field: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L225-L237 The fact that the purchase order line will be created with a `stock_move` `qty_delivered_method` and that the generated PO does not generate any move prior to confirmation will not trigger the dependency of the `qty_delivered` to retrigger a computation of the `delivered_qty` of the product which is suppose to be based on stock pickings: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L871-L876 https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale_stock/models/sale_order_line.py#L193-L198 Leaving the created sol with a delivered quantity of 1 prior to confirmation of the PO (which will generate move_ids related to the sol and trigger the compute). Fix: The changes of 2361368acfe7fecbffde2ca26392eb89aecdc9e1 regarding the `_inverse_fsm_quantity` appears unjustified with respect to the purpose of the fix. In addition, the `qty_delivered` and changes are already expected to be properly computed when the `qty_delivered_method` is not manual, particularly since the '`manual'` `service_type` is actually the default `service_type` corresponding to any 'consu' product and looks unrelated by any mean to the `delivered_qty` computation: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/product_template.py#L165-L167 opw-6104326 Forward-Port-Of: odoo/enterprise#117727 Forward-Port-Of: odoo/enterprise#115760
This update fixes an issue where the End Balance figures in the Romanian Trial Balance reports were inaccurate when the report hierarchy was enabled. The fix prevents double-counting of account groups, ensuring the trial balance totals align correctly and provide accurate financial reporting for Romanian businesses.
Original PR description
### Issue before this commit: The total row for the End Balance columns in the Romanian 4-column and 5-column Trial Balance reports displayed incorrect values when the report hierarchy was enabled. ### Steps to reproduce the issue: 1. Downaload Accounting and l10n_ro 2. Switch to RO company 3. Go to Trial Balance report and be sure that Posted Entries, Accrual Basis are setted on Hierarchy and Subtotals 4. See that the End Blance both debit and credit is not correct ### Cause of the issue: The _custom_line_postprocessor method iterated over all report lines indiscriminately, adding account group subtotals to the running accumulator and causing duplicate counting. ### Reason to introduce the fix: To eliminate group double-counting and providing consistency with the totals in all the trial balances reports. opw-6146200 Forward-Port-Of: odoo/enterprise#117855
This update resolves an issue where employees on flexible work schedules were incorrectly flagged for overtime. The fix adjusts how the system calculates expected work hours, now accurately considering the employee's flexible calendar hours instead of relying on outdated synthetic schedules. This ensures accurate overtime calculations for employees with varied work arrangements.
Original PR description
**Steps to reproduce:** - Create a flexible 32h/week calendar (8h/day, 4 days) - Assign it to an employee with the Default Ruleset - Create attendances: 8h on Monday, Tuesday, Friday, and Saturday…
**Steps to reproduce:** - Create a flexible 32h/week calendar (8h/day, 4 days) - Assign it to an employee with the Default Ruleset - Create attendances: 8h on Monday, Tuesday, Friday, and Saturday (32h total, matching the weekly budget) - Select the list view and go to the month of the attendances - Employee shows 16:00 Worked Extra Hours (8h on Fri + 8h on Sat) **Cause:** `resource.calendar._attendance_intervals_batch` generates work intervals for flexible calendars by front loading the weekly hour budget onto the first days of the week (Mon 8h, Tue 8h, Wed 8h, Thu 8h for a 32h calendar), But days beyond the budget (Fri, Sat, Sun) get zero hours. The two overtime rule paths relies on these synthetic intervals: 1) The quantity rule: `_get_daterange_overtime_undertime_intervals_for_quantity_rule()` computed `expected_duration` by intersecting the synthetic schedule with each day. For Fri/Sat the intersection was empty (expected = 0) -> all worked hours counted as overtime. https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L302-L304 **update** solved by: https://github.com/odoo/odoo/pull/265120/changes/94d4bfffa053cd78ce07ff07ab14b53e8d931053 2) The timing rule: `_get_rules_intervals_by_timing_type()` derived "work_days" from the synthetic schedule and inverted them to get "non_work_days". (Fri, Sat, Sun) were classified as non-working days, therefore, any attendance on those days triggered full overtime. https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L421-L433 **Solution:** For flexible calendars in the overtime rule consumer: - Quantity rules: read expected hours directly from the calendar's `hours_per_day` / `hours_per_week` instead of the synthetic schedule intervals, subtracting any leaves in the period - Timing rules: treat the entire attendance date range (minus leaves) as potential work days, so that `non_work_days` is empty for flexible employees (they can work any day of the week) opw-6067063 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263840
This update corrects a bug in the generic tax report that prevented error messages from appearing when dealing with negative net values. The fix ensures that the report accurately identifies discrepancies in tax amounts, even when balances are negative, improving report reliability. This resolves an issue impacting tax reporting accuracy.
Original PR description
**Issue:** In the generic tax report, a check is performed on the report lines to ensure that the declared tax amount is consistent with the expected amount. If the difference between the declared tax amount and the expected one is higher than 0.1% of the declared net amount, then a error message is displayed. If the net amount is negative, the error message is never displayed because the computed percentage of the tax difference is negative and therefore lower than 0.1% (i.e. 0.001). opw-6014350 Forward-Port-Of: odoo/enterprise#117990
This update resolves a display issue in the eCommerce mega menu builder. Previously, the menu would become empty and cause errors when a user had categories linked to the website but none of those categories had a product marked as 'published'. This change ensures the mega menu only appears when there are actual products to display, improving the user experience.
Original PR description
Steps to reproduce: =================== 1. Create a product, link it to an eCommerce category, keep it unpublished. 2. Create a mega menu, edit it. 3. Enable "eCommerce Categories" and try to change…
Steps to reproduce:
===================
1. Create a product, link it to an eCommerce category, keep it unpublished.
2. Create a mega menu, edit it.
3. Enable "eCommerce Categories" and try to change the number of columns.
=> Mega menu is empty and a JS error is logged in the console.
Cause:
======
The "eCommerce Categories" toggle in the mega menu builder appears whenever any `product.public.category` exists for the website. Once toggled, the eCommerce mega menu templates (`s_mega_menu_multi_menus`, etc.) are server-rendered and the resulting HTML is stored on `website.menu.mega_menu_content`.
Since [1] , those templates filter their with
`('has_published_products', '=', True)`. So when the user has categories but no published product, enabling the toggle produces an empty `<div class="row"></div>`. Clicking the column-count option on that empty row which won't have any children and it will cause an error.
Solution:
=========
Adapt the toggle on the same condition the templates use, so it is only offered when there is at least one category that will actually be rendered.
[1]: https://github.com/odoo/odoo/commit/120a7633505891ba3e02e879f0c1a8287a690456
opw-6218503
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#265615
Forward-Port-Of: odoo/odoo#265190This update resolves a bug that prevented invoices from being sent correctly in demo mode when using the Nemhandel integration. The fix involved updating the system's handling of data transmission to align with a recent architectural change, ensuring invoices can now be successfully processed. This improves the reliability of the demo environment.
Original PR description
Steps to reproduce:
1. Install l10n_dk_nemhandel.
2. Register user for Nemhandel in Demo mode.
3. Create and post an invoice.
4. Click Send, check 'By Nemhandel (Demo)', and send.
-> Traceback: IndexError: tuple index out of range in _mock_send_document.
Cause:
The Nemhandel mocking system was halfway refactored to align with the Peppol
mocking architecture. As a result, the `_call_nemhandel_proxy` method now
passes the request payload as a keyword argument (`params={...}`) instead of
positional argument (`args[1]`). The mock functions were still attempting to
access `args[1]`, causing the crash.
Solution:
Update the mock functions to extract the payload directly from
`kwargs.get('params', {})`, removing the obsolete positional argument (args)
fallback to align with the new EDI architecture.
task-6065372
Forward-Port-Of: odoo/odoo#260574This update resolves an issue where invoices sent to Jofotara were being rejected due to extremely small negative discount amounts. The fix ensures that discount amounts are always non-negative by applying an absolute value function, preventing errors and ensuring proper invoice processing. This improves compatibility with the Jofotara system.
Original PR description
Before this commit: 1. Create a POS order with no discount and a quantity that does not divide evenly into the unit price (e.g. price=10.0, qty=3) 2. Send the order to Jofotara Jofotara rejects the…
Before this commit:
1. Create a POS order with no discount and a quantity that does not divide evenly into the unit price (e.g. price=10.0, qty=3)
2. Send the order to Jofotara
Jofotara rejects the invoice because the AllowanceCharge/Amount on the invoice line is a small negative value like -0.000000001 with the error `"EINV_MESSAGE":"discount cannot be negative"`
This happens because _add_document_line_gross_subtotal_and_discount_vals computes the discount as: gross_subtotal - total_excluded_currency
where gross_subtotal goes through two independent rounding steps (round unit price, then round unit_price * qty). When the quantity is indivisible, the reconstituted gross_subtotal can land just below total_excluded_currency by a floating-point epsilon, producing a tiny negative discount. The same subtraction also produces a legitimate negative value for refund lines (negative quantity), which was already handled by abs() in _add_pos_order_discount_vals for the document-level total but was left unguarded at the per-line level.
After this commit:
Apply abs() to vals[f'discount_amount{currency_suffix}'] in _add_pos_order_line_allowance_charge_nodes so that discount_amount_currency is always non-negative.
opw-6183423
Forward-Port-Of: odoo/odoo#265159This update corrects a visual glitch in the Point of Sale (POS) Restaurant module where a notification badge continued to appear after a general note was removed. The fix ensures that removing a note resets the system to its correct state, eliminating the persistent badge and improving the user experience. This resolves an issue reported in the Enterprise version.
Original PR description
Steps to reproduce:
-----------
- Open POS Restaurant
- Add a General Note
- Remove the General Note
- The message badge on “Send to Kitchen” remains visible
Issue:
-----------
Removing a General Note set `general_note` to `undefined`, which was
detected as a change and kept the badge visible.
Fix:
--------------
Normalize empty General Notes to an empty string ("") so removing a note
restores the correct initial state.
Task-6101501
Related PR: odoo/enterprise#113514
Forward-Port-Of: odoo/odoo#265652
Forward-Port-Of: odoo/odoo#258632This update resolves an issue where removing a general note from a restaurant orderline caused the preparation display to incorrectly mark the line as cancelled and create a new one. The fix ensures that note history is recorded regardless of whether the note is confirmed, allowing the system to accurately update existing orderlines instead of creating duplicates.
Original PR description
Steps to reproduce: --------- 1. Create an order with an orderline general note. 2. Send the order to the preparation display. 3. Remove the note from orderline. 4. Resend the order Issue: --------------- Removing the note changes the preparation line key, so the preparation display marks the old line as cancelled and creates a new one instead of updating the existing line. Cause: ----------- The note history was only recorded when the note was confirmed. If the user simply removes/clears the note, no note history entry is generated, so the backend cannot match the previous key with the updated key. Fix: ---------- Record note history even when the note is discarded (not only when confirmed. This allows the backend to match the old and new keys and update the line instead of cancelling it. Task-6101501 Related PR - https://github.com/odoo/odoo/pull/258632 Forward-Port-Of: odoo/enterprise#117943 Forward-Port-Of: odoo/enterprise#113514
This update resolves an issue where users on Android 14 couldn't access their device's camera when selecting files through the image input field. The fix ensures users can now take photos directly through the image input, improving usability on this platform. This change addresses a compatibility problem with recent Android versions.
Original PR description
Since Android 14 we don't have option to take a photo on clicking on file input in Chrome.
This for example will allow only images but no option "Camera"
```html
<input type="file" accept="image/*/>
```
A workaround is to use a dummy mimetype (`*/*`), example `dummy/allowAndroidCamera` The fix will be applied on image widget in addition to the original `acceptedFileExtensions` to not override the existing `accept` attribute
You can test the different behaviour here: https://jsfiddle.net/n0vs6h3b/
Linked url
https://blog.addpipe.com/html-file-input-accept-video-camera-option-is-missing-android-14-15/ https://stackoverflow.com/questions/77876374/html-input-type-file-not-working-to-pull-up-camera-for-pixel-android-14-comb/79163998#79163998 https://issues.chromium.org/issues/40937303
opw-6040375
Forward-Port-Of: odoo/odoo#265750This update fixes an issue where long text in m2m avatar fields was being cut off, creating a poor user experience. The change adds a 'truncate' class to the spans, ensuring text is neatly cut off with an ellipsis when it exceeds the available space, resulting in a cleaner and more professional appearance.
Original PR description
Currently, the m2m tags avatar field does not have the truncate class for the spans. When the text is too long, it overflows and the rest is cut off. This commit adds the truncate class to the spans of the m2m tags so that the text is truncated with an ellipsis when it exceeds the available space. task-4809319 Before: <img width="322" height="189" alt="c5f23b6aee6f63982f530c2e6a641d21" src="https://github.com/user-attachments/assets/b50fc70d-4d21-4023-8838-460f060a98fb" /> After: <img width="310" height="167" alt="5ccf4bb07603a3d8c50d3763bd112f6d" src="https://github.com/user-attachments/assets/fa7e4167-98d8-47d7-a1e2-6639da8e5d05" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256817
This update fixes an issue where long text in m2m tags' avatar fields would overflow and be cut off. By adding a 'truncate' class, text is now automatically shortened with an ellipsis when it exceeds the available space, providing a cleaner and more user-friendly display.
Original PR description
Currently, the m2m tags avatar field does not have the truncate class for the spans. When the text is too long, it overflows and the rest is cut off. This commit adds the truncate class to the spans of the m2m tags so that the text is truncated with an ellipsis when it exceeds the available space. task-4809319 https://github.com/odoo/odoo/pull/256817 Forward-Port-Of: odoo/enterprise#112590
This update resolves an issue where the ecommerce file viewer on the website displayed multiple instances simultaneously when the livechat module was active. The fix ensures that only one file viewer appears, improving the user experience and preventing visual clutter. This was a minor visual glitch addressed to maintain a clean interface.
Original PR description
Before this commit, ecommerce file viewer on website may show more than 1 file viewer at once. This happens because when livechat is installed, the overlay container of livechat mistakenly shows the overlay, therefore the overlay is displayed on main page's overlay container and on the livechat container. The regression was made with [1], where the root id is not longer picked from a target DOM but instead relies on the `env`. This change was motivated to fix a flicker, but the tradeoff is that this requires good passing of the `env` with `rootId`. This was properly set on `MainComponent`, but the overlay container of livechat is exceptionally not the `MainComponent` but instead in `LivechatRoot` that is manually mount. This app lacked the `rootId` in the `env`, which this commit solves. opw-6227540 [1]: https://github.com/odoo/odoo/pull/263860 Forward-Port-Of: odoo/odoo#265603
This update fixes a visual issue in the stock picking operations report, which previously lacked table borders, making it difficult to read. The change restores the standard table borders, significantly improving the report's clarity and usability for users.
Original PR description
Issue before this commit: ========================= The picking operations report displays the operations table without borders, making it difficult to read and distinguish between rows and columns.…
Issue before this commit: ========================= The picking operations report displays the operations table without borders, making it difficult to read and distinguish between rows and columns. Steps to Reproduce: ========================= - Install the stock module - Create a delivery order with products - Print the picking operations report Cause of the issue: ========================= In this commit (https://github.com/odoo/odoo/commit/21cd7e6), the `o_report_stockpicking_operations` class was added to a div, which removed the table borders. After This Commit: ========================= This change restores the table borders in the operations report, improving readability. Before: <img width="796" height="523" alt="2026-04-17_16-30" src="https://github.com/user-attachments/assets/084861e9-3c5b-4ca7-a237-32a56bf2267d" /> After: <img width="795" height="596" alt="2026-04-17_16-30_1" src="https://github.com/user-attachments/assets/e43ed341-8e8b-47c9-9820-66a53823b26c" /> Task: 5462122 Forward-Port-Of: odoo/odoo#253498
This update fixes a potential error that could cause the website to crash when a media item's image is deleted. The change now hides the option when an image is missing and provides an 'add image' option, ensuring a smoother user experience. This improves stability and usability of the website.
Original PR description
Before this commit, the deletion of a `s_media_list_item` image triggered a traceback because `SetMediaLayoutAction.isApplied()` attempted to calculate the option's state on a missing element. Steps to reproduce: - Enter edit mode - Drop `s_media_list` snippet - Select the first media item - Delete its image - The image is deleted, but a traceback appears This commit hides media layout options when the item has no image and introduces an add image option instead. task-6229179 Forward-Port-Of: odoo/odoo#265271
This update fixes an issue where Time Off requests weren't correctly calculating hours when created with a duration type of 'Hours'. The fix ensures that 'request_hour_from' and 'request_hour_to' display the correct hours, preventing zero values. This improves the accuracy of Time Off requests.
Original PR description
…to hours ## Issue: 'request_hour_from' and 'request_hour_to' should be computed using the default calendar attendance values, but instead they display 12:00 AM, meaning their values remain 0.0. ##…
…to hours ## Issue: 'request_hour_from' and 'request_hour_to' should be computed using the default calendar attendance values, but instead they display 12:00 AM, meaning their values remain 0.0. ## Steps to Reproduce: - Open the Time Off app. - Configure a Time Off Type with the Duration Type (request_unit) set to Hours. - Set this Time Off Type as the default one while creating a new Time Off. - Create a new Time Off request. - Observe that 'request_hour_from' and 'request_hour_to' are not computed and display 12:00 AM (0.0). ## Root Cause: While fixing the issue related to preserving leave hours when changing Time Off Types, a regression was introduced. Related PR: https://github.com/odoo/odoo/pull/227235 During the creation of a new Time Off with the duration type set to Hours by default, the field 'request_unit_hours' is already True. This prevents the computation of 'request_hour_from' and 'request_hour_to', resulting in both values remaining 0.0. ## Solution: Compute 'request_hour_from' and 'request_hour_to' when their values are still 0.0 (initial Time Off creation case), and skip recomputation only when switching between Time Off Types in order to preserve manually entered hours. Steps to reproduce : [Video](https://drive.google.com/file/d/1P2MFIj8ZxFtFxv2FlX4Zdq6P-5veTxUb/view?usp=sharing) OPW: 6209992 Forward-Port-Of: odoo/odoo#264707
This update fixes a bug that allowed users to order unlimited quantities of rental products. The system now limits the available quantity based on the product's rental availability, ensuring accurate resource allocation and preventing overbooking. This change improves the reliability and efficiency of our rental service.
Original PR description
It is possible to order as many products as we want of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning module 2. Go to Rental > Products and create a new product "test" with Sales enabled, Product Type "Service", Plan Services enabled as "Developer", in the Sales tab, enable Is Published and in the Rental prices tab, create a pricing for Daily period 3. In the General Information tab, click on the internal link to "Developer" 4. Enable Sync Shifts and Rental Orders 5. Go to the eCommerce website and search for product "test" 6. You can add as many quantity of the product to your cart Issue: We don't limit the maximum quantity of the product Solution: Look through the renting availabilities of the product and set the maximum quantity to the minimum of the availabilities relevant to the renting dates selected opw-6009928 Forward-Port-Of: odoo/enterprise#111793
This update corrects an issue where the 'Send to Kitchen' toast message in the restaurant ordering system was displaying incorrect formatting for items in languages other than English. The fix uses a language-aware method to join items, ensuring the message accurately reflects the order contents in the user's selected language. This improves the clarity and accuracy of notifications for restaurant staff.
Original PR description
Steps to reproduce: ------------------- 1. Set the user language to French. 2. Configure a preparation display. 3. In PoS, add 2 products of different categories (e.g. 2 starter and 1 main) 4. Send to kitchen -> Toast shows "2 starter et 1 €, envoyé à la cuisine" instead of "2 starter et 1 main, envoyé à la cuisine". What's happening: ----------------- The summary is built with a regex that uses `$1` to replace the ", <last_item>" with an "and <last_item>", however, this `$1` in languages other than english is being translated, in our case to `1€`, and the regex replacement logic does not work properly anymore. The fix: -------- Use `formatList` to join the items, it uses the user language to apply locale-specific joining rules. opw-6149616 Forward-Port-Of: odoo/odoo#265712
This update corrects a bug where re-invoiced expenses on sales orders incorrectly displayed the total expense amount as the unit price. The fix ensures that the quantity of the expense is properly reflected in the sales order line, resolving the pricing discrepancy. This improves the accuracy of sales order reporting.
Original PR description
Currently, when re-invoicing an expense paid by company, the line added to the sale order will show a price unit equal to the whole expense amount. Steps to reproduce: - Create a new Expense Category with Re-Invoice Costs set to 'At cost' - Create a new Expense, set the new category, and set Paid By to 'Company' - Set Quantity to greater than 1, and Customer to Re-Invoice to any Sales Order - Confirm and Submit Journal Entry on the Expense record Issue: - On the linked Sales Order you will see the total of the expense is used as the unit price This occurs because we don't pass the quantity to the move line creation vals, which then default to 1. In turn, when the sale order line is added, the unit price will be based on the move line vals but the quantity will match the expense. opw-5883290 Forward-Port-Of: odoo/odoo#246816
This update resolves an issue where a white background on the website would clash with product details, creating an unprofessional design. The fix removes the unwanted white background from product detail cards, ensuring a consistent and visually appealing experience when using website backgrounds. This improves the overall user experience and brand image.
Original PR description
When a background is set on the website, we can't remove the background of the product information card making the design unaesthetic Steps to reproduce: 1. Install eCommerce 2. Go to Website and click on Edit in the top right corner 3. Open the "Theme" tab, set an image (not plain white) to the website's background and save 4. Go to the shop and open any product 5. The product details are shown on a white block that disrupts the background image Issue: We set a background-color on `#product_details` with value `$body-bg` which is an opaque white Solution: Remove the white background of `#product_details` opw-6214514 Forward-Port-Of: odoo/odoo#265021
This update fixes a visual issue where the user rights widget sometimes overflowed its container. By adding scrolling functionality to the popover component, the widget now displays all content correctly, regardless of the amount of information. This ensures a consistently clear and usable experience for users managing access permissions.
Original PR description
This PR adds the `overflow-auto` class to the popover component to enable scrolling and prevent content overflow. **Task-ID: 6137031** Forward-Port-Of: odoo/odoo#261216
This update corrects a translation issue in the Odoo Gantt view. The button used to toggle display modes was not correctly translated, preventing users from seeing the view in their preferred language. This commit ensures all button labels are translated, improving the user experience for international users.
Original PR description
The title of the button allowing to toggle the display mode in the Gantt view was not translated. This commit adds a getter to compute the title based on the current display mode, and uses it in the template. Issue reported by translator. Forward-Port-Of: odoo/enterprise#117807 Forward-Port-Of: odoo/enterprise#117739
This update resolves a problem where custom product attributes weren't correctly displayed in the POS kiosk mode. Specifically, when a product had a single custom attribute, options weren't shown, and the 'Add to Cart' button was disabled. The fix ensures that custom attributes are displayed and functional within the kiosk experience, improving usability.
Original PR description
this pr fixes 3 bug, as all are closely related. Step to reproduce (hide is_custom attr in kiosk mode): - have two attributes A and B - A has only 1 attribute value with is_custom = True - B can have…
this pr fixes 3 bug, as all are closely related.
Step to reproduce (hide is_custom attr in kiosk mode):
- have two attributes A and B
- A has only 1 attribute value with is_custom = True
- B can have any two value ( ex. gender: male/female)
- use it on a product and make it available in POS for kiosk
- start kiosk and open that product
Observation:
- we do not get option to select option from A but the heading is visible
- when we select from B, Add to cart is disabled.
Cause:
- we do not allow attribute values with is_custom = True in kiosk
- but we display the attribute regardless
- the Add to cart btn depends on `selectedValues`, which requires
value from each attribute, in this case, we are not seletion anything from A
- so it is disabled
Fix:
- we introduced `attributesToDisplay` which will hide heading in case of single
custom value for any attribute
- for Add to cart, wenow do not expect value from `is_custom` attribute values.
Allow product with 1 attr which is `is_custom` to be
configurable in configs other than kiosk) correct fix for commit
Step to reproduce
- have attributes A
- A has only 1 attribute value with is_custom = True
- use it on a product and make it available in POS
- start pos and open that product
Observation:
- we do not get option to select add text for A
Cause:
- in pos, we consider product to be configurable only it has more than 1
attributes, which misses is_custom attr
Fix:
- we backport commit[1] and also considers its side effect by introducing
`isProductConfigurable` for pos_self_order, which will still avoid
`is_custom` attrs for kiosk
[1] https://github.com/odoo/odoo/commit/5155c77a03ed2ff6c914eac41cc81ccb34b1f3c7
Empty page is displayed if product has only `is_custom` attribute value
and other attribute with type other then 'no_variant' for combo item
Step to reproduce
- have attributes A and B
- A has only 1 attribute value with is_custom = True
- B has two values with type "always"
- use it on a product and add that product in combo item and make it available
in Kisok
- start kiosk and open that combo and select that product
Observation:
- we do not get option to select
Cause:
- `availableAttributeValue` only show `no_variant` and non `is_custom` attribute
values in attributeSelection component.
Fix:
- before mounting Attributeselection component, we check if product has required
attribute or not.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#265238
Forward-Port-Of: odoo/odoo#257880This update fixes an issue where the 'import emissions' action wasn't appearing in the ESG module's menu. The fix allows the import action to be displayed, even with a restricted 'create' setting in the list view, ensuring users can easily access and utilize the ESG carbon emission reporting feature.
Original PR description
Before this commit, the "import" action of emissions in the ESG module was not visible in the COG menu. It is because the "create" attribute of the list view is disabled, which prevents the menu item from being displayed. With this commit, we override the standard behavior in this particular action, by allowing the import action to show up in the COG menu, even if the "create" attribute is disabled. version-19.1
This update resolves two issues related to the eTransport integration, specifically concerning national territory shipments and invalid delivery tokens. Instead of generating tracebacks, the system now displays a clear validation message on the affected delivery document, improving user experience and troubleshooting.
Original PR description
This commit fixes two corner case bugs:
1. Transport on National Territory with a warehouse in another country
- Setup eTransport data in settings
- Create a delivery to a Romanian customer
- in eTransport tab -> choose operation type: Transport on National
Territory
- Go to configuration -> warehouses -> change the address of the
warehouse to an address not in Romania
- send the eTransport
2. Sending to eTransport with invalid tokens
- Setup eTransport data in settings
- Remove a character from one of the tokens
- send a valid Delivery to eTransport
we get a traceback for both cases but we want a validation message on the
created document instead.
task-6217207
Forward-Port-Of: odoo/odoo#264747A recent update to Odoo's PDF processing caused errors when downloading signed documents. This fix corrects a problem with how PDF compression was handled, specifically related to newer versions of the pypdf library. The change ensures documents are downloaded correctly from the Sign app.
Original PR description
This [related PR] introduced a compression pass after calls to mergePage(). However in newer versions of pypdf (>=3.5.2), compress_content_streams() can only be called on pages of PdfWriter. An error would be raised when called on pages of a PdfReader. Steps to reproduce ----- 1. Run Odoo with pypdf>=3.5.2 2. Sign and download a document in the Sign app 3. Traceback occurs Fix ---- This commit moves the compression to the writer object, after the merged page has been added. Related pr: https://github.com/odoo/odoo/pull/261879 runbot-937761 Forward-Port-Of: odoo/odoo#265945 Forward-Port-Of: odoo/odoo#265304
A recent update to Odoo's document signing process caused errors when downloading signed documents. This fix addresses a compatibility issue with a newer version of the pypdf library, ensuring documents are correctly processed and downloaded. The change ensures smooth operation with the Sign app and related modules.
Original PR description
This [related PR] introduced a compression pass after calls to mergePage(). However in newer versions of pypdf (>=3.5.2), compress_content_streams() can only be called on pages of PdfWriter. An error would be raised when called on pages of a PdfReader. Steps to reproduce ----- 1. Run Odoo with pypdf>=3.5.2 2. Sign and download a document in the Sign app 3. Traceback occurs Fix ---- This commit moves the compression to the writer object, after the merged page has been added. Related pr: https://github.com/odoo/odoo/pull/261879 runbot-937761 Forward-Port-Of: odoo/enterprise#118117 Forward-Port-Of: odoo/enterprise#117756
Features or functions removed from Odoo
This commit removes a plugin that was no longer needed for translating the website's table of contents. The underlying functionality is now handled automatically, improving website performance and reducing complexity. This change was made to streamline the codebase and ensure ongoing efficiency.
Original PR description
The plugin `TranslateTableOfContentOptionPlugin` is not needed anymore, the replication between the headers in the content of the `s_table_of_content` and its navbar is now completely handled by the `FieldChangeReplicationPlugin` plugin since a5f1af347b55da8662d6d6802b57e14aab574d78. The test is removed because it is not representative of real edition situation (the nodes it changes are not inside `contenteditable=true` or `o_savable`), and the test added in a5f1af347b55da8662d6d6802b57e14aab574d78 covers this usecase. task-5892636 Forward-Port-Of: odoo/odoo#265779 Forward-Port-Of: odoo/odoo#264325