Daily updates from Odoo
Thursday, May 14, 2026
27 changes · saas-19.2
Resolved issues and error corrections
This update corrects a discrepancy in how ARCA-related documents are displayed in Odoo. The system has been updated to align with recent ARCA regulations, ensuring accurate reporting and compliance. The changes update document names and codes to reflect the new 'Operation subject to withholding' classification.
Original PR description
**Context:** * ARCA (formerly AFIP) has deprecated the "Documentos M" classification for document types with codes 51-59. * These are now classified as "Documentos A con leyenda 'Operación sujeta a…
**Context:** * ARCA (formerly AFIP) has deprecated the "Documentos M" classification for document types with codes 51-59. * These are now classified as "Documentos A con leyenda 'Operación sujeta a retención'" while retaining the same codes for backward compatibility with ARCA validations. **Steps to Reproduce:** * Install `l10n_ar` module. * Go to `Accounting -> Configuration -> Document types`. **Observed behavior:** * Document types 51-59 still display letter "M" and use the old naming convention (e.g. "INVOICES M", "DEBIT MEMOS M"), which no longer reflects the current ARCA classification. **Fix:** * Updated `name` fields to include the "WITH LEGEND" / "CON LEYENDA" suffix. * Changed `l10n_ar_letter` from "M" to "A" so the PDF header renders an "A". * Changed `doc_code_prefix` from `*-M` to `*-A` (FA-A, ND-A, NC-A, RE-A). * The existing `res.config.settings` option for injecting the PDF legend remains untouched. Sources: - ARCA: https://www.afip.gob.ar/facturacion/regimen-general/comprobantes.asp Ref: https://www.odoo.com/mail/message/1025488740 opw-5953504 Forward-Port-Of: odoo/odoo#254975
A technical issue preventing users from selecting a background video from Vimeo was resolved. This commit removed a broken video link from the preview options, ensuring a smooth user experience when setting background videos on the website. This improves the functionality of the website builder.
Original PR description
Steps to reproduce: 1. Drop any snippet. 2. Click on the background video option. 3. Observe Traceback. The Vimeo video with ID `499761556` is no longer available, causing a traceback when opening the background video options. This commit removes the unavailable video from the preview list. task-6088772 Forward-Port-Of: odoo/odoo#264080 Forward-Port-Of: odoo/odoo#263555
This update resolves an issue where changes made on a POS ticket screen weren't being reprinted correctly. The fix corrects the underlying logic to ensure all previous order modifications are accurately reflected when the 'reprint all changes' function is used. This improves the reliability of printed POS tickets.
Original PR description
Steps: ---------- - Install point_of_sale. - Open a POS session with a preparation printer configured. - Process an order with two different changes. - Open the ticket screen and try to reprint all previous changes. Issue: ---------- - No changes are printed. Cause: ---------- - Incorrect logic used when reprinting all changes. Fix: ---------- - Correct the logic to properly reprint all previous changes. Task-6008291
This update fixes an issue where discount lines in Czech VAT reports (vies) were incorrectly calculated. The previous method of using ABS() on negative values resulted in inflated report totals. The fix now correctly handles negative discount amounts, ensuring accurate VAT reporting.
Original PR description
Step to reproduce: - install l10n_cz_reports_2025 and switch to cz company - create a invoice, with cz company ( as partner), of 100. - when adding products, add "Transaction code" (optional fields) to "Goods" - Add discount line, set to -10, add "Transaction code" in this line too. - confirm it Observation: - invoice is 90$ - open vies summary report for this year - value turn out to 110 Cause: - commit [1](https://github.com/odoo/enterprise/commit/892268c44b1bbc838a9f03ef36a079bfff625ca6) converts every balance to +ve and only negate it, in case of refund - in case of discount lines, price is -ve, ABS() turn it to +ve and value comes out to be wrong Fix: - instead of applying ABS() directly, we flip the signs only for out_* moves, in short when a account is credited, its balance is < 0 then we flip its sign opw- 5979262 Forward-Port-Of: odoo/enterprise#117038 Forward-Port-Of: odoo/enterprise#113087
The 'Waiting for Me' filter in the Sign app was incorrectly fetching all documents instead of filtering those requiring the current user's signature. This update corrects a technical issue related to how the system processes filter criteria, ensuring the filter functions as intended and only displays relevant documents. This improves the usability of the Sign app.
Original PR description
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature. Steps to reproduce: 1) Install…
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature.
Steps to reproduce:
1) Install sign with demo data
2) Open sign app and remove default filter
3) Add a filter Waiting for me
Observed Behavior:
All the documents are fetched.
Expected Behavior:
Documents should be filtered out to only show those where the current user is a signer.
Root Cause:
Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown
From:
`('need_my_signature', '=', True)]`
To:
`[('need_my_signature', 'in', [True])]`
This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature.
As a result, instead of filtering documents, all documents are returned.
[1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108
[2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177
Fix:
Corrected the return domain logic to fetch the correct documents.
opw-6026935
Forward-Port-Of: odoo/enterprise#116985
Forward-Port-Of: odoo/enterprise#113760This update fixes a minor discrepancy in the Norwegian tax settings. The tax code 32's rate was incorrectly set to 11.0. This change ensures accurate tax calculations for Norwegian businesses using Odoo, aligning with official tax regulations. This was coordinated with a related Enterprise PR.
Original PR description
The tax rate(`amount`) for code 32 was mistakenly set to '11.0'. To properly align with the official Norwegian tax rates, it needs to be updated to '11.11'. Related Enterprise PR: https://github.com/odoo/enterprise/pull/110792 task-6033027 Forward-Port-Of: odoo/odoo#264221 Forward-Port-Of: odoo/odoo#258390
This update resolves issues preventing Odoo's Norwegian VAT XML reports from passing validation by Skatteetaten. The changes ensure correct decimal formatting, mathematical calculations, and required legal notes are included, guaranteeing accurate VAT returns and avoiding potential delays or penalties. This update directly addresses a critical requirement for compliance.
Original PR description
Before commit: The Norwegian VAT XML export fails Skatteetaten validation due to incorrect decimal formatting, mathematical rounding mismatches between base and tax amounts, missing mandatory legal…
Before commit: The Norwegian VAT XML export fails Skatteetaten validation due to incorrect decimal formatting, mathematical rounding mismatches between base and tax amounts, missing mandatory legal notes, and invalid KID number formats. Fix: To strictly follow Skatteetaten validation rules for the Norway VAT XML, the following changes were implemented: - Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted fractional rates like `11.11` to `11,11` in XML. - Rounded down the `tax_amount` to align precisely with government mathematical expectations. - `base_amount` converted into absolute value to ensuring the calculation (`base * rate = tax`) resolves perfectly. - Add the mandatory `<merknad>` explaining the reverse charge method for codes 81, 83, 86, 88, and 91. - Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix. Expect: The generated XML payload now adheres perfectly to Skatteetaten's strict structural and mathematical rules, allowing the VAT return to pass government validations successfully. Related Community PR: https://github.com/odoo/odoo/pull/258390 Task-6033027 Forward-Port-Of: odoo/enterprise#117168 Forward-Port-Of: odoo/enterprise#110792
This update resolves a bug that caused the image editor to crash when users tried to select all content with Ctrl+A when an image had a caption. The fix ensures the selection process correctly identifies the editable area, specifically targeting the nearest contenteditable element instead of the entire figure tag. This improves stability and usability for users working with images and captions.
Original PR description
#### Description of the issue this PR addresses: - When an image with caption is selected, it is wrapped in a `<figure>`, making `<figure>` the anchor node - `selectAll` was resolving the container using `[contenteditable]`, which keeps `<figure>` as the container even though it is `contenteditable=false` - This leads to `<figure>` being passed to `getDeepestEditablePosition`, which cannot resolve a valid `nodeLevelAncestor` and returns null, causing a traceback #### Desired behavior after PR is merged: - `selectAll` now targets the nearest `contenteditable=true` ancestor instead of any `[contenteditable]` #### Steps to reproduce: - Add image and enable caption - Select the image - Press Ctrl+A task-6174371 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261968
This update fixes an issue where packaging unit information was missing from delivery slip reports after a transfer was validated. Previously, the system didn't correctly display the packaging unit quantity. Now, the delivery slip accurately reflects the packaging unit and its quantity, even after the transfer is validated, ensuring accurate reporting of product movements.
Original PR description
Issue before this commit: ========================= For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the…
Issue before this commit: ========================= For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the transfer. However, after validating the transfer, the packaging unit and its corresponding quantity are no longer displayed in the delivery slip report. Steps to Reproduce: ========================= 1. Install stock and sale_management modules. 2. Enable Units of Measure & Packagings and Display Lots & Serial Numbers on Delivery Slips from settings. 3. Create a product with tracking by lot/serial number and configure a packaging unit. 4. Create a SO using this product with a packaging unit and confirm it. 5. Open the related transfer and print the delivery slip before and after validation. Cause of the Issue: ========================= The delivery slip report template (stock_report_delivery_has_serial_move_line) does not display packaging unit information after validation for move lines when the packaging unit differs from the product unit of measure. With This Commit: ========================= This commit ensures that packaging units and their corresponding quantities are displayed on the delivery slip after validation when the packaging unit differs from the product unit of measure. Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10DmFKW1Y_Tm-AyKzPrqtFMY8orBkKbIm/view?usp=sharing) opw-6142052 Forward-Port-Of: odoo/odoo#262722
A technical issue causing a 'singleton' error when generating time off reports for employees was resolved. This fix ensures the 'By Employee' reporting feature under time off functionality works correctly, preventing disruptions to payroll and reporting processes. This update improves the reliability of the French company's time off reporting.
Original PR description
A singleton error appears when opening the "By Employee" report under Time Off. **Steps to reproduce:** - Install the l10n_fr_hr_holidays module. - Switch to the French company. - Open any employee record. - Set Working Hours (resource_calendar_id) to empty. - Set Hours Per Week. - Create a time off request for any past date. - Go to Reporting → By Employee. Task:-6043142 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 limitation in how Odoo handles attachments uploaded through its automated cron jobs. Previously, a single cron job was restricted to uploading only one attachment at a time. Now, the system allows multiple attachments to be uploaded within a single cron job run, improving efficiency and reducing the need for multiple uploads.
Original PR description
make the `limit_time_real > 0` when --limit-time-real-cron=0 --limit-time-real=0 to allow multiple attachments to be uploaded in a single cron job. 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#264328
This update ensures Odoo's audit trail feature remains enabled in India, aligning with Ministry of Corporate Affairs requirements. Previously, the audit trail could be disabled, but this change enforces its continuous maintenance as mandated by law. This ensures compliance and reduces potential legal risks.
Original PR description
After the refactor introduced in https://github.com/odoo/odoo/commit/f280f762b6417fa1a0b09649ffbdecafcc7e7579, The audit trail feature was split into two modes: a lightweight general-purpose mode and a force-restricted mode for specific localizations (e.g., Germany), where deactivation is not allowed once enabled. In India, as per the requirements of the Ministry of Corporate Affairs, the audit trail must be maintained and cannot be disabled once activated. This commit extends the force-restricted audit trail mode to the Indian localization (l10n_in) to ensure compliance with statutory requirements. task-6182002 Forward-Port-Of: odoo/odoo#264508 Forward-Port-Of: odoo/odoo#262508
This update resolves a test failure in the 'pos_self_order' module that occurred due to how order slots were being generated. The fix freezes the time to '00:00' to ensure all available slots are considered, preventing the test from failing on specific days. This ensures consistent test results and reliable order scheduling.
Original PR description
Before this commit: = - The test test_slot_limit_orders created slots only for the first day of the week (Monday). - The test scenario includes a slot at "18:00". - On Mondays, the test fails between 18:01 and 23:59 because the "18:00" slot no longer exists for the current day. - On other days, the test passes since slots are generated for the upcoming Monday. After this commit: = - Freezed the time to current day at "00:00" so that slot list can have every slot for that day. task-6043739 runbot-241836 Forward-Port-Of: odoo/odoo#263198 Forward-Port-Of: odoo/odoo#254775
This update fixes a potential issue where users could accidentally assign multiple POS shops to a single cash payment method. Now, the system prevents this, ensuring accurate payment tracking and avoiding errors when processing transactions. This change enhances the reliability of our point-of-sale system.
Original PR description
**Before this commit** The user will be able to assign two different POS shop to a cash payment method by going to POS -> Configuration -> Payment Methods -> Cash -> Point of sale, this will not raise a validation error when they try to save it but it will prevent the user from opening the POS session. **After this commit** It will raise a validation error if a user tries to assign more than one POS shop to one cash payment method and save it. opw-6015025 Forward-Port-Of: odoo/odoo#252603
This update resolves a crash within the website event editor when the event is set as the homepage. The issue stemmed from a missing match case in the event ID retrieval process. By adding a default return value, the editor now functions correctly, ensuring a stable experience for users managing their events.
Original PR description
**Description of the issue/feature this PR addresses:** The `WebsiteEvent._getEventObjectId` method lacks a specific match case for the root directory, causing event ID retrieval to fail on the…
**Description of the issue/feature this PR addresses:** The `WebsiteEvent._getEventObjectId` method lacks a specific match case for the root directory, causing event ID retrieval to fail on the homepage. In order to resolve this, I've implemented a default return of 0 when the URL pattern matching fails [following the pattern established by later revisions of this code](https://github.com/odoo/odoo/blob/2199f71070ce3e9a4717eb6b750c14485406f7aa/addons/website_event/static/src/website_builder/event_page_option_plugin.js#L67). **Steps to reproduce bug:** 1. Create an event website 2. Create an event and visit it 3. On the page click Site > Properties 4. Enable `Is Homepage` 5. Return to the homepage of the application and open the editor https://drive.google.com/file/d/1OpCUAp4LJKqkoStciWeJEGVVlR3qpw1R/view?usp=drive_link **Current behavior before PR:** https://drive.google.com/file/d/1c7ACqaQx03mePzJSV_RoPn8mlLWSMa1I/view?usp=drive_link **Desired behavior after PR is merged:** https://drive.google.com/file/d/1L3Ne9h6-yB3v7VbXipjly9OrDSkZvDOu/view?usp=drive_link opw-6101680 Forward-Port-Of: odoo/odoo#263548 Forward-Port-Of: odoo/odoo#258502
This change resolves an issue where cash rounding with the 'biggest tax' strategy caused an invoice error when using customer addresses. The fix ensures the correct partner ID is used during invoice processing, preventing data deletion and improving invoice accuracy.
Original PR description
When applying a cash rounding with 'biggest tax' strategy, it happens that we end up with a MissingError when the invoice's partner is not defined as commercial_partner_id. Steps: - Install…
When applying a cash rounding with 'biggest tax' strategy, it happens that we end up with a MissingError when the invoice's partner is not defined as commercial_partner_id. Steps: - Install membership module - Create a cash rounding with the 'biggest tax' strategy and 0.05 rounding - Enable customer addresses and create a partner P with an invoice address I - Create an invoice, select I as customer (P will be assigned as delivery address but this is not relevant) - Add an invoice line for 100.03 and any tax and apply the cash rounding - Confirm -> MissingError: record has been deleted Cause: - When creating the cash rounding lines, we set the `partner_id` from the invoice's partner (in our case partner I, which has P as `commercial_partner_id`). - When posting the invoice we look for lines that have partner id different than the invoice's commercial partner id and we call the write method to set the commercial partner id instead https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L5234-L5239 - In some cases, for example in the `membership` module, the override of the write method calls the super() before using `self`. https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/membership/models/account_move.py#L45-L49 But the super triggers the `_sync_tax_lines` mechanism, during which the rounding line in deleted https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_tax.py#L3102-L3110 https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L3113-L3114 Therefore `self` doesn't exist anymore when comming back in the override Fix: Setting the commercial partner on the rounding line to avoid calling the write method opw-6128868 Forward-Port-Of: odoo/odoo#262759
This update resolves an issue where users could create attachments that repeatedly referenced themselves, leading to errors. The fix prevents attachments from being linked to themselves in the user interface and during data writing, ensuring data integrity and stability.
Original PR description
Currently, users have the option to attach an ir.attachment to itself. This causes a recursion depth error when accessing attachments. This commit prevents this in the UI and the write. Firstly, the ir.attachment does not show itself in the dropdown when selecting the resource ID. Second, the write raises a UserError if attempting to write an ir.attachment with the same ID as the Resource ID. Steps to reproduce: 1. Create an attachment and save 2. Set the Resource Model `(res.model)` to "ir.attachment" 3. Select the same attachment in Resource ID `(res_id)` 4. Attempt to view attachments: `RecursionError: maximum recursion depth exceeded` opw-6206075 closes #263591 Forward-Port-Of: odoo/odoo#264439 Forward-Port-Of: odoo/odoo#263591
A test within the l10n_latam_check module failed due to a dependency on the l10n_ar module not being installed. This update ensures the test runs correctly by requiring l10n_ar to be present during execution, preventing a runtime error.
Original PR description
Steps to reproduce: 1- Install l10n_latam_check on a fresh database instance 2- Run the test `test_invoice_status_after_voided_check` Issue: `ValueError: External ID not found in the system: l10n_ar.dc_liq_uci_a` Why this happens: The test used a document type from the l10n_ar module, so running the test without it being installed caused an error. runbot-243341 Forward-Port-Of: odoo/odoo#262800
This update resolves an issue that prevented invoices with combo products lacking taxes from being correctly processed when generating Peru UBL invoices. The fix corrects a validation oversight, ensuring that combo products without taxes now generate invoices without errors. This ensures accurate invoice generation for our Peru UBL customers.
Original PR description
A traceback occurs when sending an invoice to Peru UBL if a combo product invoice line does not have any taxes applied. Steps to reproduce the error: - Install ``l10n_pe_edi`` module with demo data -…
A traceback occurs when sending an invoice to Peru UBL if a combo product invoice line does not have any taxes applied. Steps to reproduce the error: - Install ``l10n_pe_edi`` module with demo data - Switch to PE Company - Create an invoice > Add a Office Combo product > unset the taxes > Confirm - Process now https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_xml_ubl_pe.py#L549-L552 Here, the ``grouping_key`` becomes ``None`` when no taxes are present on the invoice line. Normally, invoices without taxes are restricted at [1], but combo products are excluded from this validation at [2]. As a result, combo product lines without taxes bypass the restriction and trigger a traceback. [1]: https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_format.py#L928-L929 [2]: https://github.com/odoo/odoo/blob/42b8852df9b323984364c41a13cf27d19fbe04a7/addons/account/models/account_move_line.py#L3433-L3434 sentry-7430552834 Forward-Port-Of: odoo/enterprise#114798
This update fixes an issue where UBL invoices could incorrectly apply taxes due to differences in fiscal positions. The change ensures that only taxes matching the invoice's fiscal position are used during import, leading to more accurate financial reporting. This improves the reliability of UBL invoice processing.
Original PR description
When importing a UBL invoice, multiple taxes may share the same rate (e.g. 21%) but differ by fiscal position. Without filtering, the wrong tax (e.g. the domestic one for a foreign partner) could be selected. task-6138749 Forward-Port-Of: odoo/odoo#264525 Forward-Port-Of: odoo/odoo#263872
This update resolves an issue where dragging and releasing calendar events on touch screens would cause a browser error. Now, dragging and releasing events works smoothly on both touch and mouse devices, improving the Calendar app's usability for all users.
Original PR description
When using the Calendar app on a touch screen, dragging an event and releasing it would raise a client error. Releasing a dragged event now works smoothly on both mouse and touch devices. task-6124833 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#263361
This update resolves a problem that occurred when creating consolidated POS invoices from multiple orders for the same customer. The previous issue caused errors due to how refund reasons were being handled across multiple orders. Now, the system safely collects and validates refund reason values, ensuring invoices are created correctly and preventing potential errors.
Original PR description
When creating a consolidated POS invoice from multiple orders for the same customer, `_prepare_invoice_vals` is called on a multi-record set. Accessing `self.l10n_es_tbai_refund_reason` directly on such a set raised a ValueError because `fields.Selection.__get__` internally calls `ensure_one()`. Use `mapped()` to safely collect all distinct refund reason values across the recordset. Raise a UserError if orders have conflicting values, consistent with the existing TicketBAI validation pattern for mixed required/non-required orders. opw-6192225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262967
This update fixes an issue where completion and refusal emails for signatures were incorrectly using the signer's partner email instead of the correct, validated email defined for the sign request. Now, emails sent to signers will use the accurate email address, ensuring proper communication and notification delivery. This improves the reliability of the signature process.
Original PR description
Previously, completion and refusal emails were sent using the partner email directly, ignoring the computed email defined on the sign request item. The computed email includes validation rules and should be the main email for signer communication. This commit ensures that completion and refusal emails are sent using the computed signer email instead of the partner email. task-6148765 Forward-Port-Of: odoo/enterprise#114606
This update fixes an issue where large tablets with touch screens incorrectly displayed the mobile toolbar instead of the desktop toolbar. The change now considers screen size, ensuring the correct toolbar is shown on all devices, improving the user experience for tablet users.
Original PR description
Problem: On large tablets with touch capability and high resolution, the mobile toolbar is displayed instead of the desktop toolbar. Cause: The mobile toolbar condition relied on touch capability alone, without considering screen size. Devices with large screens but touch support were therefore incorrectly treated as mobile. Solution: Use `utils.isSmall()` to determine whether the device should display the mobile toolbar, ensuring screen resolution is taken into account. Steps to reproduce: - Open the editor on a large tablet. - Observe that the mobile toolbar is shown. - The desktop toolbar should be displayed instead. task-6106531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259605
This update resolves an issue where changing a text tag (like from 'Header 2' to 'Header 1') didn't fully remove the previous heading style. The fix ensures that selected text correctly loses its original heading formatting, improving the accuracy of text editing within Odoo.
Original PR description
Problem: When applying `h1` to part of a selection already inside an `h2`, the selected content still keeps the `class="h2"` style. Cause: `removeFormats` internally uses `formatSelection`, but in this case we only want to change the tag and not reformat the selection. This causes existing heading styles to remain applied. Solution: Use `removeFormat` instead, as it removes formatting without applying additional formatting to the selection. Steps to reproduce: - Go to Website and drop the "Text-Image" snippet. - Copy the text "Enhance Your Experience". - Paste the text into a new To-Do. - Select part of the pasted text. - Change it from "Header 2" to "Header 1 Display 1". - Observe that part of the text still keeps the "Header 2" style. task-6204505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263810
This update optimizes PDF report generation by compressing files after merging, reducing file sizes and memory usage. It addresses a previous memory leak and leverages newer pypdf versions for better performance, particularly with large reports. The result is faster report generation and reduced storage needs.
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 by compressing files after merging, resulting in significantly smaller file sizes and faster processing times. It addresses a previous memory leak issue and leverages newer PDF library versions for better efficiency, particularly when handling large documents. This improves user experience and reduces storage needs.
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