Thursday, December 11, 2025
17 changes · saas-18.4
Enhancements to existing features
This update introduces a new process to automatically upload attachment files to cloud storage. This improves storage efficiency and reduces reliance on local servers. Administrators can manually trigger the migration process to move existing attachments.
Original PR description
This commit provides a cron job to migrate attachment binary to the cloud storage. The cron job is designed to be manually triggered from by the "Run Manually" button of the Scheduled Action's form…
This commit provides a cron job to migrate attachment binary to the
cloud storage. The cron job is designed to be manually triggered from
by the "Run Manually" button of the Scheduled Action's form view.
The cron job will try to upload some attachments once
1. size is greater than the minimum upload file size defined by
(ir.config_parameter: cloud_storage_min_file_size)
2. id is greater than the number defined by
(ir.config_parameter: cloud_storage_migration_min_attachment_id)
3. res_model is in a white list
(ir.config_parameter: cloud_storage_migration_message_models)
(ir.config_parameter: cloud_storage_migration_all_models)
4. not used by documents.document
optional configurations to avoid timeout issues
- cloud_storage_migration_max_file_size:
max bytes for each migrated attachment
- cloud_storage_migration_max_batch_file_size:
max total bytes for migrated attachments in one cron job execution
The cloud_storage_migration_min_attachment_id which can be accessed
from the list view can be treated as the progress of the cron job.
Manually setting it to 0 and retriggering the cron job will retry the
upload process for previously failed or ignored attachments.
taskid: 5387110
Steps
1. install a cloud storage module (cloud_storage_google, cloud_storage_azure)
2. install the cloud storage migration module (cloud_storage_migration)
3. Go to Settings for Cloud Storage Settings <img width="505" height="206" alt="image" src="https://github.com/user-attachments/assets/d72d7b52-5ce7-4209-8645-4a8ac35dd049" />
4. [Configure the cloud storage settings](https://www.odoo.com/documentation/19.0/applications/general/integrations/cloud_storage.html)
5. Setting the Minimum File Size. Attachments smaller than the size won't be uploaded to the cloud storage <img width="457" height="96" alt="image" src="https://github.com/user-attachments/assets/8dc4e6fe-9c84-44f5-a83a-28c7b2fad30a" />
6. After 4, configure settings for the cloud storage migration
a. <img width="464" height="209" alt="image" src="https://github.com/user-attachments/assets/37352453-ff0e-4e03-a4d5-7fdb8168dee1" />
b. Cron Job:
i. the link to the cloud storage migration cron job
ii. the cron job is designed to be a job only triggered by clicking "Run Manually".
iii. It will re-trigger itself until all relevant attachments are migrated.
c. Parameters:
<img width="882" height="571" alt="image" src="https://github.com/user-attachments/assets/9926ed9f-81ac-4917-b759-872ed2584217" />
d. Progress Bar:
i.progress of the migration job
ii. calculated by `cloud_storage_migration_min_attachment_id / cloud_storage_migration_max_attachment_id`
e. Attachment Report:
i. <img width="1907" height="298" alt="image" src="https://github.com/user-attachments/assets/33a77835-c6b6-4bc4-b20a-4ec68acba783" />
ii. a view to help administrator analyze which model's attachments should be migrated
iii. help to configure step 6.c.i.4 and step 6.c.i.5
f. Message Attachments
i. help to configure step 6.c.i.4
g.All attachments
i. help to configure step 6.c.i.5
7. Click Cron Job and then Click Run Manually
<img width="409" height="123" alt="image" src="https://github.com/user-attachments/assets/f60cdfcf-e6a6-4503-87fc-0be7f14ceede" />
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#239052
Forward-Port-Of: odoo/odoo#235745Resolved issues and error corrections
This update optimizes how Odoo searches for sale orders linked to projects, significantly speeding up the loading time of the 'Settings' page. By adding an index, the system now efficiently locates relevant data, reducing the time taken to load project information. This improves overall user experience and system responsiveness.
Original PR description
Description ----------- Following odoo/odoo@238a41e35280256382f6509182b9e900fb4f7aba, the domain for `sale.order.line` in `_get_sale_order_items_query` was modified to search based on the relevant…
Description ----------- Following odoo/odoo@238a41e35280256382f6509182b9e900fb4f7aba, the domain for `sale.order.line` in `_get_sale_order_items_query` was modified to search based on the relevant `order_id` `id` or `project_id`. `project_id` is not indexed, leading to a heavy non-selective scan on the primary key for databases with many `sale. order` records. There is poor selectivity with the filter on `sale. order.line` resulting in a heavy join between `sale.order` and `sale.order.line`. This commit adds the missing index, allowing for `Bitmap Heap Scan` on both indexes and leveraging the selectivity of the project being currently opened. Benchmark --------- On a database with 3.5M `sale.order`, 12M `sale.order.line`, opening the "Settings" page of a project with a few sale lines associated with it took: | | Before | After | |--------------|--------|-------| | Timing (hot) | 9.1s | 5ms | Reference --------- opw-5280364 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239114 Forward-Port-Of: odoo/odoo#238995
This update fixes an issue where the debit note button was missing on credit notes and refunds. The button was recently moved to the invoice header, but this change only applied to invoices and bills. This fix ensures the button is visible for refunds, which is crucial for processing transactions in regions like Latin America.
Original PR description
The button for debit note is not visible on credit notes and refunds. Since f29c106b57dd6e8ca19ccc2d2479542f202d1c77 the button for debit note has been moved from action menu to the header of the invoice form, but the commit makes it only visible for invoices and bills, while it was also visible for credit notes and refunds before. The button needs to be also visible for CN/refunds as it is necessary for many countries, like latam countries opw-5385273 Forward-Port-Of: odoo/odoo#239019
This update resolves an issue in the German localization (l10n_de) module where changing a product's cost in a multi-company environment caused access errors and data inconsistencies. The problem stemmed from fetching taxes within a privileged (sudo) environment, leading to incorrect data retrieval. This fix ensures accurate tax calculations and data access after cost changes.
Original PR description
from v18.0 to v18.4, in a multi-company environment, when a product with no income/expense account had its cost changed, all the taxes for other companies were being fetched which caused access errors when trying to view it after a manual save. This happens because the fetch is happening in a sudo environment because the stock valuation layer was being created as sudo, so all taxes were being fetched and probably because of cache pollution they were not being filtered properly, this is not happening in v19.0 because the stock valuation layer was removed, so everything is being called in a normal user environment, refer to this commit-08b62a4 task-5117882 Forward-Port-Of: odoo/odoo#236931
This update fixes issues with the creation and formatting of snailmail reports. Specifically, a new function extracts PDF generation, ensuring consistent page layouts and cover pages. It also addresses a bug preventing the correct generation of followup reports, improving the reliability of snailmail communications.
Original PR description
#### [FIX] snailmail: extract report PDF generation function We extract a function `_generate_report_pdf` from `_fetch_attachment` to create the report PDF (and its filename). The resulting PDF's…
#### [FIX] snailmail: extract report PDF generation function We extract a function `_generate_report_pdf` from `_fetch_attachment` to create the report PDF (and its filename). The resulting PDF's margins are fixed and a cover page is added to it after the function is called in `_fetch_attachment`. The new function is extended in the related enterprise commit to generate the followup report inside `_fetch_attachment` (when sent via snailmail). This way it will respect the cover page option and page layout / size requirements. (See the related enterprise PR for more details.) #### [FIX] snailmail: extract letter resending function We extract a function `_resend_letters` from the `update_resend_action`. It handles the regeneration of letters after the cover option has been updated. This way the resending logic can easily extended to adjust the logic depending on attributes of the letter. The new function is extended in the related enterprise commit to disable the resending for followup report letters. This is necessary because the followup report requires special options to be generated that are not available at the point of the regeneration. #### references opw-5160121 opw-5209504 opw-5226366 Forward-Port-Of: odoo/odoo#238905 Forward-Port-Of: odoo/odoo#235699
This update fixes issues with sending follow-up reports via snailmail, specifically addressing address formatting, cover page functionality, and PDF layout compatibility with our Pingen provider. The changes ensure accurate address delivery, enable cover page options, and optimize the PDF for successful processing, preventing potential delays or rejections.
Original PR description
#### [FIX] snailmail_account_followup: fix address, cover page and layout Currently there is the following potential problem when sending the followup report via snailmail. 1. The address generation…
#### [FIX] snailmail_account_followup: fix address, cover page and layout
Currently there is the following potential problem when sending
the followup report via snailmail.
1. The address generation is not adjusted for snailmail. That can
lead to problems with the service we use to send the actual letter.
They validate the address rather strictly.
2. The cover page option does not work; it does not add a cover page.
So we can not work around problems with the address generation
by adding a cover page.
3. The layout / dimensions / margins of the generated document / PDF may not work
with our current snailmail provider (Pingen). But there is no error
message about it. (Although we do have something in the usual
snailmail flow)
4. In case the address is invalid we do not try to "print" / send the letter,
so the user does not receive any feedback.
This could be an issue in case multiple follow-up reports are sent
at the same time.
This commit fixes these issues. (See below for details.)
(1)
The logic for this already exists but it is only activated when
a context key is set. This is not the case currently.
After this commit we do set the key.
(2) & (3)
The issue is that we generate the PDF attachment before creating the
'snailmail.letter' record.
In the usual snailmail flow the PDF attachment generation is handled during the sending and
printing (in function `_fetch_attachment` on model 'snailmail.letter').
There is some special logic to
- add a cover page to the report PDF (if the option is selected)
- make sure the page dimensions of the PDF are okay
- overwrite the margins of the PDF with white to make sure the PDF is
not rejected by Pingen because of this
But all this only happens if we do not have an attachment already.
(So it does not happen currently with the followup report)
For this a function called `_generate_report_pdf` was extracted from `_fetch_attachment`
in the related community commit to generate the report PDF (and its
filename). The function is extended here to be able to generate the
followup report.
(4)
We try to print / send the letter even if the address is invalid
Reproduce (i.e. for the cover page issue; but it explains how to get
the PDF that will be sent in general)
1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Set the "Add a Cover Page" option
(Settings -> Accounting -> section "Customer Invoices")
- enabled to test for the cover page
- disabled to test that the address generation is adjusted
4. Send a follow-up report:
- On 17.0: Accounting -> menu: "Customers" / "Follow-up Reports"
-> click on a line / partner -> button "Follow up"
- On 18.0+: partner form view -> tab "Accounting"
-> section "invoice follow-ups" -> button "Send"
5. Go to the snailmail letter:
In debug mode: Settings -> menu: "Technical" -> section: "Email" -> "Snailmail Letters"
(or just search for "snailmail" in the main screen)
And select the letter
6. Download the PDF document
#### [FIX] snailmail_account_followup: forbid regenerating failed letters
The wizard to resend failed letters which allows to change the
cover page option is broken: The follow-up report can not be regenerated
correctly because it requires special follow-up specific `options` that are
lost after the initial pdf generation for the letter.
Currently it can happen that the follow-up PDF is regenerated but
without (actual) content (table listing the overdue amounts).
After this commit we cancel the snailmail letters and show an
error notification indicating that the followup needs to be done again to
create a new letter.
Reproduce
(needs credit on IAP or locally edit this function https://github.com/odoo/odoo/blob/3ffd51f1cb18e3f4fb0367c4a498d7438e0c0357/addons/snailmail/static/src/core_ui/message_patch.js#L11
to open the resend wizard `this.openFormatLetterAction()` for `sn_credit` error or always)
1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Ensure the address of the partner causes issues with Pingen
4. Ensure the cover page option is disabled:
Settings -> Accounting -> section "Customer Invoices"
5. Send a follow-up report:
- On 17.0: Accounting -> menu: "Customers" / "Follow-up Reports"
-> click on a line / partner -> button "Follow up"
- On 18.0+: partner form view -> tab "Accounting"
-> section "invoice follow-ups" -> button "Send"
6. Make some modifications like editing the follow-up message or a custom attachment
7. Download the snailmail letter PDF (see previous commit for details)
8. In the chatter go to the message saying "Letter sent by post with Snailmai"
9. Click on the red symbol (paper plane) next to the name
10. A "Format Error" wizard should show up
11. Select "Add a Cover Page"
12. Click the button "Update Config and Re-Send"
13. Download the snailmail letter PDF (see previous commit for details)
14. Compare PDFs from 7 and 13; they are different (not just the cover page)
#### references
opw-5160121
opw-5209504
opw-5226366
Forward-Port-Of: odoo/enterprise#101596
Forward-Port-Of: odoo/enterprise#99491This update resolves an issue where the Czech VAT control statement incorrectly calculated amounts for invoices in foreign currencies (specifically EUR). The fix ensures accurate reporting by using the absolute value of the signed total when foreign currency amounts are processed, aligning with Czech tax regulations.
Original PR description
With l10n_cz_reports: - Create a currency exchange between CZK and EUR where the EUR is valued at least at twice the amount of CZK. - Create an invoice in EUR, with a line with price_unit 5000 and a tax. - In the CZ Tax Report, in the VAT control statement, the converted amount is found in section B.3, which contains received taxable supplies and provided payments up to CZK 10,000. However, the converted amount of the invoice in CZK is higher than 10,000. In `_report_custom_engine_control_statement`, the amount used to check whether the move should be included in this section uses `amount_total`, which in the case of foreign currency gives the wrong result. If the move is in a foreign currency the total is not in CZK so we have to use the absolute value of the signed total. opw-5080339 Forward-Port-Of: odoo/enterprise#100456
This update fixes an issue where batch barcode scanning wasn't working correctly with multiple pickings. The system now correctly merges moves by picking, ensuring accurate tracking of batch inventory. This improves the reliability of batch management within the Odoo Enterprise system.
Original PR description
Steps to reproduce ----- - Enable batch pickings - Create a product - Create 2 receptions for the product (qty > 1) - Create a batch with the 2 transfers - Open the batch in barcode - Scan part of…
Steps to reproduce ----- - Enable batch pickings - Create a product - Create 2 receptions for the product (qty > 1) - Create a batch with the 2 transfers - Open the batch in barcode - Scan part of both pickings - Go back to the barcode main screen - Open the batch again > Both pickings have their demand = partially delivered quantity Cause ----- When leaving the page, we trigger https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L65-L68 in which we end up merging the moves together https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L51 This has been added by 9753c24 (ade0bef in 17.0) The problem is that `_merge_moves` merges all of the moves into the first of `merge_into` https://github.com/odoo/odoo/blob/26761e04bb648b46cd35697c6cbc8ed1e27fef90/addons/stock/models/stock_move.py#L1086-L1088 This, however, doesn't make much sense for batches because the moves can be from different pickings. ----- Ticket: opw-5163740 Forward-Port-Of: odoo/enterprise#101630 Forward-Port-Of: odoo/enterprise#100940
This update fixes issues where video settings were lost or not applied correctly when adding or editing video snippets. Specifically, it ensures that options from URLs and manual edits are now properly captured and applied, improving the user experience when embedding videos.
Original PR description
Issues: 1. Resetting options when dialog is closed without modification: When the media dialog is closed without changing any options and "Add" is clicked, the videoSelector component is reset,…
Issues:
1. Resetting options when dialog is closed without modification:
When the media dialog is closed without changing any options
and "Add" is clicked, the videoSelector component is reset, causing
previously selected parameters to be lost.
- Steps to reproduce:
- Drop a Video snippet.
- Double-click the snippet and toggle a few options (e.g., "Loop").
- Save the video configuration.
- Double-click the snippet again to open the video configurator.
- Save without making any changes.
- The options will be reset.
2. Embedding videos via Powerbox does not capture URL query parameters:
When embedding a video via Powerbox, option values from the URL
query parameters (like loop or autoplay) are not correctly applied.
- Steps to reproduce:
- Add any Text snippet.
- Paste a YouTube video URL with query parameters (e.g., ?loop=1&autoplay=1).
- Choose to embed the YouTube video from the Powerbox popup.
- The Video snippet is added without options enabled for the pasted URL.
3. Manual URL editing does not synchronize options:
Editing the video URL manually does not update the toggle states
of corresponding options.
- Steps to reproduce:
- Drop a Video snippet.
- Double-click the snippet and append query parameters to the URL.
- The option buttons should toggle according to the parameters, but they do not.
4. Dailymotion preview fails for protocol-independent URLs:
Previewing Dailymotion videos fails for URLs like //[www.dailymotion.com/](http://www.dailymotion.com/)....
- Fixes implemented:
- Preserve selected options when saving the Video snippet without any changes.
- Retrieve all query parameters from the URL and include them in the RPC request.
- Synchronize option toggles with the URL input when the user manually edits it.
- Fixed the Dailymotion regular expression to support protocol-independent
URLs (e.g., //[www.dailymotion.com/](http://www.dailymotion.com/)...).
task-4529118
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238732
Forward-Port-Of: odoo/odoo#210596This update fixes an issue where Turkish language translations weren't properly applied after installing the 'l10n_tr_nilvera' module. Previously, the system only activated the language but didn't update existing translations. Now, the installation process correctly updates translations across all modules, ensuring accurate Turkish language support.
Original PR description
### Issue: When installing "l10n_tr_nilvera" on a new DB the Turkish language is installed but the translation of previously installed modules are not updated. ### Steps to reproduce: - Install…
### Issue: When installing "l10n_tr_nilvera" on a new DB the Turkish language is installed but the translation of previously installed modules are not updated. ### Steps to reproduce: - Install 'l10n_tr_nilvera' and switch to a Saudi company - Check the view "report_invoice_document" - Click the translation icon on the view - No Turkish translations are loaded ### Cause: When installing "l10n_gcc_invoice" the Arabic language is installed ([src](https://github.com/odoo/odoo/blob/70404624d7ea6f971182cbe4f4fe8fc064d2afd8/addons/l10n_gcc_invoice/__init__.py#L4-L5)). But the method [`_activate_lang()`](https://github.com/odoo/odoo/blob/70404624d7ea6f971182cbe4f4fe8fc064d2afd8/odoo/addons/base/models/res_lang.py#L161-L169) only activates the language, it does not update the translations. ### Solution: Create a new method that activate the language and calls `_update_translations()` on the installed modules. opw-5219783 Forward-Port-Of: odoo/odoo#239310 Forward-Port-Of: odoo/odoo#237041
This update enhances user privacy by permanently providing access to the Cookie Policy page and allowing users to update their consent choices at any time. Previously, users could only access the policy through a popup that disappeared after accepting cookies. Now, changes to cookie preferences are correctly reflected, ensuring accurate tracking data.
Original PR description
This improvement enhances user control over cookie preferences by making the Cookie Policy page (/cookie-policy) more accessible and allowing users to modify their consent at any time. **Issue:** -…
This improvement enhances user control over cookie preferences by making the Cookie Policy page (/cookie-policy) more accessible and allowing users to modify their consent at any time. **Issue:** - Previously, the only way to access the Cookie Policy page was through the link in the cookie consent popup. However, once users accepted cookies, the popup was no longer displayed, making it impossible to navigate to the policy page later. - Additionally, the Cookie Policy page had a button to reopen the cookie consent popup, but it was only visible if cookies were not accepted. Once cookies were accepted, the button was hidden, preventing users from changing their preferences. **Improvements:** - Added a permanent link to the Cookie Policy page in the copyright footer, ensuring it remains accessible at all times. - The cookie consent toggle button now remains visible even after a user has accepted cookies, allowing them to update their preferences at any time. task-[4502416](https://www.odoo.com/odoo/project/974/tasks/4502416) Forward-Port-Of: odoo/odoo#238772 Forward-Port-Of: odoo/odoo#203409
This update resolves an error that prevented users from creating consolidated invoices for multiple POS orders linked to the same customer. The fix ensures the correct date and refund reason are used when generating these invoices, allowing for seamless consolidated billing. This improves the reliability of the SA POS invoicing process.
Original PR description
Currently, an error occurs when trying to create a consolidated invoice for multiple POS orders associated with the same customer. **Steps to reproduce:** - Install the `l10n_sa_pos` module and…
Currently, an error occurs when trying to create a consolidated invoice for multiple POS orders associated with the same customer. **Steps to reproduce:** - Install the `l10n_sa_pos` module and switch to the `SA company`. - Create two POS orders for the `same customer` without invoicing at checkout. - Close the POS session and go to `Point of Sale` > `Orders`. - Select both orders > click `Create Invoice` > `confirm` the action. (Make sure `Consolidated Billing` is enabled) **Error:** `ValueError: Expected singleton: pos.order(8, 7)` **Root cause:** At [1], the code accesses `self.date_order` and `self.l10n_sa_reason`, but when consolidated billing is enabled, self contains multiple POS orders, which causes an error. **Fix:** This commit prevents the error by ensuring that the current datetime is assigned when creating a consolidated invoice, same as [2]. For the refund reason, a fix similar to [3] has been applied. [1]: https://github.com/odoo/odoo/blob/0c87b6b8836522913dbe77b57a018ac26012edca/addons/l10n_sa_pos/models/pos_order.py#L17-L18 [2]: https://github.com/odoo/odoo/blob/583bacdc8ad2b87b99b11d1e12dacf6e42edf22b/addons/point_of_sale/models/pos_order.py#L828-L832 [3]: https://github.com/odoo/odoo/blob/0c87b6b8836522913dbe77b57a018ac26012edca/addons/l10n_es_edi_tbai_pos/models/pos_order.py#L103-L107 opw-5266908 Forward-Port-Of: odoo/odoo#237677
This change optimizes website test performance by caching image processing steps. Previously, a test was repeatedly parsing HTML, causing significant delays. The fix ensures this process happens only once, reducing test execution time and improving overall system responsiveness.
Original PR description
__Behavior before commit:__ `getWebsiteSnippets` is called *at least* twice per website Hoot test. - [When opening the sidebar][1] - [When `render_public_asset` is called][2] Although the orm result is cached using `websiteSnippetsPromise`, it still calls `removeImageSrc` everytime. But inside `removeImageSrc`, this line takes around 50 ms to execute: ```js new DOMParser().parseFromString(xmlString, "text/html") ``` Therefore wasting at least 100 ms per test. __Fix:__ Make the promise encompass the result of `removeImageSrc` so that it is called only once at the beginning of the test suite. [1]: https://github.com/odoo/odoo/blob/2dc9529af127ed4b2d451059b6ab9c83778c7814/addons/website/static/tests/builder/website_helpers.js#L281 [2]: https://github.com/odoo/odoo/blob/2dc9529af127ed4b2d451059b6ab9c83778c7814/addons/website/static/tests/builder/website_helpers.js#L51 task-5269391
This update resolves a bug where the OCR process incorrectly assigned foreign currencies to expense items, particularly when linked to products with standard prices. Now, users can correct the currency and total amount after the OCR, ensuring accurate reimbursements and preventing disruptions to the expense workflow. This improves the reliability of expense data.
Original PR description
Fixes a bug where the OCR would sometimes put a foreign currency on an expense with a product having a cost. Making it impossible to switch back to the company currency (because the currency cannot be changed). This also allows the user to change the total amount after the OCR pass, so it can be corrected if needed task-4873236 Forward-Port-Of: odoo/enterprise#101822 Forward-Port-Of: odoo/enterprise#89093
This update fixes an issue where the barcode scanning app on mobile devices displayed stock locations in a list view, which wasn't ideal for small screens. The change ensures that the app prioritizes kanban views on mobile, providing a more user-friendly experience when scanning barcodes and viewing stock information.
Original PR description
Issue ===== On mobile, we should prioritize kanban views over list views because kanban views are usually more suitable for small device screen. That said, when a product's barcode is scanned in the Barcode app main menu, we show this product's stock locations but we do that with a list view, no matter if the user is on a big screen or a small screen. How to reproduce ================ On mobile device: - Enable location and have a product with a barcode and with quantities in two different locations; - Open Barcode app; - Scan the product's barcode => The product's stock locations are displayed in a list view, which is not very pratical on small device. Fix === The action key `mobile_view_mode` was not set, with this key, we can define what view type we want to prioritize for mobile device. [opw-5180783](https://www.odoo.com/odoo/project/49/tasks/5180783) Forward-Port-Of: odoo/enterprise#101336
This update fixes a performance issue in Odoo's PDF upload functionality. By upgrading the PDF.js library, we've addressed a bug that previously caused an infinite loop when handling corrupted files. This ensures smoother and more reliable PDF uploads for our users.
Original PR description
This commit updates the PDF.js library to patch the issue related to: https://github.com/mozilla/pdf.js/pull/18878 In Odoo this issue raises a performance issue that makes a infinite loop when you upload a corrupted file and Odoo tries to upload a traceback. OPW-5214755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238994 Forward-Port-Of: odoo/odoo#236471
This update addresses a technical issue related to PDF uploads in the Odoo Enterprise system. Specifically, it patches a performance problem that could cause an infinite loop when corrupted files are attempted to be uploaded, preventing data loss. This ensures smoother and more reliable PDF handling within Odoo.
Original PR description
Modification of module to align it with the newer version This commit updates the PDF.js library to patch the issue related to: mozilla/pdf.js#18878 In Odoo this issue raises a performance issue that makes a infinite loop when you upload a corrupted file and Odoo tries to upload a traceback. OPW-5214755 Forward-Port-Of: odoo/enterprise#101551 Forward-Port-Of: odoo/enterprise#99912