Friday, June 20, 2025
30 changes · saas-18.2
Resolved issues and error corrections
This fix prevents Point of Sale sessions from failing when product option exclusions include inactive values. The system now checks that the relevant values are loaded before using them, improving reliability when opening the POS.
Original PR description
Since this commit https://github.com/odoo/odoo/pull/213789/commits/a3b5ddd909ceb3b09acd0ebb1dde6f2561a8244e, the exclusion is computed at the launch of the pos. It was not expected to have inactive values in the exclusion causing an error. It is now fixed by checking the values loaded and we are checking the values before working with them. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Clicking a kanban progress bar now refreshes only the information it needs instead of requesting every available total. This avoids unnecessarily heavy database work and should help keep these views responsive, especially where complex related data is involved.
Original PR description
When a progress bar is clicked, its aggregates should be refreshed. However, a change introduced in https://github.com/odoo/odoo/pull/163300 inadvertently caused the webclient to request all available aggregates, leading to unnecessarily complex queries (for related field by example). This commit corrects this behavior by ensuring that only the necessary aggregates are requested when a progress bar is selected.
This change adds a small internal hook to the restaurant ticket screen so related point-of-sale extensions can customize behavior more reliably. It helps keep integrations such as delivery and localization modules working consistently without changing the visible cashier experience.
Original PR description
We added a function in the ticket screen in order to override it in the modules `pos_urban_piper` and `pos_blackbox_be`. task-id: 4781945 enterprise PR: https://github.com/odoo/enterprise/pull/87989 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale now avoids loading product attribute exclusions for products that are not available in the PoS. This prevents avoidable errors and helps keep the PoS product setup more reliable for users.
Original PR description
Before this commit, if a product template attribute exclusion existed for a product template attribute value on a product not loaded in the PoS, but that exclusion was linked to a product is loaded into the PoS, it would unnecessarily load the exclusion, leading to errors. opw-4875036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A missing required setting was added to an automated Point of Sale test so it can run successfully. This helps keep the testing process reliable and prevents build failures from blocking development work.
Original PR description
The field 'account_tax_periodicity_journal_id' is required but not set in the test. This commit adds the missing field to ensure the test runs successfully. build-error-226482
UrbanPiper receipt headers now print the delivery identifier with stronger text contrast. This helps staff and customers reliably read the delivery reference on printed POS receipts.
Original PR description
- Since `18.2` the `delivery_identifier` is not correctly rendered in the receipt header when using urban piper. - This is caused by the `text-muted` class on the element, which is causing the text to be too light to be correctly printed. task-id: 4881459
Miscellaneous changes
In this PR: - Introduced a new "Slovenian 01 (SI0125-1235-8403)" format for payment references, following Slovenia’s Model 01 standard. This format is selectable in Sales journals (Advanced Settings) and set as the default for Slovenian companies. task-4805083 Forward-Port-Of: odoo/odoo#214839 Forward-Port-Of: odoo/odoo#211608
Original PR description
In this PR: - Introduced a new "Slovenian 01 (SI0125-1235-8403)" format for payment references, following Slovenia’s Model 01 standard. This format is selectable in Sales journals (Advanced Settings) and set as the default for Slovenian companies. task-4805083 Forward-Port-Of: odoo/odoo#214839 Forward-Port-Of: odoo/odoo#211608
Currently, an error is produced when attempting to edit fields in the **Purchase Line and Vendor Bill line matching view** model. **Steps to reproduce:** - Install the `purchase` module. - Open a Vendor Bill form and click the "Purchase Matching" button. - In the list view, change the **Vendor** field of any record. - Attempt to save. **Error:** ``` UndefinedTable relation "purchase_bill_line_match" does not exist LINE 1: UPDATE "purchase_bill_line_match" ``` Here, the `purcha
Original PR description
Currently, an error is produced when attempting to edit fields in the **Purchase Line and Vendor Bill line matching view** model. **Steps to reproduce:** - Install the `purchase` module. - Open a Vendor Bill form and click the "Purchase Matching" button. - In the list view, change the **Vendor** field of any record. - Attempt to save. **Error:** ``` UndefinedTable relation "purchase_bill_line_match" does not exist LINE 1: UPDATE "purchase_bill_line_match" ``` Here, the `purchase.bill.line.match` model is defined with `_auto = False`, meaning it is a non-storable model, does not have a corresponding database table, and therefore cannot be updated directly. [1] - https://github.com/odoo/odoo/blob/5977da2c93d522ece984d2fa8a31624f4b612eca/addons/purchase/models/purchase_bill_line_match.py#L10-L12 This commit makes fields read-only in the model, avoiding unintended write attempts on a non-storable view model. Sentry-6629713332 Forward-Port-Of: odoo/odoo#212383
The field priority is not required (even if it has a default) so it is possible to have False instead of a str. Traceback occures when merging leads that contains historical data. ``` File "/home/odoo/src/odoo/saas-18.3/addons/crm/models/crm_lead.py", line 1501, in _merge_opportunity merged_data = opportunities._merge_data(self._merge_get_fields()) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/odoo/src/odoo/saas-18.3/addons/crm/models/crm_lead.
Original PR description
The field priority is not required (even if it has a default) so it is possible to have False instead of a str.
Traceback occures when merging leads that contains historical data.
```
File "/home/odoo/src/odoo/saas-18.3/addons/crm/models/crm_lead.py", line 1501, in _merge_opportunity
merged_data = opportunities._merge_data(self._merge_get_fields())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/addons/crm/models/crm_lead.py", line 1457, in _merge_data
data[field_name] = fcallable(field_name, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/addons/crm/models/crm_lead.py", line 1555, in <lambda>
'priority': lambda fname, leads: max(leads.mapped('priority')) if leads else False,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '>' not supported between instances of 'str' and 'bool'
```
Forward-Port-Of: odoo/odoo#214152opw-4865213 Caused-by: https://github.com/odoo/odoo/pull/212680 Forward-Port-Of: odoo/odoo#214988
Original PR description
opw-4865213 Caused-by: https://github.com/odoo/odoo/pull/212680 Forward-Port-Of: odoo/odoo#214988
The ``test_supplierinfo_without_uom_and_product_template`` test is failing in the single app tests on runbot nightly builds. error: ``` AssertionError: 'product_uom_id' was not found in the view ``` The issue is that the ``product_uom_id`` field is included in the view with the ``uom.group_uom`` group. However, the test case does not assign the ``uom.group_uom`` group to the user. This commit fixes tests failure caused by https://github.com/odoo/odoo/pull/213497 runbot-226816
Original PR description
The ``test_supplierinfo_without_uom_and_product_template`` test is failing in the single app tests on runbot nightly builds. error: ``` AssertionError: 'product_uom_id' was not found in the view ``` The issue is that the ``product_uom_id`` field is included in the view with the ``uom.group_uom`` group. However, the test case does not assign the ``uom.group_uom`` group to the user. This commit fixes tests failure caused by https://github.com/odoo/odoo/pull/213497 runbot-226816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214996
**Steps to reproduce:** - Install Accounting - Upload some particular PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "Arbitrary Uncaught Python Exception" Cause: When printing the original bill, we try to add a banner on the PDF. In this case, PyPDF2 fails to add a banner and raises an error from decimal library (i.e. "decimal.InvalidOperation") that is not catched. **Solution:** Bypass the addition
Original PR description
**Steps to reproduce:** - Install Accounting - Upload some particular PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "Arbitrary Uncaught Python Exception" Cause: When printing the original bill, we try to add a banner on the PDF. In this case, PyPDF2 fails to add a banner and raises an error from decimal library (i.e. "decimal.InvalidOperation") that is not catched. **Solution:** Bypass the addition of the banner in such case by handling the error. opw-4829787 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214835 Forward-Port-Of: odoo/odoo#214493
Steps to reproduce: - Install the "Website" app. - Go to the homepage. - Click on "Site > Menu Editor" in the backend navbar. - Create a submenu. - Add a "Mega Menu Item" to the menu. - Save the dialog. - Enter edit mode. - Click on the header. - Select the "sidebar" template in the options. - Open the "Mega Menu". - Bug -> the website logo is visible under the left arrow icon. The bug has appeared since commit [1], where an "inherit" value was added to the background color prope
Original PR description
Steps to reproduce: - Install the "Website" app. - Go to the homepage. - Click on "Site > Menu Editor" in the backend navbar. - Create a submenu. - Add a "Mega Menu Item" to the menu. - Save the…
Steps to reproduce: - Install the "Website" app. - Go to the homepage. - Click on "Site > Menu Editor" in the backend navbar. - Create a submenu. - Add a "Mega Menu Item" to the menu. - Save the dialog. - Enter edit mode. - Click on the header. - Select the "sidebar" template in the options. - Open the "Mega Menu". - Bug -> the website logo is visible under the left arrow icon. The bug has appeared since commit [1], where an "inherit" value was added to the background color property of the mega menu nav. The goal was to apply the header's background color to the mega menu nav, but the chosen method was incorrect. Indeed, "inherit" only takes the background color from the immediate parent, and does not search up the tree until it finds one with a defined background color. In this case, since the parent had no background color set, the value ends up as "transparent". [1]: https://github.com/odoo/odoo/commit/b975377fe688f10497b75598c0c50bd7b0758367 Forward-Port-Of: odoo/odoo#214811
Issue ----- Reports printed using the DIN5008 layout but not the paper format have a big empty vertical band. The issue was reported for Return Slips but is common to all external documents.  Steps to reproduce ----- - Go to Settings > Companies > Configure Document Layout - Set the Layout to DIN 5008 - Set Paper format to A4 (anything except DIN5008) - Download the PDF Preview -> The printed
Original PR description
Issue ----- Reports printed using the DIN5008 layout but not the paper format have a big empty vertical band. The issue was reported for Return Slips but is common to all external documents.…
Issue ----- Reports printed using the DIN5008 layout but not the paper format have a big empty vertical band. The issue was reported for Return Slips but is common to all external documents.  Steps to reproduce ----- - Go to Settings > Companies > Configure Document Layout - Set the Layout to DIN 5008 - Set Paper format to A4 (anything except DIN5008) - Download the PDF Preview -> The printed pdf has an empty vertical band to the right of the document Cause ----- 87b067a added a new `din_page_pdf` class that we apply when printing the pdf https://github.com/odoo/odoo/blob/846c9746a601f52ddb768be4e4c7bfc21d6eeb23/addons/l10n_din5008/report/din5008_report.xml#L37 This forces a specific width to the contents https://github.com/odoo/odoo/blob/846c9746a601f52ddb768be4e4c7bfc21d6eeb23/addons/l10n_din5008/static/src/scss/report_din5008.scss#L124-L127 This works with the DIN paper format because it applies adequate margins https://github.com/odoo/odoo/blob/846c9746a601f52ddb768be4e4c7bfc21d6eeb23/addons/l10n_din5008/report/din5008_report.xml#L5-L18 For regular formats, we are better off with the default dynamic behaviour. Visual comparison ----- Left is before the fix, right is after the fix.  ----- Ticket: opw-4660716 Forward-Port-Of: odoo/odoo#213992 Forward-Port-Of: odoo/odoo#211715
### Problem: This commit https://github.com/odoo/odoo/commit/3c87fdc363183c8ced5ff2952c90a6c371f73fa7 filters archived products loaded to pos session's cache. It sends\ the ids of the current loaded products to filter_local_data. This creates a bug when deleting a product. The sent deleted product id will raise a missing error in the function, and will block opening and closing the session, unless they are manually deleted from IndexedDB. The solution here is to filter both archived and delete
Original PR description
### Problem:
This commit https://github.com/odoo/odoo/commit/3c87fdc363183c8ced5ff2952c90a6c371f73fa7 filters archived products loaded to pos session's cache. It sends\ the ids of the current loaded products to filter_local_data. This creates a bug when deleting a product. The sent deleted product id will raise a missing error in the function, and will block opening and closing the session, unless they are manually deleted from IndexedDB.
The solution here is to filter both archived and deleted products.
### How to reproduce:
* Open a shop and close it (to store products in cache)
* Delete any product from the previous shop
* Open the shop again
opw-4864574
Forward-Port-Of: odoo/odoo#214829The expect assertion does not wait, and waiting one animation frame is not enough for popovers, like the toolbar, as explained in [1]. [1]: https://github.com/odoo/odoo/pull/211426/commits/54da715df84789f9a1acc0cfc91be41dcdbab140 Forward-Port-Of: odoo/odoo#214955
Original PR description
The expect assertion does not wait, and waiting one animation frame is not enough for popovers, like the toolbar, as explained in [1]. [1]: https://github.com/odoo/odoo/pull/211426/commits/54da715df84789f9a1acc0cfc91be41dcdbab140 Forward-Port-Of: odoo/odoo#214955
Problem: When a paragraph contains a `<br>` element, triple-clicking on any line does not select the entire paragraph — only the clicked line is selected. Solution: Ensure that on triple click, the selection expands to include the entire block, regardless of inline breaks like `<br>`. Steps to reproduce: - Open the Todo app. - Add a paragraph of text. - Use `Shift+Enter` to insert a line break (`<br>`). - Add text on the second line. - Triple-click on the second line. → Only the sec
Original PR description
Problem: When a paragraph contains a `<br>` element, triple-clicking on any line does not select the entire paragraph — only the clicked line is selected. Solution: Ensure that on triple click, the selection expands to include the entire block, regardless of inline breaks like `<br>`. Steps to reproduce: - Open the Todo app. - Add a paragraph of text. - Use `Shift+Enter` to insert a line break (`<br>`). - Add text on the second line. - Triple-click on the second line. → Only the second line is selected, not the full paragraph. opw-4825816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212139
Problem: On macOS, pressing Option (Alt) + Backspace does not delete the previous word as expected. Instead, only a single character is removed. Cause: The `hotkey_service` does not support registering shortcuts that use the `Alt` key, which macOS relies on for word-level deletion. This prevents native macOS editing behavior from being handled properly. Solution: Add a dedicated `keydown` listener for macOS that manually handles deletion shortcuts involving `Alt` (Option) and `Command`.
Original PR description
Problem: On macOS, pressing Option (Alt) + Backspace does not delete the previous word as expected. Instead, only a single character is removed. Cause: The `hotkey_service` does not support registering shortcuts that use the `Alt` key, which macOS relies on for word-level deletion. This prevents native macOS editing behavior from being handled properly. Solution: Add a dedicated `keydown` listener for macOS that manually handles deletion shortcuts involving `Alt` (Option) and `Command`. This restores expected word and line deletion behavior for macOS users. Steps to reproduce: - On macOS, enter a two-word line in the editor. - Press Option (Alt) + Backspace. - Only the last character is deleted, instead of the last word. opw-4781484 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213184
We used to detect new printers every two minutes, but this made it hard to setup IoT Boxes as the list didn't update fast enough. We increased the detection frequency to 20 seconds during the first hour, then back to two minutes. We also removed the disconnected printers counter logic as it made no sense: a disconnected printer will now be marked directly as "disconnected" if it is not found by cups. Task: 4852407 Forward-Port-Of: odoo/odoo#214807
Original PR description
We used to detect new printers every two minutes, but this made it hard to setup IoT Boxes as the list didn't update fast enough. We increased the detection frequency to 20 seconds during the first hour, then back to two minutes. We also removed the disconnected printers counter logic as it made no sense: a disconnected printer will now be marked directly as "disconnected" if it is not found by cups. Task: 4852407 Forward-Port-Of: odoo/odoo#214807
**PROBLEM** When using the kiosk on a company that's not the default company, the employee count displayed for all department is 0. **STEP TO REPRODUCE** 1.install the attendance module. 2.select another company. 3.go to the kiosk (attendance/Kiosk Mode). 4.identify manually. 5.notice the department count is incorrectly displayed as 0. **CAUSE** When entering the kiosk, the user is disconnected from their session, the user in this context is the public_user who have only access to t
Original PR description
**PROBLEM** When using the kiosk on a company that's not the default company, the employee count displayed for all department is 0. **STEP TO REPRODUCE** 1.install the attendance module. 2.select another company. 3.go to the kiosk (attendance/Kiosk Mode). 4.identify manually. 5.notice the department count is incorrectly displayed as 0. **CAUSE** When entering the kiosk, the user is disconnected from their session, the user in this context is the public_user who have only access to the default company. The _compute_total_employee filter employees based on the company we have access to, so any employee from the non-default company are not taken into account. **FIX** We set the allowed_company_ids to the correct company id in the request context. opw-4647574 Forward-Port-Of: odoo/odoo#213935
We introduce a new systemd service that automatically starts on boot, trying to enable a remote access using ngrok. This will fail most of the time as users don't configure a ngrok token. When one is configured, the tunnel will open. When we'll remove it, we'll stop the service and its automatic startup will fail again on next boot. task: 4848368 Forward-Port-Of: odoo/odoo#213409
Original PR description
We introduce a new systemd service that automatically starts on boot, trying to enable a remote access using ngrok. This will fail most of the time as users don't configure a ngrok token. When one is configured, the tunnel will open. When we'll remove it, we'll stop the service and its automatic startup will fail again on next boot. task: 4848368 Forward-Port-Of: odoo/odoo#213409
**Current behavior:** A write on a product's uom that is the same as the current value is blocked. **Expected behavior:** This type of trivial write should be permitted. **Steps to reproduce:** 1. Create a product with a UoM, generate some journal entries for it 2. Export the product to CSV with import-support formatting 3. Try to import that CSV -> blocked by UoM constraint **Cause of the issue:** With the removal of UoM categories, this constraint was made much tighter. *
Original PR description
**Current behavior:** A write on a product's uom that is the same as the current value is blocked. **Expected behavior:** This type of trivial write should be permitted. **Steps to reproduce:** 1. Create a product with a UoM, generate some journal entries for it 2. Export the product to CSV with import-support formatting 3. Try to import that CSV -> blocked by UoM constraint **Cause of the issue:** With the removal of UoM categories, this constraint was made much tighter. **Fix:** Don't constrain trivial writes where the new UoM is the old UoM. opw-4623279 Forward-Port-Of: odoo/odoo#211828
…nbuild **Problem:** When decreaseing the quantity of the stock move created for the component of the bom when unbuilding, it triggers an error message **Steps to reproduce:** - create a product tracked by quantity (the "component product") - in the category field select an avco category - set an on hand quantity of 1 - create another product tracked by quantity (the "final product") - create a bom for this product and select your first product as the component - create a manufactur
Original PR description
…nbuild **Problem:** When decreaseing the quantity of the stock move created for the component of the bom when unbuilding, it triggers an error message **Steps to reproduce:** - create a product…
…nbuild **Problem:** When decreaseing the quantity of the stock move created for the component of the bom when unbuilding, it triggers an error message **Steps to reproduce:** - create a product tracked by quantity (the "component product") - in the category field select an avco category - set an on hand quantity of 1 - create another product tracked by quantity (the "final product") - create a bom for this product and select your first product as the component - create a manufacture order for the final product - confirm and produce all - unbuild it and click on the "Unbuilds" smart button - select the line of the manufacture order - click on "product moves" - select the line of the component product - set the quantity to 0 **Current behavior:** an error message appears **Expected behavior:** a stock valuation layer should be created with the unit cost of the component product at the time of the manufacture order **Cause of the issue:** price_unit_map is created to make sure that when unbuilding a non standard final product, the outgoing stock valuation layer created for the final product has the same value as in the MO (the current standard_price could have changed due to POs since the MO happened for instance) https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/mrp_account/models/stock_move.py#L47-L56 when reducing the quantity of the stock move linked to the component of the unbuild an outgoing stock valuation layer is created and _get_out_svl_vals is triggered, those 2 conditions are true https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/mrp_account/models/stock_move.py#L55-L56 but the product is not the same as the one of move_finished_ids of the MO (this product is final product of the MO) so the filter result in an empty record set and [0] creates an index out of range error https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/mrp_account/models/stock_move.py#L49-L51 **Fix:** the unit_cost of the stock valuation layer for the component product created from unbuild is the same as : the unit_cost from the stock valuation layer created from the MO for the component (even if the standard_price changed inbetween). https://github.com/odoo/odoo/blob/4fd9ae6ccd96ac13475e7e5aa9805e6f529cd609/addons/stock_account/models/stock_move.py#L516-L517 https://github.com/odoo/odoo/blob/4fd9ae6ccd96ac13475e7e5aa9805e6f529cd609/addons/stock_account/models/stock_move.py#L51 So to be consistent an ajustement to the the stock move created from the unbuild should create a stock valuation layer which also has the same unit cost opw-4747920 Forward-Port-Of: odoo/odoo#211091
steps to reproduce : 1. Install l10n_it_edi_website_sale 2. run the test `test_public_user_codice_fiscale` remove the unknown key `test` from the tour build_error-223784 Forward-Port-Of: odoo/odoo#214757
Original PR description
steps to reproduce : 1. Install l10n_it_edi_website_sale 2. run the test `test_public_user_codice_fiscale` remove the unknown key `test` from the tour build_error-223784 Forward-Port-Of: odoo/odoo#214757
Before master, this bug is mostly hidden since no WebP files are used by default. However, an upcoming PR targeting master converts all website images to WebP (https://github.com/odoo/odoo/pull/168862), revealing warnings in the server logs due to `binary_to_image` crashing on WebP inputs. This patch avoids the crash by explicitly handling WebP files with `get_webp_size()`. Forward-Port-Of: odoo/odoo#214850 Forward-Port-Of: odoo/odoo#214706
Original PR description
Before master, this bug is mostly hidden since no WebP files are used by default. However, an upcoming PR targeting master converts all website images to WebP (https://github.com/odoo/odoo/pull/168862), revealing warnings in the server logs due to `binary_to_image` crashing on WebP inputs. This patch avoids the crash by explicitly handling WebP files with `get_webp_size()`. Forward-Port-Of: odoo/odoo#214850 Forward-Port-Of: odoo/odoo#214706
The taxes used in the info popup of the product list should be the taxes of the company that owns the PoS. At the moment, it uses the all the taxes defined on the product regardless of the company. Steps to reproduce: ------------------- * Create a branch for your main company * Define a tax in the main company, and one in the branch * Create a product and assign the two taxes to it * Open the PoS in the branch * Open the product info popup > Observation: Both tax are shown on the popu
Original PR description
The taxes used in the info popup of the product list should be the taxes of the company that owns the PoS. At the moment, it uses the all the taxes defined on the product regardless of the company. Steps to reproduce: ------------------- * Create a branch for your main company * Define a tax in the main company, and one in the branch * Create a product and assign the two taxes to it * Open the PoS in the branch * Open the product info popup > Observation: Both tax are shown on the popup, even the one defined in the main company. Why the fix: ------------ As it is done in `_pos_data_process` we should take the taxes of the company that owns the PoS, and if no tax is found. We should use the taxe of the parent company if there is any. If no tax is found it means no tax should be used. opw-4647704 Forward-Port-Of: odoo/odoo#214669 Forward-Port-Of: odoo/odoo#213797
Previously, when multiple form snippets were added to the same page, corresponding fields (e.g., the "Name" field) in each form were assigned the same ID. This happened because we retrieved the form fields from the `FormEditorRegistry`. For the first form snippet, field IDs are generated and assigned correctly. However, assigning IDs to the fields also updated the fields stored in the `FormEditorRegistry`. So when a second form snippet is added, the fields it receives from the registr
Original PR description
Previously, when multiple form snippets were added to the same page, corresponding fields (e.g., the "Name" field) in each form were assigned the same ID. This happened because we retrieved the form…
Previously, when multiple form snippets were added to the same page, corresponding fields (e.g., the "Name" field) in each form were assigned the same ID. This happened because we retrieved the form fields from the `FormEditorRegistry`. For the first form snippet, field IDs are generated and assigned correctly. However, assigning IDs to the fields also updated the fields stored in the `FormEditorRegistry`. So when a second form snippet is added, the fields it receives from the registry already have an ID. The ID generation logic skips fields that already have an ID, so the fields in subsequent forms never got new IDs. With this fix, we now create a shallow copy of each field before using it. This prevents the original field definitions in the `FormEditorRegistry` from being modified. As a result, fields in different forms now receive unique IDs without needing to explicitly delete the field ID to force a new one to be generated. [task-4251881](https://www.odoo.com/web#id=4251881&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#214954 Forward-Port-Of: odoo/odoo#183883
Description of the issue this PR addresses: - The video settings popup has toggle options like autoplay and loop. These need styles from the website module to look like switches. Without that module, they show as checkboxes. Current behavior before PR: - When the website module is not installed, Toggle options look like checkboxes instead of switches. Desired behavior after PR is merged: - Basic switch styles are added directly in the html_editor module. Toggles now look correct e
Original PR description
Description of the issue this PR addresses: - The video settings popup has toggle options like autoplay and loop. These need styles from the website module to look like switches. Without that module, they show as checkboxes. Current behavior before PR: - When the website module is not installed, Toggle options look like checkboxes instead of switches. Desired behavior after PR is merged: - Basic switch styles are added directly in the html_editor module. Toggles now look correct even without the website module. task-4865400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214148
As in earlier versions, add an alias to the Internal folder so that it is configured out of the box on Saas. In sign, we make sure to not try and embed an action on the Internal folder if it was already deleted before the bridge is installed. Task-4690653 Forward-Port-Of: odoo/enterprise#82949
Original PR description
As in earlier versions, add an alias to the Internal folder so that it is configured out of the box on Saas. In sign, we make sure to not try and embed an action on the Internal folder if it was already deleted before the bridge is installed. Task-4690653 Forward-Port-Of: odoo/enterprise#82949
Changes include: - Better background color alternation for each journal entry. - Journal Entry number is now shown only once, and in bold. - Moved the date into the same column as the Journal Entry number to save space. task-4844519 Forward-Port-Of: odoo/enterprise#86991
Original PR description
Changes include: - Better background color alternation for each journal entry. - Journal Entry number is now shown only once, and in bold. - Moved the date into the same column as the Journal Entry number to save space. task-4844519 Forward-Port-Of: odoo/enterprise#86991