Daily updates from Odoo
Navigate
Branch
Wednesday, December 17, 2025
120 changes
31 changes
Enhancements to existing features
This update enhances the delivery of Guatemalan electronic invoices to customers by automatically attaching the XML file alongside the PDF. Previously, only the PDF was sent, but now customers receive both files directly in their email, improving transparency and convenience. The XML file naming convention has also been standardized.
Original PR description
Purpose: In the Guatemalan localization, when an electronic invoice is created, the email template to the customer already contains the PDF version of the DTE. However, the XML file, generated and…
Purpose: In the Guatemalan localization, when an electronic invoice is created, the email template to the customer already contains the PDF version of the DTE. However, the XML file, generated and sent to the SAT through Infile, is not attached to that email. Even though the SAT and Infile deliver the XML to the customer, it is more convenient and transparent if Odoo includes it directly in the outgoing invoice template email, so the customer receives both files in one place. Before this commit:- - Only PDF version is attached by default in customer email for e-invoices. - Name of edi document is prefixed with `Demo` if company is in demo environment (check parent company's environment in case of child company) (e.g. DEMO_certificate_INV_2025_00001.xml) and prefixed with `SAT` if company is in testing or production environment(e.g. SAT_certificate_INV_2025_00001.xml). After this commit:- - XML version is also attached by default along with PDF in customer email for e-invoices. - Name of edi document is always prefixed with `SAT`. task-5224521 Forward-Port-Of: odoo/enterprise#98978
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
14 changes
Enhancements to existing features
This update automatically marks Odoo orders as paid when an UrbanPiper order is marked as 'dispatched'. This prevents order cancellations due to cashier oversight and ensures accurate order status tracking. It also integrates UrbanPiper orders into the Odoo blackbox for comprehensive record-keeping.
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#99513
This update enhances the delivery of Guatemalan electronic invoices to customers by automatically including the XML file alongside the PDF. Previously, only the PDF was sent, but now customers receive both files directly in their email, increasing transparency and convenience. The XML file naming convention has also been standardized.
Original PR description
Purpose: In the Guatemalan localization, when an electronic invoice is created, the email template to the customer already contains the PDF version of the DTE. However, the XML file, generated and…
Purpose: In the Guatemalan localization, when an electronic invoice is created, the email template to the customer already contains the PDF version of the DTE. However, the XML file, generated and sent to the SAT through Infile, is not attached to that email. Even though the SAT and Infile deliver the XML to the customer, it is more convenient and transparent if Odoo includes it directly in the outgoing invoice template email, so the customer receives both files in one place. Before this commit:- - Only PDF version is attached by default in customer email for e-invoices. - Name of edi document is prefixed with `Demo` if company is in demo environment (check parent company's environment in case of child company) (e.g. DEMO_certificate_INV_2025_00001.xml) and prefixed with `SAT` if company is in testing or production environment(e.g. SAT_certificate_INV_2025_00001.xml). After this commit:- - XML version is also attached by default along with PDF in customer email for e-invoices. - Name of edi document is always prefixed with `SAT`. task-5224521 Forward-Port-Of: odoo/enterprise#98978
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
4 changes
Enhancements to existing features
This update enhances the delivery of electronic invoices for Guatemalan customers by automatically including the XML file alongside the PDF. Previously, only the PDF was sent, but now customers receive both files directly in their email, improving transparency and convenience. The XML file naming convention has also been standardized.
Original PR description
Purpose: In the Guatemalan localization, when an electronic invoice is created, the email template to the customer already contains the PDF version of the DTE. However, the XML file, generated and…
Purpose: In the Guatemalan localization, when an electronic invoice is created, the email template to the customer already contains the PDF version of the DTE. However, the XML file, generated and sent to the SAT through Infile, is not attached to that email. Even though the SAT and Infile deliver the XML to the customer, it is more convenient and transparent if Odoo includes it directly in the outgoing invoice template email, so the customer receives both files in one place. Before this commit:- - Only PDF version is attached by default in customer email for e-invoices. - Name of edi document is prefixed with `Demo` if company is in demo environment (check parent company's environment in case of child company) (e.g. DEMO_certificate_INV_2025_00001.xml) and prefixed with `SAT` if company is in testing or production environment(e.g. SAT_certificate_INV_2025_00001.xml). After this commit:- - XML version is also attached by default along with PDF in customer email for e-invoices. - Name of edi document is always prefixed with `SAT`. task-5224521 Forward-Port-Of: odoo/enterprise#98978
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
30 changes
New functionality added to Odoo
This update adds visual icons to the list view for VoIP calls, representing recording and transcript options. These icons provide a clearer visual cue for users, making it easier to quickly identify calls with recording or transcript functionality. This improves usability and streamlines access to important call information.
Original PR description
Task-5382341
This update adds tags to key website appointment snippets (cards, pictures, and lists) within the 'add snippets' dialog. This improves organization and allows for easier filtering and targeting of appointment-related content on the website, enhancing the user experience.
Original PR description
This commit adds label tags to respective snippets in add snippets dialog: `Appointment` tag: - s_appointments_card - s_appointments_picture - s_appointments_list task-[5258542](https://www.odoo.com/odoo/project/974/tasks/5258542)
This update adds the ability to view the duration of calls within the Odoo Chatter interface. Previously, call information was limited; now, users can easily track call times alongside other communication details. This improves visibility and reporting for sales and customer support teams.
Original PR description
Task-5343433 ~~Community: https://github.com/odoo/odoo/pull/240242~~
Enhancements to existing features
This update clarifies the heading for the website appointment snippet, making it more understandable for users. The change ensures the snippet's purpose – displaying appointment scheduling options – is immediately clear. This improves the overall user experience on the website.
Original PR description
This commit updates the heading content of the `s_appointments snippet` to ensure it aligns more clearly with its purpose and use case. task-5168006 Requires: - https://github.com/odoo/odoo/pull/235984
This update simplifies the process for salesmen to generate leads directly from appointment meetings. Previously, specific access groups were required; now, leads are automatically assigned to the meeting organizer, streamlining lead creation and improving sales efficiency. This change is an improvement to the existing appointment workflow.
Original PR description
Reduced required access group to enable generating leads from appointments. The lead is assigned to the user selected in the meeting definition
This update allows users to change the name of their Sign Template bundles directly within the configuration process. Previously, the bundle was automatically named after the first document. This change improves usability and provides more control over sign template organization.
Original PR description
Previously, the Sign Template bundle always used the first document's name. This commit enables users to edit the bundle name dynamically in the configuration wizard and updates the breadcrumb accordingly. task-5361809
This update automatically schedules work orders as soon as possible, streamlining the planning process. It maintains the existing option to schedule based on a specific start date, providing flexibility for users. This change improves efficiency and reduces manual effort in managing work orders.
Original PR description
Allow scheduling as soon possible by default while still allowing the (later) option to schedule based on date_start (using the current mechanism) task: 5259035
This update simplifies the creation of engineering change orders (ECOs) by pre-filling common fields and providing clearer visual guidance. The changes enhance user experience, reduce errors, and ensure accurate tracking of product revisions and related engineering modifications, ultimately improving PLM efficiency.
Original PR description
These changes focus on making ECO workflows more intuitive and preventing common mistakes users face while navigating PLM screens. Several tasks that users frequently repeat, such as selecting the…
These changes focus on making ECO workflows more intuitive and preventing common mistakes users face while navigating PLM screens. Several tasks that users frequently repeat, such as selecting the ECO type, are now prefilled based on context. This reduces friction and speeds up ECO creation. Showing the product version consistently, and adding version information to product list views, helps users quickly understand the state of the item they are modifying—especially when working with multiple revisions. Preventing document upload or removal once the ECO is applied avoids accidental changes and maintains proper traceability. Field inputs have also been improved by replacing date radio buttons with a clearer date field, helping users enter information correctly and reducing misinterpretation. The “Apply on” radios are replaced with a selection field that includes a context-based placeholder to guide the user toward the appropriate choice. Additionally, the product form view now shows both Product-type and BOM-type ECOs in the smart button. Previously, only Product-type ECOs were visible. This gives users a complete view of all related engineering changes. The ECO count on the BOM smart button was also incorrect in some cases, and this has been fixed to ensure accurate totals. Overall, these UI improvements create a smoother, safer, and more predictable ECO experience, reducing confusion and helping users follow PLM processes correctly. Task ID: 5358428
This update enhances the user experience when splitting picking orders in Odoo Enterprise. The change aligns with recent community development, streamlining the process and making it more consistent. This improves efficiency for warehouse staff.
Original PR description
Adapt the `_create_backorder` method to accept a new parameter, aligning it with the recent development introduced in the community PR. Task Id:- 5003505
This update enhances Odoo's ability to convert and map domain values, streamlining data filtering within key modules. The change simplifies a previous design restriction, making the system more flexible and efficient. This improves reporting and data management capabilities.
Original PR description
As PR #238734 changed `filter_domain_leaf()` to take only one function to both map and filter the domain (instead of a function to filter and a dict to map, which was too restrictive), and renamed it to the more explicit `filter_map_domain()`, parts using `filter_domain_leaf()` had to be changed to fit the new function prototype. task-5379826
This update simplifies the dashboard editing experience by renaming the 'Edit' button to 'Edit in Spreadsheet'. With recent changes to dashboard creation, the associated 'Add a spreadsheet' button and related elements have been removed to streamline the workflow. This change improves user understanding and consistency.
Original PR description
### Description - Rename the dashboard edit button to "Edit in Spreadsheet" for improved clarity and consistency with the dashboard editing workflow. - As the form view for the spreadsheet dashboard group has been removed and users can now create dashboards using the New button, remove the "Add a spreadsheet" button from the list view, along with its related tours and tests. Task: [5259227](https://www.odoo.com/odoo/project/2328/tasks/5259227)
This update adds a Gantt chart view to the employee attendance smart buttons on payslips and employee forms. This provides a clearer visual timeline of employee work hours, making it easier to track and manage attendance data.
Original PR description
When an employee’s work entry source is Attendance, the “Attendances” smartbutton on both the Payslip and the Employee form opens only a list view. Since attendances represent time intervals, the list view alone is not sufficient to understand the timeline. - This PR adds the Gantt view to both actions to provide a clearer visualization of attendance periods. task-5149218
This update refines the look and feel of appointment pages, including adding appointment durations and improving the overall layout. It also removes outdated components and ensures proper CSS Grid support for optimal display, enhancing the user experience.
Original PR description
* appointment_account_payment, website_appointment, website_appointment_account_payment, website_appointment_sale ### Review appointment snippets design This PR refines the appointment list design…
* appointment_account_payment, website_appointment, website_appointment_account_payment, website_appointment_sale ### Review appointment snippets design This PR refines the appointment list design and updates the two other snippet templates (card and big picture) by adding the duration. It also improves the preview data to better reflect real use cases. ### Fine-tune design of appointment pages This commit refines and updates the overall layout of the frontend appointment pages. As it's not used anymore, this commit also removes the `appointment_progress_bar` template and its inherited record. A migration script is necessary and has been done in PR[1]. We also remove the 'all appointments' button. To ensure the layout works correctly, we need to enable CSS Grid in the portal, which is addressed in PR[2]. task-5160208 Requires: - [1] https://github.com/odoo/upgrade/pull/9049 - [2] https://github.com/odoo/odoo/pull/239617 | | Before | After | |--------|--------|--------| | Add duration in Cards and Big Picture templates | <img width="1376" height="504" alt="image" src="https://github.com/user-attachments/assets/db796a9a-3270-4472-9d24-bc8079d09d55" /><img width="1374" height="535" alt="image" src="https://github.com/user-attachments/assets/d1287f31-295a-41db-aac4-f5e6cc1dd872" /> | <img width="1348" height="546" alt="image" src="https://github.com/user-attachments/assets/6e5d32bb-63a3-402e-af25-5aa917a8502d" /><img width="1369" height="539" alt="image" src="https://github.com/user-attachments/assets/a884c182-0988-4f25-8945-f86fb3fe9100" /> | | Review the List template | <img width="1388" height="558" alt="image" src="https://github.com/user-attachments/assets/1ce0d91c-ea9d-474e-a19c-43fc0e673975" /> | <img width="1380" height="595" alt="image" src="https://github.com/user-attachments/assets/47098d34-8803-47bd-803a-f1ea5ba61bbe" /> | | Appointment pages based on users | <img width="1362" height="729" alt="image" src="https://github.com/user-attachments/assets/3d46cc48-3ed4-49ce-88e6-282d0c06d3dd" /><img width="1339" height="634" alt="image" src="https://github.com/user-attachments/assets/082868de-1619-4aae-9d81-7618e5a3cc4b" /> | <img width="1328" height="637" alt="Capture d’écran 2025-12-10 à 14 28 01" src="https://github.com/user-attachments/assets/5080be89-f5c8-43e4-9321-211482e55e4d" /><img width="1331" height="451" alt="Capture d’écran 2025-12-10 à 14 28 14" src="https://github.com/user-attachments/assets/1c18c32c-8612-402c-8f96-9dc623e4eb60" /> | | Appointment pages based on resources | <img width="1302" height="722" alt="image" src="https://github.com/user-attachments/assets/485f1c4c-2523-468e-a618-be3097235c7e" /><img width="1353" height="591" alt="image" src="https://github.com/user-attachments/assets/41a577dc-9536-4ee7-b981-5e5bcceda927" /> | <img width="1320" height="534" alt="Capture d’écran 2025-12-10 à 14 29 51" src="https://github.com/user-attachments/assets/50b9c8ac-fc0a-4ada-a460-309daed984f0" /><img width="1318" height="431" alt="Capture d’écran 2025-12-10 à 14 30 09" src="https://github.com/user-attachments/assets/ff1cda4e-fedd-4e1a-8960-a28bf35dc203" /> | | Appointment page - Online | <img width="1343" height="736" alt="image" src="https://github.com/user-attachments/assets/be9aade6-d6a0-4d86-8429-d9481d120b3b" /> <img width="1352" height="673" alt="image" src="https://github.com/user-attachments/assets/663e22de-da82-46dd-821e-8650e9d74e5c" /> <img width="1340" height="788" alt="image" src="https://github.com/user-attachments/assets/08cc613c-7029-47bd-8f00-6118286ed117" /> | <img width="1332" height="616" alt="Capture d’écran 2025-12-10 à 14 31 45" src="https://github.com/user-attachments/assets/fbe6711a-c1f7-4959-8e21-a94a6649fe91" /><img width="1333" height="504" alt="Capture d’écran 2025-12-10 à 14 36 23" src="https://github.com/user-attachments/assets/1c8c07d8-87c6-4b1b-9d1a-2db3d4e2aaa0" /><img width="1332" height="571" alt="Capture d’écran 2025-12-10 à 14 35 51" src="https://github.com/user-attachments/assets/2e926696-c75a-4073-9b94-db8262292bf0" /> | | Confirmation page | <img width="1394" height="778" alt="image" src="https://github.com/user-attachments/assets/0ab70545-ea96-48d0-9eb9-21f01600b8e4" /> | <img width="1341" height="518" alt="Capture d’écran 2025-12-10 à 14 38 40" src="https://github.com/user-attachments/assets/196d667b-72f1-4fd4-8105-f38403ac7522" /> | | Appointment cancelled | <img width="1374" height="795" alt="image" src="https://github.com/user-attachments/assets/c7a3370a-238c-429b-bf3e-fa1e0d9aa9ea" /> | <img width="1335" height="469" alt="Capture d’écran 2025-12-10 à 14 39 06" src="https://github.com/user-attachments/assets/0ebd8a40-8be3-4b62-af66-901e7b192c70" /> |
This update streamlines how Odoo matches payments, particularly those processed through payment providers. By generalizing the use of a unique identifier (end-to-end_uuid), the system can now quickly and accurately identify payments, leading to faster reconciliation and improved data accuracy. This change enhances the efficiency of our payment processing workflows.
Original PR description
We use end_to_end_uuid to do a fast match for iso20022 and equivalent. But we can do the same for payments that use a payment provider. These in general give us a reference. Currently, it is used in a ref field that contains other information, forcing us to split it to retrieve it and try to match. Let's generalize the idea of end_to_end_uuid to do a faster match. task-5059766
This update streamlines project calendar task planning by bringing it in line with the standard Odoo Web interface. The changes remove outdated customizations and incorporate updates from a related pull request, improving consistency and usability for project management workflows. This ensures a more unified experience for users.
Original PR description
*: industry_fsm, project_enterprise This commit removes useless customizations and adapts code based on changes made in https://github.com/odoo/odoo/pull/238557 task-5364034
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
Features or functions removed from Odoo
This pull request streamlines the Belgian VAT reporting process by removing a duplicate module and merging its functionality into the main l10n_be_reports module. This consolidation simplifies the reporting system and improves maintainability, ensuring consistent reporting for Belgian businesses.
Original PR description
This module was added in stable in this pr: https://github.com/odoo/enterprise/pull/99496 Now it is removed and merged back into the belgian reporting module. task-5347977
This update removes a development-only method from the HR Expense Stripe module. Removing this unnecessary code improves the overall organization and maintainability of the system. This change ensures the codebase remains clean and efficient.
Original PR description
In 752ffcbc a method was added during development that was later discarded but not removed from the code This removes said method to keep the code tidy
Code cleanup and technical improvements
This update enhances the way VoIP audio is handled within the Enterprise module. Specifically, it replaces an older method with a more modern 'Ringtone' component, resulting in improved audio quality and reliability for remote calls. This change focuses on internal improvements to the VoIP system.
3 changes
New functionality added to Odoo
This pull request focuses on enhancing Odoo's internal documentation. The team added new documentation related to various internal architecture and development processes, including module dependencies, inheritance patterns, and the Odoo layering system. This update aims to improve clarity and support for internal development teams.
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
13 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>
5 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>