Wednesday, December 17, 2025
34 changes · saas-18.4
Resolved issues and error corrections
This update fixes an issue where calendar events were not displayed in chronological order when no work location was assigned. Previously, events were sorted alphabetically by title, which resulted in a confusing and inaccurate month view. Now, events are correctly ordered by their start time, ensuring a clear and organized calendar display.
Original PR description
Purpose ======= Fix the events ordering in the calendar month view. Specification ============= When comparing 2 events, if none of them has a work location the events are ordered following their title, in alphabetical order. This is wrong, the events should be ordered following their start time to keep a chronological order in the month view. Task-5407656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234583
This update fixes a security vulnerability where Portal and Internal users could create private Knowledge Articles even without the necessary permissions. The change restricts article creation to users with 'create' access, improves the user interface by hiding creation buttons for unauthorized users, and includes new tests to ensure this fix is effective.
Original PR description
How to Reproduce : 1. Remove 'Create' access on the 'Knowledge Article' model for Portal and Internal users. 2. Now log in as a Portal. 3. Try to create a new private article. 4. Log in as an…
How to Reproduce : 1. Remove 'Create' access on the 'Knowledge Article' model for Portal and Internal users. 2. Now log in as a Portal. 3. Try to create a new private article. 4. Log in as an Internal user. 5. Try to create a new private article. Both Internal and Portal users can still create private articles even after 'Create access' is removed. Article creation logic in `knowledge.article` was bypassing the usual access rights because of `sudo` (mainly to add the creator as a member, since creation rights on the member model are not granted). This allowed users to create private articles even without create access. This commit introduces: 1. Model-level access check in `create`. Sudo the creation of articles only when the user has create rights. 2. UI imp to hide the '+' button in the sidebar and the `New` button in the topbar when the user doesn't have create access. 3. New test cases to verify that model-level access rights are respected when creating an article. task-4916280 Forward-Port-Of: odoo/enterprise#101804 Forward-Port-Of: odoo/enterprise#93034
This update refines the configuration of the Account EDI Proxy Client to ensure accurate participant registration across different localization settings (My Accounting and Italy). The change removes a previous restriction and ensures that unique EDI IDs are correctly managed for these specific Odoo versions, resolving a prior registration error.
Original PR description
This commit removes the `unique_active_edi_identification` constraints from the _auto_init of `account_edi_proxy_client` client user model, and adds back the constraint on `l10n_my_edi` and `l10n_it_edi` to make it apply only to those localizations. task-4852830 Forward-Port-Of: odoo/odoo#224811
This update resolves a minor issue where the websocket connection could fail during user logout. The fix ensures a new connection is established after logout, improving the reliability of the test. This change doesn't impact users and is a routine maintenance update.
Original PR description
Before this commit, the `websocket disconnects when user logs out` was sometimes failing. This test ensures that the websocket reconnects when the user logs out. When the environment is initially…
Before this commit, the `websocket disconnects when user logs out` was sometimes failing. This test ensures that the websocket reconnects when the user logs out. When the environment is initially created, a lot of places call the `bus_service@start` method. The worker starts the websocket when receiving the first event, and discard the others. However, in this case, the call to `_start` can happen before the closing handshake is completed. As a result, the websocket is still in closing mode and the handshake is aborted. Since the disconnection wasn't clean, the `reconnect` event is triggered instead of the `connect` one. This is not a big deal and shouldn't impact the test. What matters is that a new connection is established. This commit fixes the issue by checking that a reconnection is done, either via the `connect` or the `reconnect` event. fixes runbot-234056 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240247
This update ensures that orders processed through the UrbanPiper POS system are automatically marked as paid once they've been dispatched. This simplifies the accounting process and provides a clearer view of order status. The change utilizes a similar mechanism to previously handled order completion.
Original PR description
Since `pos_urban_piper` module is not in the dependency of `pos_blackbox_be`, we need to add a blank method `_fetchUrbanpiperOrderCount` that will be overriden in both module. It's the same mecanism as what's been used for `_doneOrder`. task-id: 5261892 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240281 Forward-Port-Of: odoo/odoo#239228
This update resolves an issue where the snippet modal's background color wasn't consistently displayed across browsers (Chrome, Firefox, Safari). It also corrected the text color within the modal to match the user's selected color scheme, ensuring a better experience in dark mode.
Original PR description
This commit aims to fix two issues with the snippet modal in dark mode: 1. Streamline the background color accross browsers. Chrome takes into account the classes on the iframe for the background…
This commit aims to fix two issues with the snippet modal in dark mode: 1. Streamline the background color accross browsers. Chrome takes into account the classes on the iframe for the background color but Firefox and Safari don't. 2. The text below the custom snippets is always black, regardless of the color scheme selected. These 2 issues are fixed by using the color-scheme cookie value inside the snippet modal's iframe, adding as a meta tag and a custom class. task-5095262 | Browser(s) | Before | After | |--------|--------|--------| | Firefox/Safari | <img width="1192" height="847" alt="image" src="https://github.com/user-attachments/assets/f38f4944-3379-4300-8ec7-78a73dcce7f1" /> | <img width="1174" height="828" alt="image" src="https://github.com/user-attachments/assets/06e93051-737e-4abe-b937-79ce9a4e0a33" /> | | Chrome | <img width="1171" height="828" alt="image" src="https://github.com/user-attachments/assets/c5f1fcb4-eb55-4a26-83f5-e2c3c65ad0dd" /> | <img width="1174" height="833" alt="image" src="https://github.com/user-attachments/assets/c4066e4d-876c-455c-92eb-1ab0e115500c" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227751
This update automatically marks Odoo orders as paid when they are dispatched by UrbanPiper. This prevents orders from being accidentally cancelled during POS closing, improving efficiency and reducing potential order disruptions. The update also ensures UrbanPiper orders are recorded in Odoo's blackbox for comprehensive tracking.
Original PR description
*= urban_piper, black_box_be In this commit: =============== - When UrbanPiper updates an order to `dispatched`, we now automatically mark the order as paid in Odoo. - This prevents the order from being cancelled during the POS session closing if the cashier forgot to mark it as ready. - Also, we are adding this urban piper order to the blackbox, if it was not recorded in it. Task: 5261892 Forward-Port-Of: odoo/enterprise#102280 Forward-Port-Of: odoo/enterprise#99513
A test was failing due to a timing issue with the takeaway preset. This change freezes the test's date and time to ensure the 12:20 preset slot always appears in the future, resolving the test failure. This was a missed step during the migration of the original feature.
Original PR description
Runbot Error: [#234842](https://runbot.odoo.com/odoo/runbot.build.error/234842) When running the test `test_open_register_with_preset_takeaway` in `pos_restaurant`, the test was failing if executed after 12:20. We now freeze the datetime at June 15, 2025 - 10:00 to ensure that the preset timing slot **12:20** is always in the future. This was a forgotten change during the forward-port. Forward: [odoo/239126](https://github.com/odoo/odoo/pull/239126) Task: [#5365003](https://www.odoo.com/odoo/project/1737/tasks/5365003)
This update fixes an issue where pasted content in the website builder's translation mode wasn't correctly styled, leading to visual inconsistencies and reset spans. The fix ensures translated content is properly formatted and avoids unexpected HTML structure, improving the translation experience. Additionally, the system now restricts inserted content in translate mode to a whitelist of approved elements to maintain translation integrity.
Original PR description
### [FIX] html_editor: unwrap blocks when inserting in editable span When the ancestors of the selection are not elements supposed to contain blocks when pasting, nothing was done to remove those…
### [FIX] html_editor: unwrap blocks when inserting in editable span When the ancestors of the selection are not elements supposed to contain blocks when pasting, nothing was done to remove those blocks. This could lead to `span` elements containing `p` elements for example. This commit unwraps the blocks in the pasted content if the block containing the selection is outside of the `contenteditable` element that contains the selection. It also fixes the function `makeContentsInline` that was not robust to containing some nodes structures. Steps to reproduce: - Open `example.com`, and copy "Example" from the first block - Open website builder in translate mode - Paste - Bug: The appearance is weird because the pasted title is not styled as translation - Save - Bug: The span of translation where the text was pasted has been reset #### - Open `example.com`, and copy the whole content - Open website builder - Move cursor to the bottom of the footer, with the company name - Paste - Bug: it inserted a `p` element in the `span` (non deterministic, depends on the mood of the AI) - Open website builder in translate mode - Select some text (more likely to trigger the bug if it includes a line break, for example the description in the footer) - Use the "Translate with AI" tool from the toolbar - Bug: The appearance is weird because the inserted translation is not styled as translation - Save - Bug: The span of translation where the text was changed has been reset opw-5053872 opw-5109137 opw-5136337 task-5222402 ### [FIX] website: restrict inserted content in translate mode to whitelist The translate mode of the website builder should only ever insert nodes with a tag in the `TRANSLATED_ELEMENTS` whitelist or with `o_translate_inline` class inside a translation span. Doing otherwise makes the translation span "invalid" according to the server, which discards the translation. Blocks are already unwrapped when inserting in translations (by the previous commit), but some other nodes are not in the whitelist, for example `img`. This commit adds the class `o_translate_inline` on `a` elements when inserted and unwraps nodes that are not in the whitelist and do not have that class. Steps to reproduce: - Open `example.com`, and copy the link "Learn More" - Open website builder in translate mode - Paste - Save - Bug: The span of translation where the link was pasted has been reset #### - Copy an image (or a piece of html containing an image) - Open website builder in translate mode - Paste - Save - Bug: The span of translation where the image was pasted has been reset opw-5053872 opw-5109137 opw-5136337 task-5222402
This update corrects a bug where the website demo tour was failing when the system used demo data. The issue stemmed from a product not being consistently displayed on the initial shop page. This ensures the demo tour functions correctly for all users, providing a seamless experience.
Original PR description
### Issue: The tour introduced in #237117 is failing when demo data is available. This is due to `product_with_alternative` not being in the first page in shop when demo data is available. runbot-234699
This update corrects an issue where invoice dates were incorrectly rolled back to the previous day due to timezone differences in Chilean tests. The fix ensures invoices are posted with accurate dates, preventing potential accounting discrepancies. This improves the reliability of our Chilean accounting module.
Original PR description
**Issue:** ```python File "/data/build/enterprise/l10n_cl_edi/models/account_move.py", line 744, in _l10n_cl_edi_post_validation raise UserError( odoo.exceptions.UserError: The stamp date and time…
**Issue:**
```python
File "/data/build/enterprise/l10n_cl_edi/models/account_move.py", line 744, in _l10n_cl_edi_post_validation
raise UserError(
odoo.exceptions.UserError: The stamp date and time cannot be prior to the invoice issue date and time. TIP: check in your user preferences if the timezone is "America/Santiago"
```
**Cause:**
Posting an invoice at early local hours (e.g., 2025-12-11 04:00) is converted by the [Chilean timezone (America/Santiago)](https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/l10n_cl_edi/models/l10n_cl_edi_util.py#L117-L120) to the previous day (e.g., 2025-12-10 19:30).
**Solution:**
- Freeze the test time at a stable CL-safe hour
- Add a fixed `invoice_date` aligned with the frozen timestamp
Reference : [timezone converter](https://dateful.com/time-zone-converter?t=730pm&d=2025-12-10&tz2=Santiago-Chile)
Runbot error: [234755](https://runbot.odoo.com/odoo/runbot.build.error/234755)
Related PR: https://github.com/odoo/enterprise/pull/99518
Forward-Port-Of: odoo/enterprise#102127
Forward-Port-Of: odoo/enterprise#101901This update fixes an issue where attempting to refund orders that included archived products would cause a blank page error. The fix ensures that the system correctly identifies and processes product information, allowing refunds to be processed even after a product has been archived. This improves the reliability of the point-of-sale system.
Original PR description
Step to reproduce: - start pos and finalize a order with product A - go backend - Archive product A - start the pos again - try to refund the order Observation: - Blank page with traceback in console…
Step to reproduce: - start pos and finalize a order with product A - go backend - Archive product A - start the pos again - try to refund the order Observation: - Blank page with traceback in console ``` Caused by: TypeError: Cannot read properties of undefined (reading 'filter') at __exports.getOrderChanges at Proxy.getOrderChanges ``` Cause: - until now `product.template` model is looked for filter after a reload https://github.com/odoo/odoo/blob/1b2500422209ed5feb6d49716f94d58c931bf541/addons/point_of_sale/static/src/app/models/data_service_options.js#L91-L93 https://github.com/odoo/odoo/blob/1b2500422209ed5feb6d49716f94d58c931bf541/addons/point_of_sale/static/src/app/services/data_service.js#L290-L295 and not `product.product`, this makes `product_id` available but `product_tmpl_id` undefined, causing inconsistency Fix: - we add `product.product` in `cleanupModels` for data to in sync with backend opw-5237961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238514
This update prevents Odoo deployments from failing when the optional ‘payment_stripe’ module isn’t installed. Previously, optimized deployments would crash. Now, if the module is missing, the system gracefully handles the situation, ensuring a smoother startup process.
Original PR description
Description of the issue/feature this PR addresses: The `payment` module does not declare a dependency on the `payment_stripe` module but the code implicitly depends on it. This makes a problem in optimized deployments where the `payment_stripe` module is not included. Current behavior before PR: Optimized Odoo deployments without `payment_stripe` fail to start because of a `ModuleNotFoundError`. Desired behavior after PR is merged: If the module is not available, the import error is silently ignored and the `is_stripe_supported_country` calculation returns `False`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240131 Forward-Port-Of: odoo/odoo#239562
This update resolves a formatting issue in invoices generated when using quotation templates in sales orders. Previously, the name and description were combined on a single line in the PDF. This fix ensures that the description is correctly displayed on a separate line, improving invoice clarity and consistency.
Original PR description
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale…
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale and invoicing installed 2- Create a quotation template, and add a description in the line. 3- Create a quotation with the created template. 4- Confirm the order and create an invoice for the sale order. 5- Print the pdf, as seen the name and description are shown in the same line, while if the sale order was created without a template, we would have seen the description from product in the next line. `_get_journal_items_full_name` is used to enforce the product name in the description. However, in cases where product name doesn't exist in the description, e.g. our case here, the name and description will be shown in the same line in the invoice pdf. This can be fixed by adding a new line between the name and the description. read: #235122 opw-5130171 Forward-Port-Of: odoo/odoo#240177 Forward-Port-Of: odoo/odoo#237110
This update corrects a formatting problem in invoices generated when using quotation templates in sales orders. Previously, the invoice PDF displayed product names and descriptions on the same line, leading to an unorganized appearance. This fix ensures descriptions are correctly separated from product names in the invoice, improving readability and professionalism.
Original PR description
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale…
### Issue: In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf. #### Steps to reproduce: 1- Install a db with sale and invoicing installed 2- Create a quotation template, and add a description in the line. 3- Create a quotation with the created template. 4- Confirm the order and create an invoice for the sale order. 5- Print the pdf, as seen the name and description are shown in the same line, while if the sale order was created without a template, we would have seen the description from product in the next line. `_get_journal_items_full_name` is used to enforce the product name in the description. However, in cases where product name doesn't exist in the description, e.g. our case here, the name and description will be shown in the same line in the invoice pdf. This can be fixed by adding a new line between the name and the description. opw-5130171 Forward-Port-Of: odoo/enterprise#102208 Forward-Port-Of: odoo/enterprise#100417
This update fixes an error in how BoM kits with nested components were valued, preventing overvaluation due to incorrect cost sharing calculations. It ensures accurate inventory valuation by correctly applying cost shares at each level of the BoM hierarchy. This requires AVCO (Average Cost) to be enabled.
Original PR description
### [FIX] purchase_mrp, mrp: correct BoM Kit valuation with nested kits #### Issue: When purchasing a BoM Kit (50/50) containing others BoM Kits (50/50), cost share was applied at each level (50%…
### [FIX] purchase_mrp, mrp: correct BoM Kit valuation with nested kits
#### Issue:
When purchasing a BoM Kit (50/50) containing others BoM Kits (50/50), cost share was applied at each level (50% instead of 25%), leading to overvaluation (e.g., 200% total instead of 100%)
#### Cause:
`cost_share` was always applied fully during BoM explosion and as a portion of the full price on `_get_unit_price()`
#### Other bug fixed:
Fix `_get_cost_share()` to correctly return 0 when BoM total cost_share already equals 100%
#### Requirement:
AVCO (Average Cost) must be enabled on all components/BoMs
#### Steps to reproduce:
1. Recreate that hierarchy with AVCO Products
- A kit "Testing Kit Complete" containing:
-- "Component01", cost share 50%
-- A kit "Testing Kit 1", cost share 50%:
--- "Component02", cost share 50%
--- "Component03", cost share 50%
2. Create and validate a Purchase Order for "Testing Kit Complete" (unit price: 1000)
3. Receive the products
4. Go in Inventory > Reporting > Valuation and search for Component
5. All 3 components are set to 500, instead of Component01: 500 / Component02: 250/ Component03: 250
opw-4806023
### [FIX] purchase_mrp: correct BoM valuation with product variants or optional lines
#### Issue:
BoM valuation ignores variant-specific lines and does not skip lines with quantity 0
#### Cause:
The code only checks that the BoM adds up to 100%
But this can cause issues with variants that do not include all products or with optional lines
As a result, the total valuation may be incorrect
#### Steps to reproduce:
1. Recreate a kit hierarchy with AVCO products:
- Kit "Variant Kit" (Variant Color: White and Wood) containing:
-- "Component01", cost share 0%, only for variant White
-- "Component02", cost share 0%
2. Create and confirm a Purchase Order for "Variant Kit" (variant: Wood, unit price: 1000)
3. Receive the products
4. Go to Inventory > Reporting > Valuation and search for the components
5. Only Component02 appears with 500$, so only half of the total value is shown
opw-4806023
opw-5085457
Forward-Port-Of: odoo/odoo#218326This update corrects a bug where a procurement group wasn't consistently linked to deliveries when multiple moves were added to a picking. The fix ensures that a procurement group is always created and associated with the delivery, streamlining the process of managing stock transfers related to sales orders. This improves the accuracy of inventory tracking.
Original PR description
### Steps to reproduce: - Create a picking with a move for any product #### Issue 1: > A procurement group is created and linked to the transfer - Add a second move on the picking and save #### Issue 2: > The procurement group of the picking is lost ### Cause of the issue: The `_set_sale_id` set method creates a procurment group and links it to the picking no matter if the `sale_id` is set or not. https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/sale_stock/models/stock.py#L90-L93 https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/sale_stock/models/stock.py#L100-L113 opw-5386424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239697
This update resolves an issue where large product images on the Shop page were being blurred due to how they were sized. The fix adds a class to the images that ensures they maintain their original aspect ratio, preventing distortion and improving the visual presentation of products. This ensures a consistent and professional look for our online store.
Original PR description
Steps to reproduce: =================== 1- Add a product with a very large image width & publish product. 2. Go to the Shop page & type product name. -> The product image is blurred. Cause: ====== The product images have `h-100 w-100` classes which force them to fill the container dimensions exactly, ignoring their intrinsic aspect ratio. Solution: ========= Add the `object-fit-contain` class to the image. This ensures the image scales to fit within the container while preserving its aspect ratio. Side note: `object-fit-contain` class will be added only in version 17.0 In the next versions the class already exists. opw-5258658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239506 Forward-Port-Of: odoo/odoo#238108
This update ensures that rental orders created from leads automatically include the tags associated with the original lead. Previously, rental orders lacked this functionality due to a minor difference in how tags were passed during order creation. This change improves data consistency and reporting for rental agreements.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a lead with tags; 2. convert lead to rental order. Issue ----- The new rental order has no tags. Cause ----- Tags are added to regular sales orders via the `_prepare_opportunity_quotation_context` method, but rental orders use `_get_action_rental_context` instead, which is virtually identical, but adds the `in_rental_app` context value, and doesn't include `default_tag_ids`. Solution -------- Rather than having duplicate code, make `_get_action_rental_context` retrieve the base context from `_prepare_opportunity_quotation_context`, then adding `in_rental_app=True`. opw-4549941 Forward-Port-Of: odoo/enterprise#102220
This update resolves an issue where copying and pasting empty list items in the HTML editor would prevent the backspace key from working. The fix automatically inserts a line break (<br>) into the pasted item, ensuring proper backspace functionality and editing.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a new paragraph, type some text. - Create a numbered list below paragraph, type some text. - Keep the cursor at the start of list text and select the above text - Copy the selection and paste in a new paragraph. - Backspace in pasted list is not working. This happens because pasted list item is empty. **Desired behavior after PR is merged:** Now, copied empty list item is filled with `<br>`, as result backspace works properly. task-5226511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234869
This update prevents HR users from receiving unnecessary reminder emails. The fix filters out time-off and holiday entries when sending reminders, ensuring that notifications are only sent for actual timesheet requests requiring user input. This improves efficiency and reduces email clutter for our users.
Original PR description
**Steps to reproduce:** - Install timesheet_grid_holidays - Create a user with no timesheet access - Create a leave and approve it as a manager - Set up employee reminders in timesheet settings - Run the timesheet reminder scheduled action **Issue:** HR users without timesheet app access or who haven’t submitted timesheets in the past 3 months were still receiving reminder emails. **Cause:** When a time-off is approved or a public holiday is recorded, it generates timesheet entries, which causes reminder emails to be sent incorrectly. **Fix:** Filter out time-off and public holiday entries when sending reminders. Now, reminders are only sent for actual timesheets that require user input. task-5085790 Forward-Port-Of: odoo/enterprise#102061 Forward-Port-Of: odoo/enterprise#95450
This update fixes an issue where expense report column widths weren't calculating correctly. The change ensures that the correct table width is used, resulting in properly sized columns for better readability and usability. This improves the overall user experience when viewing expense reports.
Original PR description
Before this commit, some classnames set on the list renderer were lost in the expense override. As a consequence, the column width logic couldn't be applied correctly. The widths were computed with a wrong available width (the width of table's parent element, which is the renderer itself). Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240270
This update resolves an issue where background images were stored as base64 data, negatively impacting website loading speed. The fix now uses the original image source, and a new process automatically corrects existing database entries. This improves website performance and user experience.
Original PR description
Since saas-18.4, body background images are saved as base64 in `body-image` instead of an URL. This affects the performance of the website. To reproduce: - Install Website - Open the website builder - go on the theme tab - website > background > choose an image - In the CSS file or in the style tab of the dev tools > `body-image` value is a base64 image To fix: Instead of directly giving the image source as the `body-image` value, we should give the `originalSrc` of the image element. To retro fix databases that would maybe have base64 backgrounds, a `normalizeBodyBackgroundImage` have been added to replace them with the correct URL. This function activates when the user opens the website builder.
This update resolves an issue that previously caused errors when processing invoices with reverse charge accounting (BIS3) in Japan. The fix ensures invoices are correctly generated and transmitted, improving the reliability of financial reporting. This change primarily impacts users relying on BIS3 invoice formats for international transactions.
Original PR description
opw-5419227 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240275
This update addresses a bug in the spreadsheet component, specifically preventing issues with empty matrices during evaluation. Multiple developers collaborated on this fix, ensuring stability and performance of the spreadsheet functionality within the Odoo 18.4 release. This change improves the overall reliability of spreadsheet operations.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/71918cc879 [REL] 18.4.21 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/95b83c449f [FIX] evaluation: do not spread empty matrix [Task: 5421196](https://www.odoo.com/odoo/2328/tasks/5421196) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves a bug preventing users from adding products to invoices when navigating from an FSM task. The issue stemmed from differing context settings – specifically, the 'out_invoice' parameter – used when accessing invoices from a sale order versus a task. This change ensures consistent domain logic for product selection, allowing users to correctly add products to invoices regardless of the initial navigation path.
Original PR description
On a fsm task, using the smart button to go to the invoice, will not give the same domain for the products, if you go from the sale order or directly from the task Steps to reproduce:…
On a fsm task, using the smart button to go to the invoice, will not give the same domain for the products, if you go from the sale order or directly from the task Steps to reproduce: ------------------- * Create a product - Purchase: False - Sale : True * Create a fsm task * Add products * Go to the sale order * Create the invoice (regular invoice) * Go back to the task * Go to the invoice using the invoices smart button * Try to add your product -> issue it's not possible. Observation: --------------- The domain of the search is not the same if we go from the sale order or from the task. This is because the domain depend on the context and the context is not the same : [Domain](https://github.com/odoo/odoo/blob/8258ddf12ed6c0495628f7a480d1e2424e756540/addons/account/views/account_move_views.xml#L1134-L1141) When using the smart button on the SO, some elements will be added to the context, the important one is: default_move_type : "out_invoice": [SO context](https://github.com/odoo/odoo/blob/18.0/addons/sale/models/sale_order.py#L1453) Instead when using it on the task, the context does not have that element: https://github.com/odoo/enterprise/blob/cb79d565031ee0e1bec9db82aa35deb2e1c03576/industry_fsm_sale/models/project_task.py#L325-L327 This will be calculate here in the js files: [evalContext](https://github.com/odoo/odoo/blob/c3367bd7c6900e42394b006ccf48c3b36a1b87e9/addons/web/static/src/views/fields/field.js#L400) opw-5135567 Forward-Port-Of: odoo/enterprise#101938 Forward-Port-Of: odoo/enterprise#98612
This update fixes an issue where invoice reports for KE companies were not displaying prices with commas. The fix removes a duplicate XPath and correctly formats the total and taxable amounts, ensuring accurate financial reporting. This improves clarity and compliance for KE-related invoices.
Original PR description
Steps to reproduce: 1. install `l10n_ke` 2. Switch to KE Company 3. Create a product with all KRA eTIMS details set on the Accounting page. 4. Create an invoice to KE Company with that product and set unitprice > 10000 5. Confirm the invoice and send it. Now, see the invoice report Issue: 1. xpath for `td_subtotal` was duplicated 2. The total amount and taxable amount were not formatted as prices (no commas). Before: <img width="771" height="397" alt="image" src="https://github.com/user-attachments/assets/492fe911-18d6-4e01-a16d-d7450c17373f" /> After: <img width="766" height="389" alt="image" src="https://github.com/user-attachments/assets/bbe5d4e2-b337-445c-833a-06492a8c827d" /> Solution: Updated the invoice report to: - Remove the duplicated `td_subtotal` xpath. - Properly format the total and taxable amounts with `t-options`. opw-5341578 Forward-Port-Of: odoo/enterprise#101794 Forward-Port-Of: odoo/enterprise#100279
This update fixes a test failure in the Point of Sale module caused by inconsistencies in date handling between online and offline modes. The fix ensures the test accurately reflects how the system functions when not connected to the internet, preventing future errors related to year-specific checks.
Original PR description
**Why the fix:** The date was frozen in the backend but it did not work in the case where we are offline. This happens because when offline we get the date in the frontend by creating a *new Date()*, which is not affected by either the backend or the frontend freezeDate. This means that when the year changes, this test would fail, as we check that the year is 2025 by hardcoding it. To avoid this, we now use the pos_reference value to build this part back together. runbot-233565 Forward-Port-Of: odoo/odoo#240044 Forward-Port-Of: odoo/odoo#238113
This update resolves an issue impacting Swiss payroll calculations, specifically related to overtime payments (ST-Overtime) and the LPP (Lohn- und Premodifizierungs-Pauschale) tax calculation. The fix ensures accurate and compliant payroll processing for Swiss businesses using the l10n_ch_hr_payroll module.
Original PR description
Forward-Port-Of: odoo/enterprise#102161
This update fixes an issue where pressing Enter multiple times before a star rating incorrectly duplicated elements in the previous paragraph. It also resolves a problem with line breaks next to non-editable elements, ensuring line breaks now function correctly. This improves the overall user experience and stability of the HTML editor.
Original PR description
**Current behavior before PR:** - When pressing Enter twice before a star rating (3-star or 5-star), the previous paragraph incorrectly ended up containing a single star. - When performing a line break next to a contenteditable false element, `deepEditableSelection` returned a selection whose anchor was inside that non-editable element. Since the selection was inside a contenteditable false element, the `insertLineBreakElement` method returned early without doing anything. **Desired behavior after PR is merged:** - Pressing Enter before the star rating no longer duplicates a star in the previous paragraph. - When `deepEditableSelection` returns a selection whose anchor lies inside a contenteditable false element, we now use an editable selection instead. This prevents the anchor from ending up inside a non-editable element and allows the line break to work correctly. task-5079270 Forward-Port-Of: odoo/odoo#238925 Forward-Port-Of: odoo/odoo#226433
This update fixes an issue where newly added buttons in the Odoo form editor weren't correctly focused or displayed in the sidebar. The fix ensures the editor's properties are immediately visible after creating a new button, streamlining the design process.
Original PR description
Have an arch with many conditional button in the header Click on Add a button in the form editor. Before this commit, the new button was not correctly focused and the sidebar did not display the properties of the new button. This was because we gave the wrong xpath coordinates to focus to the editor. After this commit, this flow works as expected task-5364798 Forward-Port-Of: odoo/enterprise#101059
This update fixes an issue where currency rates for companies outside of UYU were incorrectly dated, leading to inaccurate tax calculations. The change ensures all currency rates are now synchronized with today's date, improving the accuracy of financial reporting for companies using currencies other than UYU.
Original PR description
When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to…
When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to properly do the conversions. ### Steps 1. Create a new Company with country Uruguay 2. Change current logged company to new Company 3. Change the currency to USD 4. Go to Settings, option Automatic Currency rate and configure provider yo [UY] Uruguayan Central Bank 5. Click manual synchronization 6. Check rates ### Current behavior before PR All currencies except UYU currency has created taxes with date today. Only one error in UYU currency that is created with yesterday rate  ### Desired behavior after PR is merged: All the currencies are created with the same date, the correct day that is today rate. References: LATAM 1341 / ADHOC Task 51716 Forward-Port-Of: odoo/enterprise#85065
This update corrects a previous issue where users could select any time off type when creating group allocations. Now, the system only allows selection of time off types that require an allocation, mirroring the process when creating a single allocation. This ensures data consistency and prevents incorrect allocation configurations.
Original PR description
To reproduce: ============= - Create time off tyoe that does not require allocation - Go to timeoff > Allocation > Group allocation -> you can select the created time off type Problem: ======== we didn't have a domain on `holiday_status_id` field, so all time off types were available for selection. Solution: ========= Add a domain on `holiday_status_id` field to only show time off types that require allocations the same way as when creating a single allocation. opw-5113959 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238008 Forward-Port-Of: odoo/odoo#228617
This update resolves an issue where videos added to product descriptions in the e-commerce section would disappear after saving. The fix prevents the system from automatically clearing these descriptions based on a misinterpretation of the video's HTML structure. This ensures videos are consistently displayed for customers.
Original PR description
Versions
--------
- 18.0+
Steps
-----
1. Open website editor on a product page;
2. edit the ecommerce description;
3. add a video using the `/video` command;
4. save & close editor.
Issue
-----
The video disappears.
Cause
-----
The `write` override in `website_sale` uses the `is_html_empty` method to clear "empty" descriptions. When adding a video, it gets added as a `<div data-oe-expression="URL" class="media_iframe_video"></div>` element, i.e. an "empty" `div` element according to `is_html_empty`, hence getting cleared on write.
Solution
--------
In the `write` override, don't clear the ecommerce description if it contains "media_iframe_video".
Also, for 18.0, add `options="{'embedded_components': false}"` to the product view in the back-end to disable adding video there, as it gets formatted in a way that isn't supported by the front-end. For 18.2, this was already done in 6339f261e7161.
opw-5218018
Forward-Port-Of: odoo/odoo#240080