Daily updates from Odoo
Wednesday, December 17, 2025
94 changes
34 changes
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#24008015 changes
Resolved issues and error corrections
This update resolves a minor issue where the websocket connection could unexpectedly drop during user logout tests. The fix ensures a reliable reconnection process, guaranteeing that the test consistently establishes a new connection after a logout. This improves the stability and predictability of our testing procedures.
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 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 restores a necessary constraint, preventing duplicate registrations and improving system stability.
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 an issue where the snippet modal's background color wasn't consistently displayed across browsers (Chrome, Firefox, Safari). It also ensures that text within the snippet modal respects the user's chosen color scheme, providing a better and more reliable dark mode experience. This improves usability for all users.
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 corrects a bug where a procurement group wasn't consistently linked to deliveries when multiple moves were added to a picking. The change ensures that a procurement group is always created and linked, regardless of whether a sale order is associated, improving the accuracy of inventory tracking and order fulfillment. This resolves an issue impacting order processing efficiency.
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 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 timesheets requiring user input. This improves efficiency and reduces email clutter.
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#101984 Forward-Port-Of: odoo/enterprise#95450
A test was failing due to inconsistencies in date handling between online and offline POS systems. This fix ensures the test accurately reflects how the system behaves when not connected to the internet, preventing future disruptions. The change uses a reliable data source to build the date, ensuring consistent test results.
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#238113
This update ensures that orders processed through the UrbanPiper POS system are automatically marked as paid once they are dispatched. This change addresses a dependency issue and utilizes a similar process to previously handled order statuses. It improves the accuracy of order tracking and streamlines the payment process for UrbanPiper transactions.
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#239228
This update resolves an issue where invoices posted at early times in the Chilean timezone were incorrectly interpreted as being in the previous day, leading to errors. The fix ensures invoice dates are handled correctly, preventing this problem and improving invoice processing reliability.
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 resolves an issue impacting Swiss payroll calculations, specifically related to overtime payments (ST-Overtime) and the LPP (Lohnsteuer-Pauschbetrag) tax deduction. The fix ensures accurate tax and payroll reporting for Swiss businesses using the Odoo Enterprise module.
Original PR description
Forward-Port-Of: odoo/enterprise#102161
This update fixes an issue where optimized Odoo deployments failed to start if the `payment_stripe` module wasn't present. The change silently handles missing dependencies, ensuring Odoo starts correctly even without the Stripe payment module. This improves the overall stability and reliability of Odoo deployments.
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 corrects a formatting problem in invoices generated when using quotation templates in sales orders. Previously, the name and description were combined on the invoice PDF. This fix ensures that descriptions are correctly separated with a new line, improving invoice clarity and consistency for users.
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, creating an unreadable format. This fix ensures descriptions appear on separate lines, improving invoice clarity 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 resolves an issue where large product images on the Shop page were being blurred due to how they were being sized. The fix ensures product images maintain their original aspect ratio, displaying correctly regardless of their size. This improves the visual presentation of products for customers.
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 context information was passed. This change streamlines the process of tagging rental agreements, improving organization and reporting.
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 within the HTML editor would prevent the backspace key from working. The fix now automatically inserts a line break (<br>) into the pasted item, ensuring proper backspace functionality and preventing editing problems.
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
4 changes
Resolved issues and error corrections
This update resolves an issue where invoices posted at early times in the Chilean timezone were incorrectly interpreted as being in the previous day. The fix ensures that invoice dates are handled correctly during testing, preventing errors and maintaining accurate record-keeping. This improves the reliability of the 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 resolves an issue impacting Swiss payroll calculations, specifically related to overtime payments (ST-Overtime) and the LPP (Lohnsteuer-Pauschbetrag) tax deduction. The fix ensures accurate reporting and compliance with Swiss tax regulations, improving the reliability of payroll processing for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#102161
This update fixes an issue where rental orders created from leads didn't automatically inherit tags. The change ensures that tags from the original lead are correctly applied to the rental order, streamlining the process of tracking rental agreements. This improves data consistency and reporting.
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 a bug where currency conversion rates for non-UYU currencies were incorrectly dated, leading to inaccurate tax calculations. The fix ensures all currency rates are created 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
14 changes
Resolved issues and error corrections
This update resolves errors that occurred when duplicating folders within Odoo, specifically preventing crashes and incorrect folder placement. The system now correctly handles folder duplication, though attempts to duplicate the 'Company' root folder into 'My Drive' are now blocked with a warning.
Original PR description
**Before this PR:** - Duplicating a folder into itself caused a traceback. - Duplicating a folder into one of its sub-folders also caused a traceback. - Duplicating the 'Company' root folder into 'My Drive' incorrectly created the copy inside the 'Company' folder instead. **Technical reason:** - A record was being created before the copy operation, which led to infinite recursion. - The owner was incorrectly set as the parent folder, causing the duplicated folder to appear in 'Company' folder. **After this PR:** - Duplicating a folder into itself or any of its sub-folders now works correctly. - Attempting to duplicate the Company root folder into My Drive will no longer work and will instead display a warning. Task-5149773 Forward-Port-Of: odoo/enterprise#98777
This update fixes an issue where product tooltips incorrectly displayed period information related to subscription pricing and showed both recurring and sales prices on product cards. Now, tooltips accurately reflect the beginning or end of the period based on the invoice policy, and product cards only show the correct recurring price for subscription products.
Original PR description
Version - 18.0 Steps to Reproduce: Issue 1: Incorrect tooltip text 1. Go to Products → Products in subscription app. 2. Open a product page and select goods product type 3. observe product_tooltip…
Version
- 18.0
Steps to Reproduce:
Issue 1: Incorrect tooltip text
1. Go to Products → Products in subscription app.
2. Open a product page and select goods product type
3. observe product_tooltip show incorrect wording:
* "Based on order" showed end of the period.
* "Based on delivered" showed beginning of the period.
Issue 2: Product card shows both recurring and sales price
1. Go to Products → Products in subscription app.
2. Observe that the product card displays both recurring price and sales price
After this PR:
- Tooltip now correctly states:
* for "based on order" invoice_policy -> beginning of period
* for "based on delivery" invoice_policy -> end of period
- Product cards show only the recurring price when applicable.
task-5156390
<img width="1002" height="436" alt="image" src="https://github.com/user-attachments/assets/39f00555-e37a-44a5-8786-d7f8d6882de7" />
<img width="968" height="262" alt="image" src="https://github.com/user-attachments/assets/0d6d5c2d-d5ab-4376-bc03-dba243abce8b" />
Forward-Port-Of: odoo/enterprise#102147
Forward-Port-Of: odoo/enterprise#95010This update resolves an issue where clicking 'Send' in a Sign Request wizard incorrectly redirected users to the signing interface when the sender was also a signer. The fix ensures that clicking 'Send' now correctly closes the wizard, streamlining the signing process for all users.
Original PR description
When creating a Sign Request where the sender is also one of the signers, clicking Send in the wizard incorrectly redirected to the document preview/signing interface. This fix ensures that clicking Send always closes the wizard and does not trigger any redirect, regardless of the sender’s signer status. task-5408155 Forward-Port-Of: odoo/enterprise#101816
This update resolves an issue where requests to the IoT box for customer display functionality were failing due to incorrect data formatting. The PR corrects this formatting, ensuring the IoT box receives the necessary information to display customer data properly. This improves the reliability of the customer display feature.
Original PR description
Currently the requests sent to the iot box to use customer display cause and error because of the bad format of the data in the request. This PR formats the data correctly to be sent to the iot box The compatibility for webrtc for the iot boxes in 19.1 isn't necessary as webrtc was removed in 19.1 task-5408081 Forward-Port-Of: odoo/enterprise#101821
This update resolves a technical issue preventing PoS sessions linked to Fiskaly from closing correctly when cash in/out entries had reason names exceeding 40 characters. The change ensures all reason names are truncated to meet Fiskaly's requirements, preventing errors and maintaining proper integration with this payment processing system. This improves the reliability of our German Point of Sale functionality.
Original PR description
Before this change, closing a PoS session linked to Fiskaly would fail if a cash in/out entry had a reason exceeding 40 characters. Fiskaly returned: "body/cash_statement/business_cases/2/name must NOT have more than 40 characters". This commit ensures reason names are truncated to comply with Fiskaly's schema. opw-5208191 Forward-Port-Of: odoo/enterprise#98853
This update resolves an issue that occurred when users attempted to duplicate transactions through the account module. Specifically, the system would throw an error if no journal was associated with the duplication process. The fix ensures a valid command is used when a journal is missing, preventing the error and improving stability.
Original PR description
Currently, an error occurs when user opens the `account.duplicate.transaction.wizard.form` view and saves it. **Steps to Reproduce:** - Install the `account_accountant` module. - Using `Open View`,…
Currently, an error occurs when user opens the `account.duplicate.transaction.wizard.form` view and saves it. **Steps to Reproduce:** - Install the `account_accountant` module. - Using `Open View`, open the `account.duplicate.transaction.wizard` view > enter the start date, and save.. `ValueError: Compute method failed to assign account.duplicate.transaction.wizard(22,).provider_duplicate_ids` The error occurs because when the view is opened and saved, the _compute_provider_duplicate_ids method is triggered. Since no journal is linked to the wizard, the method assigns an empty list ([]) to provider_duplicate_ids [1]. Because this is a O2M field, assigning a raw empty list is invalid and causes the error. This commit ensures that when journal is missing, instead of assigning an empty list ([]), a valid relational command `([Command.set([])])` is used. Ref: https://github.com/odoo/enterprise/pull/97196/commits/c109e0bcce20f14b6dbd3d28e61b135f1fd048f2 [1] https://github.com/odoo/enterprise/blob/d808ad3f6ff52632e00cf1a68de0e5270e52895d/account_online_synchronization/wizard/account_journal_duplicate_transactions.py#L53 sentry-7080686084 Forward-Port-Of: odoo/enterprise#101177
A recent test failure related to task scheduling time zones has been corrected. The fix ensures that task planning uses UTC time, preventing inaccurate date calculations and ensuring consistent scheduling across different time zones. This resolves a potential issue impacting task planning accuracy.
Original PR description
The test `test_plan_task_in_calendar` failed with a one-hour difference in `planned_date_begin`. The error occurred because the work intervals were computed using the resource's timezone (`Europe/Brussels`) instead of `UTC`, leading to a shifted planned date. Setting the resource timezone to `UTC` ensures consistent interval computation and resolves the test failure. [RB-227059](https://runbot.odoo.com/odoo/error/227059) Forward-Port-Of: odoo/enterprise#100580
This update resolves an issue where attachments for account reports weren't being generated or added correctly. The fix standardizes how attachments are handled across different report types and ensures consistent functionality, improving the reliability of report generation.
Original PR description
[FIX] account_reports: returns: fix generations of files as attachments _generate_submission_attachments does not exist anymore ; it's been renamed to _generate_locking_attachments. Because of that,…
[FIX] account_reports: returns: fix generations of files as attachments _generate_submission_attachments does not exist anymore ; it's been renamed to _generate_locking_attachments. Because of that, some intended overrides were not executed properly, and several XML/CSV export files were not generated and added as attachments to the return. Moreover, the functions generating export files used to be called by account.report's export_file function (from a button defined in options['buttons']). export_file always forced the 'export_mode' key into the options it passed tp those file generators; we reintroduce this behavior for consistency, to avoid messy situations due to forward-port or functions being converted from the former paradigm to the new one. Note, however, it's always better to fully regenerate the options from such a generator. ================================================================================= [FIX] account_reports: returns: homogenize the reset behavior Before this fix, resetting a tax report deleted all the attachments of the return, while resetting for example the Partner VAT Listing (in Belgium), left them untouched. We now introduce a common helper for all reset functions, defining the behaviors they should share. Forward-Port-Of: odoo/enterprise#101673
This update fixes an issue where the Quality Control module's list view was incorrectly loading data. The system has been reverted to using the correct view definition, ensuring accurate display of control points when accessing the Quality Control section. This ensures the Quality Control functionality operates as intended.
Original PR description
Since odoo/enterprise#94012, when loading the quality.point list view from the main menu, `quality_point_routing_view_tree` is used instead of `quality_point_view_tree`. This is not correct. To reproduce : - Install quality_control and mrp_workorder - In Quality Module, go to Quality Control / Control Points [opw-5253899](https://www.odoo.com/odoo/project/966/tasks/5253899) Forward-Port-Of: odoo/enterprise#101098
This update corrects a bug in the Belgian payroll module that prevented a minimum wage warning from appearing when an employee record lacked a job assignment. The fix removes a redundant condition within the payroll calculation, ensuring the warning is displayed correctly for all employee types. This ensures accurate payroll reporting for Belgian companies.
Original PR description
Steps to reproduce: - Open an employee on the Employees app for a Belgian company - On the payroll tab, set the salary to lower than the minimum wage for an employee that has no job - The warning will not show unless the employee has a job set to him Cause of the bug: - Condition inside _compute_l10n_be_is_below_scale function returned false if an employee had no job Fix done: - Removed unneccessary condition task-5424012
This update fixes a visual issue in the Swiss Master Data Report, specifically the PDF visualization and list view formatting. The changes remove a comma from the 'Year' field display and update the display names of report entries, ensuring accurate and professional reporting for Swiss payroll data.
Original PR description
. Corrected the generated Wage Type Report PDF visualization by modifying the external layout . Fixed the Year field display in the list view: removed the comma . Updated the display name of record "Month + Year" task-5130155
This update corrects a bug in the Belgian payroll module that prevented a minimum wage warning from appearing when an employee record lacked a job assignment. The fix removes a redundant condition within the payroll calculation, ensuring the warning is displayed correctly for all employee types. This ensures accurate payroll reporting for Belgian companies.
Original PR description
Steps to reproduce: - Open an employee on the Employees app for a Belgian company - On the payroll tab, set the salary to lower than the minimum wage for an employee that has no job - The warning will not show unless the employee has a job set to him Cause of the bug: - Condition inside _compute_l10n_be_is_below_scale function returned false if an employee had no job Fix done: - Removed unneccessary condition task-5424012
This update resolves a technical issue within the Enterprise edition's spreadsheet functionality. Specifically, a missing configuration setting was preventing proper sheet identification, which could have caused errors when creating or managing spreadsheets. This fix ensures the spreadsheet feature operates reliably for all users.
Original PR description
…SHEET command
This update fixes a minor issue where the live chat window wasn't consistently opening in the user's current browser tab. The change ensures that when a user initiates a chat, the window automatically appears in their browser, improving the user experience and streamlining communication.
Original PR description
task-5408790 https://github.com/odoo/odoo/pull/240384
4 changes
Resolved issues and error corrections
This update fixes an error in the Mexican payroll module that caused incorrect period end calculations when creating pay runs with schedules like '10 Days' or 'Bi-weekly'. The fix ensures that pay runs are generated with the correct period end date, aligning with updated payroll standards. This improves the accuracy of payroll processing for Mexican companies.
Original PR description
Bug: When we create a new pay run for a mexican company and we select the schedule "10 Days", "14 Days", "Bi-weekly" or "Bi-monthly", the end of the period is computed incorrectly. Cause: The standard method changed but it wasn't updated in the mexican payroll module. Fix: Change the signature of the method to match the one in hr_payroll. Task: 5421825
This update resolves an issue where users without HR permissions couldn't submit 360 feedback. A recent security change now requires access checks on related data, and this fix uses `sudo()` to bypass the check when necessary, allowing these users to complete the process. This ensures all users can participate in 360 feedback assessments.
Original PR description
**Version:** - 19.0 **Steps to reproduce:** - As an administrator, create an appraisal and assign an appraiser who has no HR permissions (regular user role) - Log in as the appraiser. - Attempt to submit a 360 feedback. - An access error is raised. **Issue:** - The 360 feedback wizard fails due to missing access rights when sending the feedback. **Cause:** - https://github.com/odoo/odoo/pull/217277/commits/4a822785ca850c7ae5b21039536333276b2c61af - A recent ORM change now enforces a read-access check on the comodel when writing to Many2many fields. The 360° feedback wizard writes to an M2M field referencing hr.employee, but appraisers (non-HR users) lack read rights on hr.employee, causing the new security check to raise an AccessError. **Fix:** - During create(), check whether the current user has access to rights on hr.employee. If not, create the wizard with `sudo()` so it can create and write the required records without raising an access error. task-5261938
This update fixes a misleading warning message displayed in the eCommerce shop when a subscription product is viewed without a linked plan. The change ensures users receive a clear and accurate message – 'This product has no valid combination' – preventing confusion and potential order errors. This improves the user experience and ensures accurate product information.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Install website_sale_subscription - Create a subscription product without a plan - Open product on eCommerce Issue: - When viewing a subscription product without a subscription plan in the eCommerce shop, the system incorrectly shows the warning "This subscription is not compatible with the one already in your cart. Please order them separately or empty your cart." - This happens even if the cart is completely empty. - The method _is_add_to_cart_possible doesn’t find any valid combination to add to the cart, and because the product is marked as recurring, it always triggers the wrong message. Solution: - Add a condition to check if current product have any recurring price set if not then it will show the correct warning that 'This product has no valid combination.' Impact: - Users see clear and correct warnings on products without a subscription plan. task-5255749 Forward-Port-Of: odoo/enterprise#100929
This update corrects an issue where invoices posted at early times in the Chilean timezone were incorrectly dated as the previous day, causing validation errors. The fix ensures consistent invoice dates during testing by freezing the test time and setting a fixed invoice date aligned with the timezone.
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#10190117 changes
Resolved issues and error corrections
This update fixes alignment issues within the partner record form and improves the user experience by hiding the 'MyInvois' tab when it's not relevant – specifically, for journal entries related to sales or purchases. This ensures that users only see the most pertinent information, streamlining their workflow.
Original PR description
This commit: - Fixes alignment of the `MYINVOIS INFORMATION` section on the partner form. - Hides the `MyInvois` tab on journal entries where journal type is neither `sale` nor `purchase`. task-5356808 Forward-Port-Of: odoo/odoo#239837
This update ensures that downpayment lines in the l10n_my_edi_extended module consistently use a specific classification code ('022') for reporting purposes. This change maintains accurate accounting and tax reporting by standardizing the classification of downpayment transactions, while other product lines continue to use their standard product-based classifications.
Original PR description
Ensure downpayment lines are assigned a fixed classification code ("022"), while other lines retain their product-based classification.
Task-5356913
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update refines how EDI participants are registered within Odoo, specifically targeting localization-specific EDI integrations (MyEDI and Italian EDI). The change ensures that errors related to duplicate registrations are resolved, streamlining the process for users working with these localized EDI systems. This improves reliability and reduces potential registration issues.
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 fixes a technical issue impacting how appointment URLs are generated, leading to improved search engine optimization (SEO) for appointment pages. Previously, the appointment type slug wasn't correctly reflected in URLs, now it is, and users can also adjust the slug for appointment types. This enhances visibility and accessibility for appointments.
Original PR description
This PR replaces the appointment type's id by the slug of this one in the appointment URLs. This allows a better SEO for the appointment pages and users to change the slug of the appointment types too. Previously the slug was not replaces by the value entered in the Cutsom Url field of the Optimize SEO form, this is not longer the case. Community PR: https://github.com/odoo/odoo/pull/231609 Task-5114394
This update fixes a bug in the sales reporting module that was incorrectly calculating profit margins. The fix involves adjusting the calculation formula to ensure accurate margin figures are displayed when using multi-currency pricelists. This ensures sales reports accurately reflect profitability.
Original PR description
Step to reproduce: - create new journal and a pricelist with different currency (here TWD i.e 36.833 * USD) - set that pricelist and journal in a pos - have a product with sales (here 1000$) and cost…
Step to reproduce: - create new journal and a pricelist with different currency (here TWD i.e 36.833 * USD) - set that pricelist and journal in a pos - have a product with sales (here 1000$) and cost price (300$) - create pos and finalize the order with that product - go to sales > reporting > sales > pivot view - check margin for that order Observation: - the margin is calculated wrong due to improper brackets - current calculation ( for TWD currency , multiply with currency rate) sale price - ( cost price / currency rate) i.e. `1000 * 36.833 - (300* 36.833 / 36.833) = 36833 - 300 = 36533` Fix: - fixed the calculation, used brackets - actual calculation - `(1000 * 36.833 - 300 * 36.833) / 36.833 = 1000 - 300 = 700` Before <img width="687" height="97" alt="image" src="https://github.com/user-attachments/assets/3a821a5c-eb12-4eae-9465-1702e9d4ac97" /> After <img width="679" height="110" alt="image" src="https://github.com/user-attachments/assets/d62dbb1d-6839-4099-90b1-6f9a19576721" /> opw-5166714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where assigned values in Many2one fields within project tasks would disappear after saving the changes. The fix ensures that data is correctly handled during the saving process, preventing data loss and maintaining accurate task information. This improves data integrity and user experience.
Original PR description
**Steps to produce:** - Install project module. - Go to project > Open any project > Open any task > Click on gear icon. - Click on Add properies > Set Field type as `Many2one` and Model as…
**Steps to produce:** - Install project module. - Go to project > Open any project > Open any task > Click on gear icon. - Click on Add properies > Set Field type as `Many2one` and Model as `Contact`. - Now assign value to Property 1 > Click on `External button` > Click on `Save & Close`. **Issue:** - The assigned value disappears after saving. **Root cause:** - At [1], since `id` is not an active field (see [2]), it is not present in record.data, which is expected. However, record.data is then passed to m2oTupleFromData, which assumes that the data includes an id because it is normally used on data coming directly from the ORM. - Additionally, since display_name is also not present, m2oTupleFromData falls back to record.data.name, which is not proper. **Solution:** - Use an ORM read to retrieve the proper display_name of the record before constructing the Many2one tuple. [1]: https://github.com/odoo-dev/odoo/blob/24ccc3faf14ade70b21bf253af16a534df726fc8/addons/web/static/src/views/fields/properties/property_value.js#L87-L89 [2]: https://github.com/odoo/odoo/blob/369ca1e5a154235e80b9ea6af7b3f10442c0939f/addons/web/static/src/model/relational_model/record.js#L793-L795 Before: <img width="589" height="68" alt="bef" src="https://github.com/user-attachments/assets/b2aeba0c-1c52-4663-9f94-5c7808a882db" /> After: <img width="613" height="81" alt="after1" src="https://github.com/user-attachments/assets/a3b3d733-929d-4a24-9e17-c73d9569e9b7" /> **opw-5257819** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue that previously caused errors during BIS3 invoice generation when reverse charge accounting was used. The change ensures invoices are correctly formatted and processed, preventing disruptions in financial reporting and compliance. This improves the reliability of our account receivable processes.
Original PR description
opw-5419227 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where videos added to product descriptions in the website editor would disappear after saving. The fix prevents the system from automatically clearing video elements from the description, and includes a setting to prevent video formatting issues in the backend for version 18.0.
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-5218018This update fixes a rounding issue in the sale timesheet module that was causing inaccurate remaining time displays on Sales Orders. The fix eliminates intermediate rounding to ensure precise hour calculations, preventing discrepancies and providing correct time overages. This improves the accuracy of sales reporting.
Original PR description
Steps to reproduce: - Create service product with UoM 'pack of 20 hours' and prepaid policy - Sell the product and confirm the Sales Order - Create a helpdesk ticket/task linked to the Sales Order…
Steps to reproduce: - Create service product with UoM 'pack of 20 hours' and prepaid policy - Sell the product and confirm the Sales Order - Create a helpdesk ticket/task linked to the Sales Order Line - Log 22:00 on timesheets Current behavior: Sales Order Line shows '-2:01 remaining' Expected behavior: Should show '-02:00' to reflect two hours overconsumed without rounding. Root cause: Python's float type follows the IEEE 754 double-precision standard, where only base-2 fractions can be stored precisely. Base-10 fractions cannot be represented exactly, introducing tiny rounding errors. During chained operations such as multiple conversions or subtractions, these small errors accumulate into larger discrepancies. The float_round() function uses a small constant epsilon to correct rounding noise, but as arithmetic chains grow, errors exceed epsilon's tolerance and it can no longer correct them. Since a single global epsilon cannot handle every case (small vs. large values, chained vs. single operations, or regressions), rounding drift is inevitable when rounding happens repeatedly. Fix: To prevent these rounding errors from compounding, the solution is to stop intermediate rounding altogether. By using conversions with round=False, all arithmetic is done in the base unit (hours) with full float precision, and rounding is applied only once when displaying the final value. This eliminates error accumulation and ensures consistent, drift-free results. task-5090240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229282
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 context information was passed. This change streamlines the rental order process and improves data consistency.
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 ECO applications incorrectly linked product documents to attachments, leading to database errors. The fix ensures attachments are correctly associated during ECO application, preventing potential data inconsistencies and application failures. This improves the reliability of ECO processes.
Original PR description
When applying an ECO, the system incorrectly sets the origin_attachment_id of a product.document to a product.document record itself instead of its related ir.attachment. As a result, if the incorrectly referenced ir.attachment is missing, the ECO will attempt to reference a record that does not exist, leading to a foreign key violation during action_apply. Steps to reproduce: 1.) Create an mrp.eco record 2.) Upload a document, take note of the product.document ID 3.) Unlink the ir.attachment with ID = (document ID + 1) (+1 is to account for the .copy within action_apply) 4.) Run eco.action_apply 5.) Observe SQL Constraint Expected result: The ECO should correctly link the product.document to its related ir.attachment. Actual result: origin_attachment_id may point to an unrelated ir.attachment, causing constraint violations when those attachments do not exist. opw-5050263
This update fixes a potential memory error that could occur when installing the new 'account_no_followup' module in Odoo 18. The fix avoids a large data calculation that previously overloaded the system's memory. This ensures smoother module installations and prevents potential performance slowdowns.
Original PR description
The module `account_no_followup` is a new module added in odoo/enterprise#96627. Since it's marked as `auto-install=True` and since it's a dependency of the new `pos_no_followup` module, it may be installed on existing 18.0 databases with a lot of account.move.lines. In this case, the module installation will raise a MemoryError as there's a new stored computed field on journal items called `no_followup`. Computing this field and storing the value in cache will overfill `self.env._cache` and reach the 2GB threshold. This commit fixes that by adding an overwrite of the `_auto_init` method to initialize the field's value in raw SQL, circumventing the issue.
This update addresses a bug fix within the Odoo spreadsheet component. Specifically, it prevents the spread of empty matrices, improving data accuracy and stability. Multiple developers collaborated on this release, ensuring a robust update for the 18.0 version.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/3d9063cb7f [REL] 18.0.52 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/c4c51c062c [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 corrects a bug where archived employees were still appearing in the timesheet section of helpdesk tickets. The fix ensures that timesheets are only populated with active employee data, improving data accuracy and preventing confusion. This resolves a potential issue with reporting and data management.
Original PR description
**Steps to Reproduce:** - Install hekpdesk_timesheet. - Go to settings, enable timesheets - Archive an employee. - In a ticket, try to add a timesheet entry. **Isuue:** Archived employees are also appearing under timesheets tab. **Fix:** Passed a context so that only active employees appear in the selection. task-5078763
This update fixes a technical issue where the HTML Editor was incorrectly accumulating local overlays, leading to potential performance problems. The fix ensures that these overlays are properly cleared when the Editor and its associated plugin are removed, resolving a bug introduced after a website refactor. This improves the stability and performance of the HTML Editor.
Original PR description
This commit ensures that local overlays are correctly removed when the Editor and `LocalOverlayPlugin` are destroyed. Steps to reproduce (observable after 18.4): - Go on website - Enter edit mode - Save - Repeat entering edit mode and saving - Inspect the DOM: oe-local-overlay elements keep accumulating, only one is non-empty The bug is only observable after 18.4, after the website refactoring, but the root cause has been present since 18.0, so we fix it there in case there are other use cases. task-5380409
This update simplifies the TDS tax warning displayed in the withholding process. It now automatically alerts users when a vendor’s PAN (tax identification number) is missing, focusing on the core purpose of collecting this information. Removing the rate-based check ensures a clearer and more consistent warning message.
Original PR description
Simplified the condition to show warning whenever the partner’s PAN is missing in the TDS entry wizard, instead of checking for lower TDS rate. The warning’s purpose is only to alert users to collect PAN from vendors, so rate based check was removed. task-5245353 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where currency rates for non-UYU currencies were incorrectly dated, leading to inaccurate tax calculations. The change ensures all currency rates are synchronized with today's date, resolving a previous error and improving data accuracy for UYU and other currencies.
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
6 changes
Resolved issues and error corrections
This update fixes alignment issues within the partner record view and improves the user experience by hiding the 'MyInvois' tab when it's not relevant (e.g., for non-sale or non-purchase journal entries). This ensures a cleaner and more focused interface for users.
Original PR description
This commit: - Fixes alignment of the `MYINVOIS INFORMATION` section on the partner form. - Hides the `MyInvois` tab on journal entries where journal type is neither `sale` nor `purchase`. task-5356808
This update fixes an issue where currency rates were incorrectly generated with yesterday's date for currencies other than UYU. The change ensures all currency rates are created with today's date, improving accuracy and preventing incorrect tax calculations. This ensures consistent and reliable financial reporting.
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 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
This update resolves a test failure within the Odoo Enterprise system, specifically impacting how employee accounting is handled. The issue stemmed from a miscount of analytic lines created during a test setup, caused by a temporary calendar entry. This fix ensures accurate accounting calculations for employees.
Original PR description
fixing runbot error https://runbot.odoo.com/odoo/runbot.build.error/234639 on test test_mrp_analytic_account_employee_from_widget introduced by this PR https://github.com/odoo/enterprise/pull/85517
**cause of the error:**
Because there is a resource.calendar.leave without calendar_id,
without resource_id and at a date after today :
during the setupclass, when the employee is created,
_create_future_public_holidays_timesheets() creates an account.analytic.line.
So at the end of the test ,
self.env["account.analytic.line"].search([('employee_id', '=', self.employee1.id)])
returns 2 records instead of 1.
runbot-234639This update resolves a bug where forum images set to specific sizes (50% or 25%) were not being saved correctly. The fix disables reliance on inline styles for image sizing within forum posts, ensuring images are displayed as intended. This improves the forum's functionality and user experience.
Original PR description
Problem: When creating a new forum post with an image set to "50%" or "25%" size, the post is saved with the original image size instead of the selected one. Cause: The `Post.content` field has `strip_style=True`, which removes any inline `style` attributes before saving. Since image size ratios were applied using `style="width: 50%"`, the width information was lost. Solution: Disable image size options that depend on inline `style` attributes, as they cannot be preserved when saving forum posts. Steps to reproduce: 1. Go to Forum. 2. Create a new post. 3. Add an image and set its size to 50% or 25%. 4. Save the post — the image appears with its original size. opw-5173917 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures the Odoo spreadsheet functionality is running the most recent version, addressing potential issues and improving performance. It includes fixes related to how spreadsheets are evaluated, preventing errors with empty matrices. This update contributes to a more stable and reliable spreadsheet experience.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4657a89f10 [REL] 17.0.81 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f8365456ed [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 migration issue that previously caused errors when new tax groups weren't automatically created during the migration process. The script now proactively creates necessary tax groups, addressing a situation where groups were accidentally deleted or not properly migrated due to a change in how tax groups were handled in previous versions. This ensures smoother tax setup for new businesses.
Original PR description
Before this commit: migration script only creates a new tax group. After this commit: migration script will create all tax groups that are required for new taxes if they do not already exist Why:…
Before this commit:
migration script only creates a new tax group.
After this commit:
migration script will create all tax groups that are required for new taxes if they do not already exist
Why:
During the migration if the tax group is not found then the value error is raised
There are 2 reason of why the tax group is not found :
1. User deletes it by themselves
2. In the upgrade script of account in version saas~16.2.1.2 the pre-migrate script where global scope of tax groups was converted to company-specific, [Ref](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L173) If the tax groups are not associated with any tax or any account_move_line then it is deleted.
User Traceback :
` File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2203, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: account.1_l10n_id_tax_group_non_luxury_goods`
account_tax_group records in production :
```
kdes_3444743=> select id,name from account_tax_group;
id | name
----+---------------------------------------------------------------
1 | {"en_US": "Taxes", "id_ID": "Pajak"}
2 | {"en_US": "Luxury Good Taxes", "id_ID": "Pajak Barang Mewah"}
3 | {"en_US": "Non-luxury Good Taxes", "id_ID": "Pajak Barang"}
4 | {"en_US": "Zero-rated Taxes", "id_ID": "Pajak Nol"}
5 | {"en_US": "Tax Exempted", "id_ID": "Bebas Pajak"}
(5 rows)
```
Query executed [here](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L152) :
```
WITH company AS (
SELECT "company_id" AS id,
"tax_group_id" AS tg_id
FROM "account_move_line"
WHERE "company_id" IS NOT NULL
AND "tax_group_id" IS NOT NULL
UNION
SELECT "company_id" AS id,
"tax_group_id" AS tg_id
FROM "account_tax"
WHERE "company_id" IS NOT NULL
AND "tax_group_id" IS NOT NULL
)
INSERT INTO account_tax_group ("country_id", "create_date", "create_uid", "name", "preceding_subtotal", "sequence", "write_date", "write_uid", company_id, _tmp_orig_id)
SELECT "tg"."country_id", "tg"."create_date", "tg"."create_uid", "tg"."name", "tg"."preceding_subtotal", "tg"."sequence", "tg"."write_date", "tg"."write_uid", company.id, tg.id
FROM account_tax_group tg,
company
WHERE company.tg_id = tg.id
```
Above selection query on user's DB :
```
kdes_3444743=> SELECT "company_id" AS id,
"tax_group_id" AS tg_id
FROM "account_move_line"
WHERE "company_id" IS NOT NULL
AND "tax_group_id" IS NOT NULL
UNION
SELECT "company_id" AS id,
"tax_group_id" AS tg_id
FROM "account_tax"
WHERE "company_id" IS NOT NULL
AND "tax_group_id" IS NOT NULL;
id | tg_id
----+-------
1 | 1
1 | 2
(2 rows)
```
As only 2 tax groups are associated with the account_move_line and account_tax
They are only being inserted to the able along with the company id prefix and company_id field set
, remaining enteries are deleted in [next query](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L173).
Same is the case with the records in [ir_model_data](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L174-L196).
OPW : 5358546
UPG : 3444743
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr