Thursday, December 11, 2025
50 changes · saas-18.4
Resolved 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 LWF report incorrectly included data from previous departments when a new department was selected. The fix clears existing report data before generating a new report with the chosen department, ensuring accurate reporting of labour welfare fund contributions. This improves the reliability of the LWF report for users.
Original PR description
Step to reproduce: - Install l10n_in_hr_payroll. - Create 3-4 employee with labour welfare fund, all in different departments. - Open the LWF report wizard and do not select any department. -…
Step to reproduce: - Install l10n_in_hr_payroll. - Create 3-4 employee with labour welfare fund, all in different departments. - Open the LWF report wizard and do not select any department. - Download report , all employee will come in report. - Now select any department and download report again. - All employee(It is fetching previous data) + employee from selected department will come in report. Cause: - In '_compute_line_ids()' wizard computed field 'line_ids' doesn't properly reset previous lines as a result previous data remains in lines. - When the department is changed, the wizard id remain same, so previously lines added to wizard are coming with new lines. - Using `Command.link()` for new lines is invalid because it requires an existing database record ID, but wizard lines are creating inside a compute method so their IDs are only saved after the flush. Fix: - Since this is a stable version, clear the previously existing lines using 'Command.clear()' before creating new ones. Task - 5366498 Forward-Port-Of: odoo/enterprise#101190
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 where outdated records in the system's data management (ir.model.data) persisted after a model was removed. These lingering records could cause errors and instability. The fix ensures that these records are properly cleaned up, improving system reliability and preventing potential problems.
Original PR description
When a model is unlinked, the `ir.model.data` related to that model wasn't cleaned up. This leaves dangling records that can generate issues. sentry-6938852090 Forward-Port-Of: odoo/odoo#236615
This update resolves an issue where the demo stock data installation incorrectly used US currency, causing problems when users have databases with different currencies (like EUR). The fix ensures the demo data installation works correctly regardless of the company's currency, improving data consistency and usability.
Original PR description
Currently in the `_merge_move_itemgetter` the system call `self.company_id.currency_id.decimal_places`. However the demo data of stock create a database with US currency and some `stock.move` in it. If we have an existing database with EUR for example. The upper call will return a `currency_id.decimal_places` since we have multiple currency. The best solution, would be to split `_action_confirm` to do a loop by company. But it would need a small refactoring and we will do a minimal diff to fix this issue. Using the smallest currency among all the company is not always correct but it's a super edge case and we should probably remove this code since it went to far. Close #230965, #234078 Forward-Port-Of: odoo/odoo#239273
This update resolves an issue where a test for the website color picker was failing due to timing problems. The fix ensures the test waits for all steps in the color selection process, preventing inconsistent and unreliable test results. This improves the stability of the website customization feature.
Original PR description
__Behavior before commit:__ Since `edit` writes one character after the other, using it on a color picker to write an RGBA color calls `make_scss_customization` when the input value reaches the RGB color. Then, another call is made when the entire color is written (because they are both valid colors). However usually the test finished before the steps for the second call were reached because the `Deferred` was only waiting for the first call. __Fix:__ Wait for all steps to avoid nondeterministic behavior. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/234621
A recent change in the Employee Skills pie chart report caused an error when users clicked on individual data points. This fix prevents the error by addressing a removal of a previous list view functionality. Users can now reliably access the chart data.
Original PR description
Clicking a record in the Employee Skills pie chart report currently triggers a traceback. Steps to reproduce the error: - Install ``hr_skills`` module with demo data - Open any employee > In Resume…
Clicking a record in the Employee Skills pie chart report currently triggers a traceback. Steps to reproduce the error: - Install ``hr_skills`` module with demo data - Open any employee > In Resume tab, Click on TIMELINE - Switch to Pie chart > click on any record Traceback: ```py UndefinedColumn: column hr_employee_skill_history_report.id does not exist LINE 1: SELECT "hr_employee_skill_history_report"."id" FROM "hr_empl... ``` ``hr.employee.skill.history.report`` model is ``_auto=False``, meaning that no database table is created for this model. In earlier versions, clicking on the record opens the list view. In the [commit](https://github.com/odoo/odoo/commit/341fe890d2b7001dab1e3cd65ecb0c3bb4ed327e), list view was removed. So, now clicking on the record will lead to the above traceback. [1]: https://github.com/odoo/odoo/commit/341fe890d2b7001dab1e3cd65ecb0c3bb4ed327e sentry-7099766240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue where website snippets were displaying incorrectly, often leaving them blank. The fix focuses on limiting the snippet's visibility to product pages, ensuring it functions as intended without impacting other website areas. This improves the overall user experience on product listings.
Original PR description
This PR fixes an issue introduced in Commit[^1] while trying to fix an issue with the alternative products section being displayed even with no alternative products. In Commit[^1], the rule was set in the snippet file, which worked but was affecting all the places where this snippet is displayed, which made the snippet preview empty. To ensure this does not happen, we scope the rule to the product page only, ensuring the snippet remains untouched. [^1]: https://github.com/odoo/odoo/commit/0dfc5a6cfbae808f2dc5c7042bc07180eaa49e9a task-5404601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 ensures that a key stock test consistently produces the same results. Previously, slight timing differences in test execution could cause the test to fail intermittently. To guarantee reliable test results, the test now freezes time to eliminate these timing variations.
Original PR description
In a previous fix in #174442, we ensured that the order of moves when freeing reservation would remain deterministic, even if move dates were the same. In the test however, we didn't make sure that both moves were created at the exact same time, meaning that in some case, a millisecond could pass between the two moves creation, making the later assert checking if both dates are the same wrong, and making the test irrelevant. Now freeze the time at an irrelevant date just to make sure the test always does what it was intended to do. runbot-233470 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239229
This update fixes an issue where subscription details weren't being displayed correctly within the dashboard. Specifically, it corrected a filtering problem and ensured subscription titles were accurately shown. This improves the clarity and usability of the subscription section for users.
Original PR description
Before this commit, when subscriptions were linked to the analytic account of a project, the sale order items appears in an unwanted section when the section is unfolded. Meanwhile, when the subscription section is unfolded the title of the subscriptions items are not correctly displayed. The first issue is due to the fact that we did not correctly exclude the subscriptions items from the domain. The second issue is due to the fact that we fetch the field 'name' from the subscription search instead of the field 'display_name' task-5159781 Forward-Port-Of: odoo/enterprise#97238
This update corrects a technical issue that was preventing the generation of WPS files in the Saudi HR payroll module. The fix addresses an error caused by incorrect function usage, ensuring reports are now created reliably. This resolves a potential disruption to payroll reporting.
Original PR description
this commit addresses traceback errors occured due to incorrect usage of `_` function. task-5310946 Forward-Port-Of: odoo/enterprise#99789
This update resolves a problem in the tests for the 'pos_settle_due' module that was failing due to a hardcoded year. The fix ensures the tests work correctly regardless of the current year, improving the reliability of the testing process. This prevents potential disruptions during development and ensures accurate test results.
Original PR description
When running the pos_settle_due tests with faketime, the tour pos_settle_account_due was failing cause of a hardcoded year which would not work on another year. This is now fixed. runbot-error: 234052 Forward-Port-Of: odoo/enterprise#101217
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 a technical issue where users could inadvertently modify parser rules after the parser was initially set up. This change ensures data integrity by preventing unauthorized modifications to the parser, improving the stability and reliability of Odoo's data processing.
Original PR description
The parser rules cannot be modified once the parser has been instantiated. task-5091744 Forward-Port-Of: odoo/odoo#239046
This update resolves a problem where invoices generated in Arabic were sometimes printed incorrectly, with missing logos or repeated headers. The fix reduces the number of invoices processed at once, allowing the printing software to render them correctly. This ensures all invoices are printed accurately.
Original PR description
Repro steps: 1. Create a customer whose language is Arabic 2. Create 16 or more invoices for that customer 3. Send these invoices together all at once Issue: PDFs generated for the invoices are strange, some have missing logo in the header, while others have the header repeated multiple times on the page. Root cause: wkhtmltopdf does not have enough time to render all these PDFs at once, so it fails to render them properly leading to these half-rendered PDFs. Solution: This commit solves this issue by reducing the number of invoices that the cron processes at once from 20 to only 10 (the default of the function _cron_account_move_send). This would ensure that wkhtmltopdf has enough time to process and render a batch of invoices at once. opw-4997495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236810
This update fixes an issue where GIF image sizes were incorrectly displayed in the Odoo builder. A previous workaround was removed, and the system now accurately shows the size of GIF images, aligning with other image types. This ensures consistent and accurate image representation within the builder.
Original PR description
`*` = html_builder, html_editor A previous workaround [[1]](https://github.com/odoo/odoo/commit/520dde6f20742229de32c7bf781ab4208284ee79) hid GIF file sizes in the builder because `_processImage` used to return incorrect data for GIFs, causing their size to appear as "NaN kb". The underlying `_processImage` issue was fixed in [[2]](https://github.com/odoo/odoo/commit/27be6d81497b49939d039361dc602d4575e23502), but the workaround from [[1]](https://github.com/odoo/odoo/commit/520dde6f20742229de32c7bf781ab4208284ee79) was never reverted. This commit removes that leftover logic and restores correct size display for GIF images, bringing them back in line with other image types. task-[5071548](https://www.odoo.com/odoo/project.task/5071548) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures compatibility with new IoT Boxes by adding a necessary request parameter. The customer display data service was recently simplified, but this change restores functionality to support the v19.1 IoT Boxes and their response formats. This ensures a smooth experience for users utilizing these devices.
Original PR description
In `saas-18.4` and `19.0` the customer display data service was simplified as we refactored to control IoT displays with actions instead of controllers.
However, to ensure compatibility with v19.1 IoT Boxes, we need to add a request parameter back and to accept both responses: `result: { data: { ... } }` and `result: { ... }`.This update resolves an issue where document previews were not updating correctly after renaming documents. The fix ensures that the preview always displays the most recent document name, regardless of how the document was renamed (e.g., via the 'Rename' action or the chatter interface).
Original PR description
BUG 1: --------- **steps to reproduce**: 1. Install documents 2. Open any document 3. Go to Action > Rename 4. Rename the document 5. Preview it and read the name showed there **issue**: When…
BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there
**issue**:
When previewing the document, it still shows the old attachment name.
**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:
1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130
2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383
**solution**:
Use the document name when previewing it
BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.
**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.
**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.
Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.
**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.
**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
<summary>Click here to see the results:</summary>
Before:
<img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
After:
<img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>
</details>
opw-5065433
Forward-Port-Of: odoo/enterprise#101183
Forward-Port-Of: odoo/enterprise#95111This update resolves a technical issue that caused a traceback when reloading the WorkEntries page in Odoo Studio. The fix ensures Studio correctly loads the page after a reload, improving stability and preventing disruptions for users. This change focuses on internal technical improvements.
Original PR description
**Verison:** - saas-18.2 **Steps to reproduce:** - Go to an employee form view. - Click on the WorkEntries smart button. - Open Studio. - Reload page. **Issue:** - A traceback appears after reloading the page in Studio. **Cause:** - The smart button URL uses the model name hr.work.entry, but Studio’s service_action expects a path without dots. Because the action cannot be loaded correctly, the view breaks and triggers the traceback. **Solution:** - Return the proper path instead of the model name so that the action loads correctly. This prevents the error when reloading the page. task-5236317 Forward-Port-Of: odoo/odoo#239335 Forward-Port-Of: odoo/odoo#235662
This update resolves an issue where removing a video URL in the HTML editor would leave a broken iframe in the system, leading to errors. The fix ensures that when a video URL is deleted, the associated options are properly cleared, preventing the creation of invalid media entries and improving the user experience. This prevents 404 errors and ensures data integrity.
Original PR description
*=website **Steps to reproduce:** 1. Drop a video 2. Reopen the media dialog 3. Remove the URL 4. Confirm **Issue:** When the URL was removed and confirmed, an iframe without a valid source was saved, leading to a 404 error. **Fix:** When the video URL is cleared, VideoSelector component calls selectMedia with an empty object. MediaDialog did not previously handle this case, so the media selection was not cleared. Now we Update MediaDialog to treat an empty object as a clear-selection signal and disable the Add button accordingly. task-5190485 Forward-Port-Of: odoo/odoo#238884 Forward-Port-Of: odoo/odoo#234085
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#210596