Saturday, April 25, 2026
28 changes · saas-19.3
Resolved issues and error corrections
This update eliminates a misleading confirmation dialog that appeared when using the barcode app to add non-stockable products to delivery orders. The fix streamlines the process by leveraging existing data checks, ensuring a smoother user experience for all product types. This improves usability and prevents unnecessary interruptions.
Original PR description
### Steps to reproduce: - In the settings: Enable Multi-Steps Routes - Create a non-storable product P - Go to the barcode app > Operations > Delivery Order > New - Click on "Add Product" > select P…
### Steps to reproduce: - In the settings: Enable Multi-Steps Routes - Create a non-storable product P - Go to the barcode app > Operations > Delivery Order > New - Click on "Add Product" > select P as product > Confirm #### > A confirmation dialog appears: Oops! It seems that this product is not located in WH/Stock. Do you confirm you picked from there? ### Expected behavior: Since the product is not storable it should not trigger the dialog ### Cause of the issue: The `is_storable` value of the `product.product` is not part of the data that can be used to check if we should check the quantity available in location since only the product id and name are directly available: https://github.com/odoo/enterprise/blob/77d3cc81be8aeb9f2e8bf57fb561fcae80f23b04/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L70 However, since an rpc is already performed in order to determine the `qty_available` of the product, we might as well use that same rpc to recover the information and also avoid the dialog in case it is irrelevant. opw-6110655 Forward-Port-Of: odoo/enterprise#114173
This update corrects an error that prevented reading demo user data when demo companies were archived. The fix replaces the demo user with a standard user that's always accessible, ensuring demo invoices function correctly. This resolves a display issue within the demo environment.
Original PR description
Steps to reproduce: ------------------- 1. Create a new trial DB with demo data and French localization 2. Archive Marc Demo if you create the DB locally (this happens automatically on Odoo.com…
Steps to reproduce: ------------------- 1. Create a new trial DB with demo data and French localization 2. Archive Marc Demo if you create the DB locally (this happens automatically on Odoo.com trials due to the user seat limit probably) 3. Select the demo company only (unselect the main one) 4. Open Accounting and click the Sales journal from the dashboard Access Error about reading Marc Demo. Unarchiving him would work around this issue. Why the bug ----------- The sales demo invoices set invoice_user_id to Marc Demo (base.user_demo). Marc Demo belongs to the main company and can't be read from another company when archived. On 19.0 this did not break because the avatar widget only needed display_name (read with sudo). Commit https://github.com/odoo/odoo/commit/3732ca85b03bea9eabfb05cc306ce0bf5bac88d4 added write_date to it for cache busting, so now the read is real and the rule fails. The fix ------- Use base.user_admin instead: it's never archived, so it stays readable from any company. opw-6106870 Forward-Port-Of: odoo/odoo#259365
This update fixes an issue preventing access to demo data within Odoo trial instances. The problem stemmed from demo user accounts being archived, which caused errors when accessing demo records in separate companies. The fix changes the demo user account used for generating invoices and bills to a standard, always-accessible account, ensuring consistent demo data access.
Original PR description
Steps to reproduce: ------------------- 1. Create a new trial DB with demo data and French localization 2. Archive Marc Demo if you create the DB locally (this happens automatically on Odoo.com…
Steps to reproduce: ------------------- 1. Create a new trial DB with demo data and French localization 2. Archive Marc Demo if you create the DB locally (this happens automatically on Odoo.com trials due to the user seat limit probably) 3. Select the demo company only (unselect the main one) 4. Open Accounting and click the Purchases journal from the dashboard Access Error about reading Marc Demo. Unarchiving him would work around this issue. Why the bug ----------- demo_invoice_deferred and demo_bill_deferred set invoice_user_id to Marc Demo (base.user_demo). Marc Demo belongs to the main company and can't be read from another company when archived. On 19.0 these records only existed in the main company, where Marc Demo is accessible. Commit 9aed0c0135d7b084dee544c6566fad96c62ec1fd migrated the demo to `template`, so now they are created in every company. Still, it only breaks because of commit [3732ca85b03b](https://github.com/odoo/odoo/commit/3732ca85b03b), which added write_date to the avatar widget for cache busting. Before, the widget only needed display_name (read with sudo), so the rule was not checked. The fix ------- Use base.user_admin for demo_invoice_deferred (never archived, stays readable from any company), and False for demo_bill_deferred (a bill has no salesperson). opw-6106870 Forward-Port-Of: odoo/enterprise#113946
This update fixes an issue where chatter message highlights were appearing unexpectedly on the employee form in the HR Payroll module. The change restricts highlights to only the 'review_state' field, ensuring a cleaner and more focused user experience. This improves usability and reduces visual clutter.
Original PR description
The dropdown_selection_badge widget was triggering chatter message highlights on hover for all its usages (e.g. Dimona). Add an opt-in highlight_chatter attribute so only the review_state field on the employee form triggers this behavior. task-6131035 Forward-Port-Of: odoo/enterprise#114138
This update addresses a technical issue related to Odoo's integration with Peppol, a European network for electronic invoicing. By adding a new field to track the status of Peppol transactions, the system can now accurately determine if invoices were sent through Peppol. This enhancement ensures compatibility with evolving Peppol standards and future support for additional response types.
Original PR description
With the addition of new peppol_move_state for the Application Responses in Peppol, some checks to know wether the move was sent through Peppol were not updated. This commit does that by adding a common field for it. This is usefull as we might add some extra peppol_move_state values in the near future (Peppol supports more response types than we currently offer to our users). Forward-Port-Of: odoo/odoo#259064 Forward-Port-Of: odoo/odoo#258598
This update corrects an issue where lead conversions sometimes created duplicate company entries in the customer hierarchy, leading to data inconsistencies. The fix ensures that company creation is handled correctly using existing processes, preventing this duplication and maintaining accurate customer records.
Original PR description
**Issue:** When converting a lead with both `contact_name` and `partner_name`, the created contact end up with a duplicate company hierarchy, producing an invalid chain like: Person A < Company < Company **Cause:** `_create_customer()` was creating a company from `partner_name` in addition to the normal `parent_name` flow already handled by `res.partner.create()`, so the same company name was effectively used twice. **Fix:** Remove the extra company creation and let the existing `parent_name` behavior create the company once, then attach the contact to it directly. Task-6105653 Forward-Port-Of: odoo/odoo#259300
This pull request updates the translations for Odoo's SaaS version 19.3. It includes modifications to the core translation files (.weblate.json) and copies translations from the previous version (19.2) for various languages, ensuring accurate and localized user experiences across the accounting module and other affected areas.
Original PR description
Related: https://github.com/odoo/enterprise/pull/111141 Forward-Port-Of: odoo/odoo#257723 Forward-Port-Of: odoo/odoo#254667
This pull request updates the translations for Odoo Enterprise's SaaS version 19.3. It involves updating the core translation files (.weblate.json) and copying translations from the previous version (19.2) to ensure all languages are accurately supported. This ensures consistent and correct user experiences across all supported languages.
Original PR description
Related: https://github.com/odoo/odoo/pull/254667 Forward-Port-Of: odoo/enterprise#113055 Forward-Port-Of: odoo/enterprise#111141
This update fixes a calculation error related to early payment discounts on invoices. Previously, the untaxed amount was incorrectly displayed. The fix ensures accurate calculation by correctly identifying discount amounts as tax-excluded, leading to correct financial reporting.
Original PR description
Steps to produce: --- - Install the `Sales` module. - Go to `Invoicing > Configuration > Payment Terms`. - Open `Immediate Payment` and enable Early Discount. - Set `Reduced Tax` to `Always (upon…
Steps to produce: --- - Install the `Sales` module. - Go to `Invoicing > Configuration > Payment Terms`. - Open `Immediate Payment` and enable Early Discount. - Set `Reduced Tax` to `Always (upon invoice)`. - Go to Invoicing > Configuration > Taxes. - Create a 21% tax with `Tax included`. - Create a product with a sale price of 7.50 and assign the tax. - Create a Sale Order with this product > Set Immediate Payment as payment term. Issue: --- - The untaxed amount is computed as 6.22 instead of 6.20. Root cause: --- - At [1], in `_add_base_lines_for_early_payment_discount`, the base lines generated for early payment discount were missing the `special_mode='total_excluded'`. - Consequently, the tax engine interpreted these amounts as tax-included and attempted to recompute the untaxed base, resulting in an incorrect untaxed amount. Solution: --- - Add `special_mode='total_excluded'` to the base lines created for early payment discount computation. - This ensures the discount amounts are treated as already tax-excluded. [1]https://github.com/odoo/odoo/blob/a2b4f618328f3ce3f654fd2c1ee4410365706a7e/addons/sale/models/sale_order.py#L515-L550 opw-6023472 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260480 Forward-Port-Of: odoo/odoo#255724
This update ensures that VAT numbers in the VIES summary reports generated for Czech companies are formatted correctly, removing the country code. This is necessary to comply with official VIES XML requirements, preventing potential reporting errors and ensuring accurate data exchange with tax authorities.
Original PR description
**Steps to reproduce:** - Install the `l10n_cz_reports` module and switch to a `CZ Company` - Create an invoice for a customer with a VAT number, add a product, and set the Transaction Code (enable…
**Steps to reproduce:** - Install the `l10n_cz_reports` module and switch to a `CZ Company` - Create an invoice for a customer with a VAT number, add a product, and set the Transaction Code (enable it from the optional columns if needed). - Navigate to Reporting > VIES Summary Report. - Observe the value in the `VAT Number` column (includes country code). - From the dropdown, export the report as XML. **Observation:** In the generated XML file, the `c_vat` field contains the VAT number including the country code (e.g., `CZ12345679`) instead of only the numeric part (`12345679`). **Root cause:** At [1], the VAT number is directly taken from the report lines without removing the country code. **Fix:** This commit ensures that the `c_vat` field contains only the VAT number without the country code, complying with the official VIES XML format requirements. Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part) [1]: https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62 opw-6093259 Forward-Port-Of: odoo/enterprise#114990 Forward-Port-Of: odoo/enterprise#113083
This update resolves an error that occurred when users tried to access ticket links after an attendee was removed from an event. The fix prevents a technical error (IndexError) by gracefully handling empty attendee lists, ensuring ticket links always work correctly.
Original PR description
Currently, an error occurs when accessing the ticket link after the related attendee has been deleted. **Steps to Reproduce:** - Install the **Events** module. - Create a new event. - Create an attendee with a valid email ID. - Make sure the email is sent successfully. - Delete the attendee for the event. - From the received email, try to click on the **"View Tickets"** link. **Error:** `IndexError - tuple index out of range` **Cause:** The controller filters registrations using the provided `registration_ids`, but when the attendee is deleted, the resulting recordset becomes empty. It raises an error when trying to access the first element of an empty recordset. **Fix:** This commit handles empty recordsets by returning early when no registrations are found. sentry-7357927405 Forward-Port-Of: odoo/odoo#256310
This update fixes a technical issue where the Timesheet assistant was storing outdated suggestions in local storage, leading to performance slowdowns. The change automatically removes suggestions older than 30 days, optimizing the application and improving user experience.
Original PR description
In the Timesheets assistant, we store the suggested events taken or dismissed by the user to avoid suggesting them again. However, there is no mechanism to remove them from the localstorage, so it currently grows infinitely. With this PR, we now delete events older than 30 days, to avoid filling the localstorage with useless data. Task-6131640 Forward-Port-Of: odoo/enterprise#114562
This update optimizes the Odoo tracker to minimize unnecessary data collection and reduce the strain on system resources. The tracker was recently updated to use JavaScript, leading to increased tracking events. This fix aims to streamline the tracker's operation and improve performance.
Original PR description
The odoo tracker was [recently reworked to use JS](https://github.com/odoo/odoo/pull/247438) and allow website controllers to use readonly replicas. In the process, we increased the number of tracked events significantly. Since we don't intend to replace plausible/analytics - our tracker is used primarily for functional purposes. This PR aims to reduce calls to the tracking endpoint and ultimately reduce the amount of data in it. Part of Task-4939052
This update resolves a technical issue that prevented the system from correctly mounting components within messages, particularly when searching. The fix ensures that components load successfully, improving the overall stability and reliability of the messaging functionality. This change addresses a reported error and enhances the user experience.
Original PR description
Currently, there is a mounting issue when we have search in messages. As reported below,"cannot mount a component on a detached dom node at App.validateTarget". This commit uses the correct lifecycle hook to mount the component and catch mounting errors. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where styling applied to images (like rounded corners or shadows) was incorrectly carried over when the image was replaced with an icon. Now, the icon will always have a clean style, ensuring consistent appearance and preventing unexpected visual effects. This improves the user experience when switching between images and icons.
Original PR description
### Steps to Reproduce: - Go to the To-do app and create a new task. - Upload an image. - Apply shape styling to the image (e.g., rounded, shadow, img-thumbnail). - Replace the image with an icon. ### Description of the issue/feature this PR addresses: - When an image had shape applied (such as rounded, rounded-circle, shadow, or img-thumbnail) and was replaced with an icon, those classes were carried over to the icon. ### Desired behavior after PR is merged: - Since these classes are specific to image shape styling, they are now removed when an image is replaced with an icon. task-6007631 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259611 Forward-Port-Of: odoo/odoo#258060
This update resolves an issue where the employee offer salary wasn't correctly displayed when opening the offer form from the employee record. The fix adds a necessary context to ensure the correct salary amount is populated, improving the employee onboarding process. This ensures accurate salary information is presented to users.
Original PR description
task-5979287 Forward-Port-Of: odoo/enterprise#109067
This update corrects a recent change that removed the currency field from account batch payments. This ensures that monetary amounts are correctly associated with their respective currencies, preventing potential errors in financial reporting and reconciliation. The fix ensures data accuracy for financial transactions.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/301f63597b0c21fef16a1941314ac95602c8f01f removed some currency id field from the account bank statement and so the monetary field didn't have the currency anymore task-6131298 Forward-Port-Of: odoo/enterprise#115017 Forward-Port-Of: odoo/enterprise#114369
This update ensures service order line display names accurately show the price unit when requested, regardless of a previous display setting. Previously, the display was inconsistent, and this fix corrects that behavior by verifying the 'with_price_unit' context flag. This improves the clarity and accuracy of service order information for users.
Original PR description
Before this commit, when `formatted_display_name` is true in the context, the display name of `sale.order.line` records will always show the partner and the price unit if it contains a service product. The problem is `with_price_unit` is no longer checked in the context to really know if we want to display or not the price unit in the formatted display name. This commit checks `with_price_unit` in the context to display the price unit in the formatted display name if it is truly in the context. Forward-Port-Of: odoo/odoo#259080
This update fixes an issue where invoices incorrectly showed as 'Paid' after a check was voided. The change ensures that the invoice payment state reverts to 'not_paid' when a check is voided, preventing inaccurate payment tracking. This ensures financial reporting accuracy.
Original PR description
Steps to reproduce: 1- Install l10n_ar and l10n_latam_check modules 2- Switch company to (AR) Responsable Inscripto 3- Go to [Accounting -> Configuration -> Journals -> Bank] and make sure 'outstanding payments account' is set in outgoing payments for own checks and manual payment 4- Go to [Accounting -> Vendors -> Bills] and create a new bill 5- Create an own check payment for the full amount 6- Go to the check and void it Description of issue: When you view the invoice after voiding the check, it's payment state will be shown as 'Paid' Expected behavior: Invoice payment state should go back to 'not_paid' Why this happens: When the check is voided, it's `amount_residual` attribute becomes 0. This causes `pay.is_matched` to be True, and as a result `all_payments_matched` attribute is also True. This turns the invoice payment state to paid. opw-6016394 Forward-Port-Of: odoo/odoo#260872 Forward-Port-Of: odoo/odoo#256118
This update fixes a minor issue in the website editor where the round corners option would disappear when a border wasn't present. The change ensures the round corners option remains visible regardless of border settings, improving the user experience when customizing website blocks. This simplifies the process for users to apply rounded corners.
Original PR description
Steps to reproduce: - Open the website editor. - Select a block with the border configurator and round corners enabled. - Set the border width to 0 px. => The Round Corners option is hidden. Before this commit, the change introduced by [1] hid the option when no border was set. This restriction was not needed because a block can use a border radius without a visible border. After this commit, the option remains visible when round corners are supported, even without a border. [1]: 97e8cc8d664e66ba62e8282a67f069805682ae41 task-6089515 Forward-Port-Of: odoo/odoo#260633
This update resolves a visual bug in the Discuss feature where the 'offline' status indicator on avatars was incorrectly positioned in Safari. The fix adjusts how opacity is applied, ensuring the status icon displays correctly. This improves the user experience for all users on Safari.
Original PR description
IM status on avatars in Discuss have been improved to properly mask the image [1]. To do so, this uses SVG and ForeignObject on top of mask, so that it can uses font-awesome icons such as `fa…
IM status on avatars in Discuss have been improved to properly mask the image [1]. To do so, this uses SVG and ForeignObject on top of mask, so that it can uses font-awesome icons such as `fa fa-circle` for online status. This change introduced an accidental regression in Safari, where position of the offline status is wrong. This comes from a bug in Safari where some CSS inside foreignObject resets the position of the element to position 0, 0 on the global SVG [2] [3]. This affects offline status because this IM status has an `opacity-75`, intended to reduce distraction from the offline, but since this changes opacity this introduce the bug in Safari of mis-position. This commit fixes the issue by moving the applied CSS to change opacity from `opacity-X` rules inside foreignObject to the parent `g` tag above `foreignObject`. That way, the element inside `foreignObject` has no change of opacity but instead the `g` has it, which is ok for Safari. Note that this implementation assumes that change of opacity inside `foreignObject` is made only once and with `opacity-X` classnames. [1]: https://github.com/odoo/odoo/pull/246182 [2]: https://github.com/bkrem/react-d3-tree/issues/284 [3]: https://bugs.webkit.org/show_bug.cgi?id=23113 Task-6143646 Before / After <img width="308" height="579" alt="Screenshot 2026-04-21 at 12 51 52" src="https://github.com/user-attachments/assets/41596916-f371-407e-acb1-eb097c497360" /> <img width="310" height="584" alt="Screenshot 2026-04-21 at 12 51 20" src="https://github.com/user-attachments/assets/513df1f5-4cde-4cb7-8769-d6264dfb36a0" /> Forward-Port-Of: odoo/odoo#260341
This update resolves an issue where accounting administrators without Point of Sale access would encounter an error when viewing invoices linked to POS orders. The fix removes unnecessary access restrictions within the Odoo system, allowing authorized users to correctly access and manage invoices.
Original PR description
An accounting administrator without Point of Sale access would get an AccessError when opening a customer invoice linked to a POS order. The `edi_show_cancel_button` computed field calls `_get_move_applicability()`, which in turn calls `_move_has_settle_or_deposit_pos_order()`. That method was reading `invoice.pos_order_ids.lines` without `sudo()`, causing the ORM to enforce access rights on `pos.order` for the current user. Users who only have accounting rights (no "Point of Sale/User" or "Inventory/User" group) would therefore get an AccessError. opw-6044860 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258772 Forward-Port-Of: odoo/odoo#254905
This update corrects a misleading issue in the Z report generated with date ranges. Previously, the report header incorrectly displayed information from a single session even when multiple sessions with completed orders were included. Now, the report header accurately reflects the sessions contributing to the report data, ensuring a more precise and reliable report.
Original PR description
Before this commit: - When generating a Z report via date range (config_ids, no session_ids), the header's session name was derived from the closed-session if there was exactly one, which excludes open sessions (stop_at IS NULL). - If an open session had completed orders (state='done') within the date range, those orders were included in the report body while the session itself was absent from the sessions list. - This caused the header to display the closed session's name and title the report as a single-session Z report, even though it contained data from multiple sessions. opw-6123054 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259900
This update fixes an issue where combo products weren't calculating prices correctly when multiple items were purchased. Specifically, the system was misinterpreting quantities, leading to inaccurate pricing for items within the combo. This ensures accurate pricing and prevents overcharging for multiple items.
Original PR description
When buying more than one unit of a combo product, the free-item quota (qty_free) was not scaled by the parent quantity, causing child lines with qty > 1 to be partially mis-classified as extra. This meant the same line was processed by both the free and extra loops, with the extra loop overwriting the correct price. Additionally, the proportional price_unit for free child lines used the unscaled original_total (which already includes the parent qty factor) against a per-unit parent_lst_price, resulting in a price that was too low by exactly the parent qty factor. opw-6045562 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261222 Forward-Port-Of: odoo/odoo#258753
This update resolves an issue where loading sale orders from the point-of-sale (POS) system would fail if the order contained archived products. Now, sale orders can successfully include products that have been archived, improving the flexibility and usability of the POS system. This change was made to address a reported bug (opw-6116760) and ensures a smoother user experience.
Original PR description
Before this commit, loading a sale order from pos would raise an error if the order contained a product that had been archived. opw-6116760 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260638
This update resolves an issue where barcode quantities were displayed with slight rounding errors due to how JavaScript handles decimal numbers. The fix ensures accurate quantity representation, particularly when dealing with batch transfers and wave operations, improving data reliability.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to Settings and enable: * Storage Locations (Warehouse). * Batch, Wave & Cluster Transfers. * Create a Product and set its on-hand quantity to…
**Steps to reproduce:**
* Install `stock` module.
* Go to Settings and enable:
* Storage Locations (Warehouse).
* Batch, Wave & Cluster Transfers.
* Create a Product and set its on-hand quantity to 60.
* Go to Inventory → Configuration → Operation Types and create a new operation type:
* Set Type of Operation to Internal Transfer.
* In the Barcode App tab, enable Group batch lines.
* Go to Inventory → Operations → Internal Transfers and create a new transfer:
* Select the newly created Operation Type.
* Add the created Product with quantity 4.4.
* Mark the transfer as To Do.
* Create another Internal Transfer with the same configuration:
* Select the same Operation Type.
* Add the same Product with quantity 48.8.
* Mark the transfer as To Do.
* Open the Internal Transfers list view.
* Select both created transfers.
* Click Action → Add to Wave Transfer.
* Choose A new Wave Transfer and confirm.
* In the popup, select both transfers and add them to the wave.
* Open the Barcode application.
* Open the created operation and select the Batch on the right side
to open the wave transfer in the barcode interface.
**Observed behavior:**
- The grouped line quantity is displayed as 53.99999996 instead of
the expected value(53.2).
**Cause:**
- When the Barcode app loads data,` _createState()` is executed,
which calls `groupLines()`.
- Inside this method, quantities are aggregated using standard
JavaScript floating-point addition:
https://github.com/odoo/enterprise/blob/08d0a7f480046bb489ca69e7b3535e99cb20eee5/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L204-L205
- Since JavaScript stores numbers as binary floating-point values,
decimals like 4.4 and 48.8 cannot be represented exactly.
Repeated additions accumulate precision errors, producing results
like 53.99999996 instead of 53.2.
**Fix:**
- Aggregate quantities using `formatFloat` with the barcode precision
before converting them back to floats
- `formatFloat` rounds the value according to the configured precision
of the barcode model, ensuring the intermediate result is normalized
after each addition. Converting the formatted value back with
`parseFloat` guarantees the stored number respects the expected
decimal precision and prevents floating-point accumulation errors.
---
opw-5932329
Forward-Port-Of: odoo/enterprise#114998
Forward-Port-Of: odoo/enterprise#110241This update resolves a crash in the website's video embedding feature that occurred when a video source (URL) was missing. The change simplifies the video placeholder to prevent errors during loading and ensures the feature functions reliably regardless of whether a video URL is provided. This improves the overall stability and user experience for video content on our website.
Original PR description
Commit[^1] reworked the `s_video` snippet placeholder into a plain SVG, dropping the inner `<iframe>` and the `data-oe-expression` attribute that carried the video URL. The `.media_iframe_video` class was kept, so the `MediaVideo` interaction still binds to the placeholder and calls `generateVideoIframe`, which then reads `dataset.oeExpression || dataset.src` (undefined) and crashes on `.match()`. The same crash hits the `DOMContentLoaded` fallback on the frontend for any saved page that ends up with a `src-less` placeholder. To prevent the issue, we exit the interaction early if no `src` is saved and leave the existing children in place. Nothing changes if the video has a valid URL already. [^1]: https://github.com/odoo/odoo/commit/db91ddd861b13694fe0e0b8d9cce23e02f487a6a task-6158263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261184
This update fixes an issue where upgrade scripts within Odoo modules weren't properly organized, leading to potential logging and warning problems. Now, these scripts are correctly associated with the core upgrade package, ensuring cleaner operation and more reliable script execution. This improves the stability and predictability of Odoo updates.
Original PR description
The resulting modules should be bound to the `odoo.upgrade` package. Side effects: - the loggers created inside the upgrade scripts are now in the `odoo.upgrade` namespace. - warnings raised by bad usages in upgrade scripts are now correctly filtered. Forward-Port-Of: odoo/odoo#261050 Forward-Port-Of: odoo/odoo#258025