Daily updates from Odoo
Wednesday, April 1, 2026
354 changes
13 changes
Resolved issues and error corrections
This fix resolves a system crash that occurred when confirming sales orders containing both regular dropship products and subscription-based dropship products. The issue was caused by inconsistent date format handling in the purchase order system. By standardizing how dates are processed, the system now correctly handles mixed product types without errors.
Original PR description
**Steps to reproduce:** * Install *sale_management*, *sale_subscription*, and *stock* modules. * Go to *Settings* and enable *Dropshipping*. * Create two products: * One *normal dropship* product. *…
**Steps to reproduce:**
* Install *sale_management*, *sale_subscription*, and *stock* modules.
* Go to *Settings* and enable *Dropshipping*.
* Create two products:
* One *normal dropship* product.
* One *dropship + subscription* product.
* Create a *Quotation*.
Add both products to the order.
* Confirm the quotation.
**Observed behavior:**
* A traceback occurs during confirmation:
File '/home/odoo/workspace/odoo19/odoo/addons/purchase_stock/models/stock_rule.py', line 159, in _run_buy
date_planned = po.date_planned or min(v['date_planned'] for v in po_line_values)
TypeError: can't compare datetime.datetime to datetime.date
**Cause:**
* In *_run_buy*, the system computes the earliest *date_planned* using:
https://github.com/odoo/odoo/blob/4056fa8036ddad11c898cd775b7fa21ba4f8a5de/addons/purchase_stock/models/stock_rule.py#L159
* Subscription products set *date_planned* as *datetime.date*,
https://github.com/odoo/enterprise/blob/a88c64a224805d95b60a20c502428897655dba53/sale_subscription_stock/models/sale_order_line.py#L153
`current_period_start = self.order_id.last_invoice_date or
self.order_id.start_date or fields.Date.today()`
* while normal products set *date_planned* as *datetime.datetime*.
https://github.com/odoo/odoo/blob/4056fa8036ddad11c898cd775b7fa21ba4f8a5de/addons/sale_stock/models/sale_order_line.py#L286
before min() It call `_prepare_purchase_order_line_from_procurement`,
the value is assigned directly from `values.get('date_planned')`, and conversion
with `fields.Datetime.to_datetime()` only happens conditionally:
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/purchase_stock/models/purchase_order_line.py#L347-L351
As a result, some values remain `date` while others are `datetime`,
* When both are present in *po_line_values*, Python cannot compare the
two types, causing the crash.
**Fix:**
So by moving the `fields.Datetime.to_datetime()` cast to the initial
assignment of `res['date_planned']`, so it is always a `datetime`
regardless of the source, and removing the now-redundant cast inside
the `if` block.
---
opw-6034079
---
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#255063This update fixes an error that occurred when users tried to view custom snippets they had created from map components. The issue happened because the system couldn't find the original map snippet when certain features were disabled. We've also improved the naming of map snippets to make it clearer which one is the Google Map option, reducing confusion when creating custom snippets.
Original PR description
Steps to reproduce: 1. Go to the website editor (ensure developer mode is off) 2. Drag and drop a Map snippet onto the page 3. Click on the newly placed snippet and save it as a custom snippet 4.…
Steps to reproduce: 1. Go to the website editor (ensure developer mode is off) 2. Drag and drop a Map snippet onto the page 3. Click on the newly placed snippet and save it as a custom snippet 4. Enable developer mode and refresh the website editor 5. Add a new Google Map snippet to the page a. The Google Map snippet is the one where the icon shows a map with a pin on the **left side**. 6. In the wizard, enter your valid API key and click Save a. Alternatively, you can use Odoo inspector to write any string into the `google_maps_api_key` field of the `website` model to simulate the above 7. Disable developer mode and refresh the website editor 8. Click one of the categories in the editor side panel to open the snippets browser 9. Click into the 'Custom' snippets category 10. Observe the error Depending on whether or not you have a Google Maps API key configured on your website, either the `s_map` or `s_google_map` base snippet will be disabled/hidden. When a user has created custom snippets out of the disabled base snippet, you will recieve the error mentioned above when the snippet browser attempts to load in these custom snippets, as it will be unable to load the base snippet. To fix this, we check if an original snippet was found when loading in a custom snippet. If not, we will not load in the custom snippet to avoid confusion. This error does not occur in Developer Mode, as both base snippets are always enabled in this case. Aditionally, we also clarify which snippet is the Google Map snippet to avoid confusion for the user when creating custom snippets. opw-5933787 Forward-Port-Of: odoo/odoo#256847 Forward-Port-Of: odoo/odoo#250236
This fix resolves an issue where invoice delivery notifications (webhooks) were being blocked with access errors when sent between user accounts. The system was incorrectly applying access restrictions to webhook processing, preventing invoices from being properly delivered. This update restores the ability to send and receive invoices through the automated notification system.
Original PR description
- Register your user (on a db that allows webhook). - On another registered account, send an invoice to the first one. => A webhook call has been made, resulting into a 403 Forbidden. Following some changes on access rights checks, the webhook don't work. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256607
This fix corrects an issue where branch companies using their parent company's VAT for PEPPOL registration were incorrectly shown a participation role setting in the configuration. Since branches should only be able to send documents (not receive), this setting is now hidden from the user interface to prevent confusion and ensure proper system behavior.
Original PR description
In v19.0 -> master, if a branch company used the VAT of the parent company to register for peppol, the peppol participation role would be shown in the configuration settings, with a default value being "Sending and receiving", And since branches in this case should be able to ONLY send, the setting shouldnt be visibile to the user. task-none Forward-Port-Of: odoo/odoo#256820
This fix restores the ability to sort grouped lists by date and datetime fields in the Accounting module. Users can now click on the Date column header in grouped views (like Deferred Entries) to sort the data, which was previously broken. This improves the usability of financial reporting and data organization features.
Original PR description
Steps to reproduce 1. Open Accounting > Customers > Invoices and create an invoice with deferred dates. 2. Open the invoice and click the Deferred Entries smart button. 3. In the grouped list view,…
Steps to reproduce 1. Open Accounting > Customers > Invoices and create an invoice with deferred dates. 2. Open the invoice and click the Deferred Entries smart button. 3. In the grouped list view, click the Date column header to sort. 4. Nothing happens. Issue The [IMP] web: Grouped kanban/list in a single RPC (https://github.com/odoo-dev/odoo/commit/26c37c9c070107f8bd753cb8a6d8343384fdd7bf) refactor introduced a regression. _get_read_group_order() [1] iterated over the provided aggregates list to build the ORDER BY clause. Fields with an aggregator attribute that are not included in the aggregates list (e.g. date fields, which getAggregateSpecifications() excludes) were silently dropped from ORDER BY. [1] https://github.com/odoo/odoo/blob/26c37c9c070107f8bd753cb8a6d8343384fdd7bf/addons/web/models/models.py#L496-L514 Solution Add a fallback in _get_read_group_order() so that when fname is neither a groupby field nor present in the provided aggregates list, the method checks field.aggregator directly and appends `fname:aggregator direction` (e.g. `date:min ASC`) to the ORDER BY string. The ORM's _read_group_orderby() already accepts such specs in ORDER BY even without them being in SELECT. opw-6044059 Forward-Port-Of: odoo/odoo#256592
This fix resolves an issue where the coupon code entry form was being hidden after a customer entered a promotional code in their shopping cart. The form will now remain visible and functional when a pricelist with an E-commerce Promotional Code is active, allowing customers to continue using coupon codes as intended.
Original PR description
Issue: --- If the current pricelist has `E-commerce Promotional Code` set, the coupon form is hidden. Steps to reproduce: --- 1- Create a pricelist and set `E-commerce Promotional Code`. 2- Navigate to the cart in website. 3- Enter pricelist code in the coupon form. Result: Once the code is entered, pricelist is changed and the coupon form is hidden. Cause: --- This is done intentionally on #23713. However, it seems it's not relevant anymore. Fix: --- We can remove `force_coupon` condition from `reduction_code` template. However `force_coupon `is also used inside xpath expression in `reduction_coupon_code` template. In order not to break stable we can keep `t-set="force_coupon"` inside the `reduction_code` template, and remove it on master. opw-5977474 Forward-Port-Of: odoo/odoo#256789 Forward-Port-Of: odoo/odoo#252518
The Bluetooth caliper driver was sending measurement readings without a success status flag, causing the system to incorrectly show false disconnection warnings. This fix ensures that successful measurements are properly marked as complete, eliminating the misleading alerts and improving the reliability of Bluetooth device readings.
Original PR description
When a measurement was successfully read via Bluetooth, the driver broadcasted the `value` without the `status` flag. The frontend JavaScript received the `value` but rejected the payload because the `status` was not explicitly marked as successful, leading to a fake disconnection warning. opw-5473691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256860
This fix resolves a bug that prevented purchase orders from being confirmed in certain cases. A previous system update changed the name of a technical field from 'product_uom' to 'product_uom_id', but one part of the code was missed. This update corrects that reference so purchase orders can be confirmed without errors.
Original PR description
A big refactor of UOM in saas-18.1 (https://github.com/odoo/odoo/pull/184131) accidentally left a reference to the `product_uom` field on `purchase.order.line`. But that field was renamed to `product_uom_id` in https://github.com/odoo/odoo/pull/186250. In rare edge-cases, if we it `supplierinfo['product_uom_id'] = line.product_uom.id` while confirming a purchase order, it will block it because of a traceback: ``` supplierinfo['product_uom_id'] = line.product_uom.id ^^^^^^^^^^^^^^^^ AttributeError: 'purchase.order.line' object has no attribute 'product_uom'. Did you mean: 'product_id'? ``` This PR fixes the issues by accounting for the field rename. OPW-6068125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256768 Forward-Port-Of: odoo/odoo#256416
This fix ensures that archived accounts are properly checked when creating unaffected earnings accounts, preventing validation errors during system upgrades. Previously, the system would fail when an archived account had the same code as a new unaffected earnings account, which was causing upgrade failures for companies using the Saudi Arabia localization module.
Original PR description
Archived accounts are also searched when looking for duplicate codes since https://github.com/odoo/odoo/commit/cd8d9718427e48aaa79be21f9a08e89b79b573f9 We need to check archived accounts as well when creating the unaffected earnings account, to avoid triggering the validation if an archived account has the same code. This is failing on upgrades with `l10n_sa` installed where the account `sa_account_999999` has been archived. Forward-Port-Of: odoo/odoo#256112
This fix resolves an issue where replacing the contact form on the /contactus page would cause submission errors. The problem occurred because the system was using email settings from the old form configuration even after the form was deleted and recreated. The fix ensures that email settings are only applied when the original form is still present, preventing mismatches during form submission.
Original PR description
Problem: There is a data-for span in the /contactus page that sets specific values on the page's form. If this form is deleted and a new form is added, an error will occur when trying to submit the new form. This is because the value set for website_form_signature will use the email set in the data-for, which will not match with the new form. Purpose: Modify the code that sets the website_form_signature value to ensure that the original form is present as well if using the data-for values. Steps to Reproduce in Runbot: 1. Use the Website Editor to delete the form on the /contactus page and create a new one. 2. Attempt to submit the new form. opw-5956030 Forward-Port-Of: odoo/odoo#253410
Fixed an issue where Odoo was showing unnecessary warning messages when users uploaded certificate files without setting a password. The system now only displays warnings when a password is actually required, making the user experience clearer and reducing false alerts during the file upload process.
Original PR description
Before the change, when the user uploads a file, Odoo automatically shown a warning message saying that the content of the file or the password are incorrect. Now the system does not show the warning when a password is not set and checks if the password is set when saving task-6036219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256759 Forward-Port-Of: odoo/odoo#253834
This fix resolves an issue where cancelled events from Microsoft Calendar would cause synchronization errors if they hadn't been previously synced to Odoo. The system now properly handles cancelled events during the sync process, preventing errors and ensuring smooth calendar synchronization between Microsoft and Odoo.
Original PR description
Before this commit, when syncing events from Microsoft, if there was a cancelled event that was not yet synchronized with Odoo, calling browse on event.odoo_id would raise an error as it would be None. opw-5917677 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256827
This fix resolves an issue where sales orders and other documents using date-based sequences would display incorrect month/year information in their reference numbers. When a document was dated for a future month, the sequence number would correctly use the future month's counter, but the prefix would incorrectly show the current month. The fix ensures the date used for formatting the sequence prefix matches the date used to select the sequence number.
Original PR description
## Issue When using date_range in a `ir.sequence`, the placeholders `%(...)s` would be based on a different date than the sequence number. ## Steps to reproduce This is one example among other use…
## Issue
When using date_range in a `ir.sequence`, the placeholders `%(...)s` would be based on a different date than the sequence number.
## Steps to reproduce
This is one example among other use cases causing this issue.
1. Install *Sales* (`sale_management`)
2. In Settings > Technical > Sequences, select the `sale.order` sequence
- Set the Prefix to something containing the current month (e.g. `S%(y)s/%(month)s/`)
- Enable *Use subsequences per date_range* (`ir.sequence.use_date_range`)
- Add a row for the current month, with *Next Number* set to 1
- Add a row for the next month, with *Next Number* set to 5
3. Create a Sales Order:
- Any Customer
- Any Product
- Set the *Quotation Date* to next month
- Confirm
4. **The resulting Sales Order uses the sequence from next month (= its name ends with 5), but replace the `%(month)s` placeholder by the current month.**
<img width="541" height="130" alt="image" src="https://github.com/user-attachments/assets/6ace81f9-1ce2-4401-a9ba-383673a20981" />
The original issue reported by ticket 5950028 showed a similar issue with dropshipped Purchase Orders, which would use the date of delivery for the sequence number, and the current month for the placeholder in the prefix/suffix.
## Cause
When interpolating the prefix/suffix of a sequence, the date used by default is `datetime.now(self.env.tz)`. If provided, the context keys `ir_sequence_date` and `ir_sequence_date_range` are used instead.
https://github.com/odoo/odoo/blob/877289cf4d9725e12b355f482308150fe170e816/odoo/addons/base/models/ir_sequence.py#L211-L216
In the `IrSequence._next` method, the correct `ir.sequence.date_range` is chosen, based on the sequence date provided (which is the *Quotation Date* in our steps to reproduce) and the `ir_sequence_date_range` is passed as a context key to be used in the `_interpolation_dict` function later.
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/odoo/addons/base/models/ir_sequence.py#L261-L270
**The `ir_sequence_date` is not passed as a context key, which will make `_interpolation_dict` use `datetime.now(...)` to interpolate the placeholders in the prefix/suffix.**
opw-5950028
Forward-Port-Of: odoo/odoo#256449
Forward-Port-Of: odoo/odoo#25632023 changes
Enhancements to existing features
This update enhances the product import functionality to automatically group product variants under a single product template based on matching product names in import files. Users can now manage entire product families (templates and variants) from a single Excel file, with automatic creation of product attributes and values. This streamlines bulk product management and reduces manual data entry.
Original PR description
Backport: - https://github.com/odoo/odoo/pull/236489 - https://github.com/odoo/odoo/pull/249086 - https://github.com/odoo/odoo/pull/255497 Task: 6041826 Implemented a new product import system that…
Backport: - https://github.com/odoo/odoo/pull/236489 - https://github.com/odoo/odoo/pull/249086 - https://github.com/odoo/odoo/pull/255497 Task: 6041826 Implemented a new product import system that supports grouping product variants under a single product template based on the product name. This new feature allows the creation and update of product templates and their variants from a single Excel file. Grouping Logic: - Variants are grouped onto a product template if they share the same product name in the import file. Attribute Value Handling: - Attribute values are provided in a structured format: `attribute name:value name`, separated by commas (e.g., Color:Red, Size:M). - Attributes and their values are automatically created if they do not already exist in the system. External ID Handling: - If a product/variant has attribute values, the external ID is expected to be a `product.product` External ID. - Otherwise (if it's a simple product or the template record), the external ID is expected to be a `product.template` External ID. Example (.csv): External ID;Internal Reference;Name;Product Type;Barcode;Sales Price;Weight;Sales Description;Attribute values product_template_1;;T-shirt Big Bang;Goods;;110;;T-shirt with Big Bang Theme; product_product_1;T-SHIRT-BB-1;T-shirt Big Bang;;code-b-1;;0,12;;Color:Red,Size:S product_product_2;T-SHIRT-BB-2;T-shirt Big Bang;;code-b-2;;0,13;;Color:Red,Size:M product_product_3;T-SHIRT-BB-3;T-shirt Big Bang;;;115;0,14;;Color:Blue,Size:L product_product_4;T-SHIRT-BB-4;T-shirt Big Bang;;;125;0,15;;Size:M,Color:Red product_product_5;T-SHIRT-SW-RS;T-shirt Stars Wars;Goods;code-1;100;0,12;T-shirt with Stars Wars Theme;Color:Red,Size:S product_product_6;T-SHIRT-SW-RM;T-shirt Stars Wars;Goods;code-2;100;0,13;T-shirt with Stars Wars Theme;Color:Red,Size:M product_product_7;T-SHIRT-SW-RL;T-shirt Stars Wars;Goods;code-3;100;0,14;T-shirt with Stars Wars Theme;Color:Red,Size:L product_product_8;T-SHIRT-SW-BS;T-shirt Stars Wars;Goods;code-5;110;0,12;T-shirt with Stars Wars Theme;Color:Blue,Size:S product_product_9;T-SHIRT-SW-BM;T-shirt Stars Wars;Goods;code-6;110;0,13;T-shirt with Stars Wars Theme;Color:Blue,Size:M product_product_10;T-SHIRT-SW-BL;T-shirt Stars Wars;Goods;code-7;110;0,14;T-shirt with Stars Wars Theme;Color:Blue,Size:L Forward-Port-Of: odoo/odoo#254323
The repair module has been improved to make the code more flexible and easier to customize. A new internal method was created to handle the generation of sales order line information, allowing businesses and developers to extend this functionality without modifying the core code. This makes the system more maintainable and adaptable to custom business needs.
Original PR description
* This change moves the logic of generating sale.order.line values into a new method _prepare_repair_so_line_vals(), allowing easier extension and override in custom modules. 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#220306 Forward-Port-Of: odoo/odoo#213506
Resolved issues and error corrections
Fixed an error that prevented project users from adding customers to tasks. The system was incorrectly trying to update partner information when a customer was assigned, causing an access restriction error. This fix allows project team members to properly assign customers to tasks without encountering permission issues.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only Project > User access. 2. Create a new task in project. 3. Add a customer on the task. 4. Access error is raised. Issue: - - Project users could not create a task with a customer. - An access error appeared during task creation. Cause: - - When a customer was added to the task, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Added a check before writing to avoid unnecessary writes. - Used sudo() to update the partner phone securely. - Added view-level restriction using base.group_partner_manager to control who can edit the phone number. task-5039657 Forward-Port-Of: odoo/odoo#256921 Forward-Port-Of: odoo/odoo#252406
This fix resolves a system crash that occurred when confirming sales orders containing both regular dropship products and subscription-based dropship products. The issue was caused by inconsistent date format handling in the purchase order system. By standardizing how dates are processed, the system now correctly handles mixed product types without errors.
Original PR description
**Steps to reproduce:** * Install *sale_management*, *sale_subscription*, and *stock* modules. * Go to *Settings* and enable *Dropshipping*. * Create two products: * One *normal dropship* product. *…
**Steps to reproduce:**
* Install *sale_management*, *sale_subscription*, and *stock* modules.
* Go to *Settings* and enable *Dropshipping*.
* Create two products:
* One *normal dropship* product.
* One *dropship + subscription* product.
* Create a *Quotation*.
Add both products to the order.
* Confirm the quotation.
**Observed behavior:**
* A traceback occurs during confirmation:
File '/home/odoo/workspace/odoo19/odoo/addons/purchase_stock/models/stock_rule.py', line 159, in _run_buy
date_planned = po.date_planned or min(v['date_planned'] for v in po_line_values)
TypeError: can't compare datetime.datetime to datetime.date
**Cause:**
* In *_run_buy*, the system computes the earliest *date_planned* using:
https://github.com/odoo/odoo/blob/4056fa8036ddad11c898cd775b7fa21ba4f8a5de/addons/purchase_stock/models/stock_rule.py#L159
* Subscription products set *date_planned* as *datetime.date*,
https://github.com/odoo/enterprise/blob/a88c64a224805d95b60a20c502428897655dba53/sale_subscription_stock/models/sale_order_line.py#L153
`current_period_start = self.order_id.last_invoice_date or
self.order_id.start_date or fields.Date.today()`
* while normal products set *date_planned* as *datetime.datetime*.
https://github.com/odoo/odoo/blob/4056fa8036ddad11c898cd775b7fa21ba4f8a5de/addons/sale_stock/models/sale_order_line.py#L286
before min() It call `_prepare_purchase_order_line_from_procurement`,
the value is assigned directly from `values.get('date_planned')`, and conversion
with `fields.Datetime.to_datetime()` only happens conditionally:
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/addons/purchase_stock/models/purchase_order_line.py#L347-L351
As a result, some values remain `date` while others are `datetime`,
* When both are present in *po_line_values*, Python cannot compare the
two types, causing the crash.
**Fix:**
So by moving the `fields.Datetime.to_datetime()` cast to the initial
assignment of `res['date_planned']`, so it is always a `datetime`
regardless of the source, and removing the now-redundant cast inside
the `if` block.
---
opw-6034079
---
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#255063This update corrects a configuration issue where branch companies using their parent company's VAT for PEPPOL registration were incorrectly shown a participation role setting. Since branches can only send documents (not receive), this setting is now hidden from the configuration interface to prevent confusion and ensure proper system behavior.
Original PR description
In v19.0 -> master, if a branch company used the VAT of the parent company to register for peppol, the peppol participation role would be shown in the configuration settings, with a default value being "Sending and receiving", And since branches in this case should be able to ONLY send, the setting shouldnt be visibile to the user. task-none Forward-Port-Of: odoo/odoo#256820
This fix restores the ability to sort grouped lists by date and datetime fields in Odoo. Users can now click on date column headers in grouped views (like the Deferred Entries list) to sort the data, which was broken in a recent update. This improves the usability of financial reporting and data management features.
Original PR description
Steps to reproduce 1. Open Accounting > Customers > Invoices and create an invoice with deferred dates. 2. Open the invoice and click the Deferred Entries smart button. 3. In the grouped list view,…
Steps to reproduce 1. Open Accounting > Customers > Invoices and create an invoice with deferred dates. 2. Open the invoice and click the Deferred Entries smart button. 3. In the grouped list view, click the Date column header to sort. 4. Nothing happens. Issue The [IMP] web: Grouped kanban/list in a single RPC (https://github.com/odoo-dev/odoo/commit/26c37c9c070107f8bd753cb8a6d8343384fdd7bf) refactor introduced a regression. _get_read_group_order() [1] iterated over the provided aggregates list to build the ORDER BY clause. Fields with an aggregator attribute that are not included in the aggregates list (e.g. date fields, which getAggregateSpecifications() excludes) were silently dropped from ORDER BY. [1] https://github.com/odoo/odoo/blob/26c37c9c070107f8bd753cb8a6d8343384fdd7bf/addons/web/models/models.py#L496-L514 Solution Add a fallback in _get_read_group_order() so that when fname is neither a groupby field nor present in the provided aggregates list, the method checks field.aggregator directly and appends `fname:aggregator direction` (e.g. `date:min ASC`) to the ORDER BY string. The ORM's _read_group_orderby() already accepts such specs in ORDER BY even without them being in SELECT. opw-6044059 Forward-Port-Of: odoo/odoo#256592
This fix prevents the express checkout option (Apple Pay, Google Pay) from appearing when customers have gelato products in their cart. Gelato requires email and street address information to calculate shipping costs, which express checkout doesn't provide upfront. This resolves errors that customers were experiencing when trying to use express payment methods with gelato orders.
Original PR description
Issue: --- Public users get error using Apple/Google pay with gelato. Steps to reproduce: --- 1- Setup gelato and stripe express checkout. 2- Using phone, in incognito mode, add a gelato product to cart. 3- Try express checkout. Cause: --- This is because email and street is not present in express checkout. While gelato needs these info to generate calculate shipping cost. Fix: --- We can prevent the express checkout to be shown in gelato orders. opw-5904177 Forward-Port-Of: odoo/odoo#250443
This update resolves a critical issue where invoice delivery notifications (webhooks) were being blocked with access errors. When one user sends an invoice to another, the system now properly handles the notification delivery without permission failures, ensuring invoices are reliably transmitted between accounts.
Original PR description
- Register your user (on a db that allows webhook). - On another registered account, send an invoice to the first one. => A webhook call has been made, resulting into a 403 Forbidden. Following some changes on access rights checks, the webhook don't work. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256607
Users can now successfully search for archived accounts by their account code. Previously, when filtering for inactive accounts and searching by code, the system would not display the archived account even though it matched the search criteria. This fix ensures that the account code search works correctly regardless of whether an account is active or archived.
Original PR description
# How to reproduce - Go to the chart of account - Archive any record (e.g. Code 101401) - Search with the filters : - Inactive Accounts - Account: 101401 (the code of the record) # The problem The…
# How to reproduce
- Go to the chart of account
- Archive any record (e.g. Code 101401)
- Search with the filters :
- Inactive Accounts
- Account: 101401 (the code of the record)
# The problem
The record that we searched for is not shown
# Cause
The domain for the "Account" filter is the following : https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L147
And this is the domain for "Inactive Accounts":
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L159
This is correct and the search should return what we wanted, but the code's search is overriden by:
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/models/account_account.py#L383-L384
And the search with the `code_store` domain only explicitely looks for accounts that are active, so our "[('active', '=', False)]" is essentialy ignored
This is fixed in 19.1 because this commit (https://github.com/odoo/odoo/commit/de959adf7c806e09864b52fec78d981e66804280) replaced the custom search by a `compute_sql`
# Proposed solution
We change the search with the `code_store` to look for records that are both active and inactive, since the active value will be handled by the parent search
opw-6059404
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#256060This fix resolves an issue where replacing the contact form on the /contactus page would cause submission errors. The problem occurred because the system was using email settings from the old form configuration even after the form was deleted and recreated. The fix ensures that email settings are only applied when the original form is still present, preventing mismatches during form submission.
Original PR description
Problem: There is a data-for span in the /contactus page that sets specific values on the page's form. If this form is deleted and a new form is added, an error will occur when trying to submit the new form. This is because the value set for website_form_signature will use the email set in the data-for, which will not match with the new form. Purpose: Modify the code that sets the website_form_signature value to ensure that the original form is present as well if using the data-for values. Steps to Reproduce in Runbot: 1. Use the Website Editor to delete the form on the /contactus page and create a new one. 2. Attempt to submit the new form. opw-5956030 Forward-Port-Of: odoo/odoo#253410
This update improves the certificate upload experience by removing unnecessary warning messages when users haven't set a password. The system now only validates the password when it's actually required during the save process, reducing confusing alerts and making the user experience smoother.
Original PR description
Before the change, when the user uploads a file, Odoo automatically shown a warning message saying that the content of the file or the password are incorrect. Now the system does not show the warning when a password is not set and checks if the password is set when saving task-6036219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256759 Forward-Port-Of: odoo/odoo#253834
This fix resolves an issue where users couldn't close popup windows by pressing the Escape key when the popup contained no clickable buttons or links. The problem occurred because the focus was being set on the wrong element, preventing the browser's built-in close functionality from working. Now popups will consistently close with the Escape key regardless of their content.
Original PR description
Steps to reproduce: =================== - Add a Popup snippet to a page - Remove all links/buttons inside the popup - Save and wait for the popup to appear - Press ESC -> Nothing happens. Cause:…
Steps to reproduce:
===================
- Add a Popup snippet to a page
- Remove all links/buttons inside the popup
- Save and wait for the popup to appear
- Press ESC
-> Nothing happens.
Cause:
======
https://github.com/odoo/odoo/blob/a922c31fa7ccd1107b31287ab1f75697fae874f8/addons/website/static/src/snippets/s_popup/000.js#L219-L226 when the popup contains no tabbable elements, `this.el.focus()` was called. `this.el` refers to the `.s_popup` div, not the `.modal` element that Bootstrap monitors for keyboard events. As a result, the ESC keydown event never reached Bootstrap's handler and the modal stayed open.
When focusable elements (links, buttons) were present, `tabableEls[0].focus()` correctly focused an element inside `.modal`, so ESC worked fine in that case.
Solution:
=========
Replace `this.el.focus()` with `this.el.querySelector(".modal").focus()` so focus lands on the `.modal` element allowing Bootstrap's built-in ESC handler to fire correctly in all cases
opw-5891054
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#254284
Forward-Port-Of: odoo/odoo#250050This fix ensures that archived accounts are properly checked when creating the unaffected earnings account, preventing validation errors during system upgrades. Previously, the system would fail when an archived account had the same code as the new unaffected earnings account, particularly affecting users upgrading with the Saudi Arabia localization module installed.
Original PR description
Archived accounts are also searched when looking for duplicate codes since https://github.com/odoo/odoo/commit/cd8d9718427e48aaa79be21f9a08e89b79b573f9 We need to check archived accounts as well when creating the unaffected earnings account, to avoid triggering the validation if an archived account has the same code. This is failing on upgrades with `l10n_sa` installed where the account `sa_account_999999` has been archived. Forward-Port-Of: odoo/odoo#256112
This fix resolves a rare issue that prevented purchase orders from being confirmed due to an outdated field reference in the system. After a previous update renamed a field from 'product_uom' to 'product_uom_id', some code was not updated accordingly, causing errors when confirming orders. This patch corrects the field reference to ensure purchase orders can be confirmed without interruption.
Original PR description
A big refactor of UOM in saas-18.1 (https://github.com/odoo/odoo/pull/184131) accidentally left a reference to the `product_uom` field on `purchase.order.line`. But that field was renamed to `product_uom_id` in https://github.com/odoo/odoo/pull/186250. In rare edge-cases, if we it `supplierinfo['product_uom_id'] = line.product_uom.id` while confirming a purchase order, it will block it because of a traceback: ``` supplierinfo['product_uom_id'] = line.product_uom.id ^^^^^^^^^^^^^^^^ AttributeError: 'purchase.order.line' object has no attribute 'product_uom'. Did you mean: 'product_id'? ``` This PR fixes the issues by accounting for the field rename. OPW-6068125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256768 Forward-Port-Of: odoo/odoo#256416
This update fixes an error that occurred when users tried to view custom snippets based on map components in the website editor. The issue happened because custom snippets created from disabled base snippets would fail to load. The fix prevents these problematic custom snippets from appearing, and also clarifies the names of the Map and Google Map snippets to reduce user confusion when both are visible in developer mode.
Original PR description
Steps to reproduce: 1. Go to the website editor (ensure developer mode is off) 2. Drag and drop a Map snippet onto the page 3. Click on the newly placed snippet and save it as a custom snippet 4.…
Steps to reproduce: 1. Go to the website editor (ensure developer mode is off) 2. Drag and drop a Map snippet onto the page 3. Click on the newly placed snippet and save it as a custom snippet 4. Enable developer mode and refresh the website editor 5. Add a new Google Map snippet to the page a. The Google Map snippet is the one where the icon shows a map with a pin on the **left side**. 6. In the wizard, enter your valid API key and click Save a. Alternatively, you can use Odoo inspector to write any string into the `google_maps_api_key` field of the `website` model to simulate the above 7. Disable developer mode and refresh the website editor 8. Click one of the categories in the editor side panel to open the snippets browser 9. Click into the 'Custom' snippets category 10. Observe the error Depending on whether or not you have a Google Maps API key configured on your website, either the `s_map` or `s_google_map` base snippet will be disabled/hidden. When a user has created custom snippets out of the disabled base snippet, you will recieve the error mentioned above when the snippet browser attempts to load in these custom snippets, as it will be unable to load the base snippet. To fix this, we check if an original snippet was found when loading in a custom snippet. If not, we will not load in the custom snippet to avoid confusion. This error does not occur in Developer Mode, as both base snippets are always enabled in this case. Aditionally, we also clarify which snippet is the Google Map snippet to avoid confusion for the user when creating custom snippets. opw-5933787 Forward-Port-Of: odoo/odoo#255704 Forward-Port-Of: odoo/odoo#250236
The Bluetooth caliper driver was sending measurement readings without a success status flag, causing the system to incorrectly show disconnection warnings even when measurements were read successfully. This fix ensures the driver properly marks measurements as successful, eliminating false disconnection alerts.
Original PR description
When a measurement was successfully read via Bluetooth, the driver broadcasted the `value` without the `status` flag. The frontend JavaScript received the `value` but rejected the payload because the `status` was not explicitly marked as successful, leading to a fake disconnection warning. opw-5473691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a validation issue in the payment demo module to ensure provider configurations are properly checked. The fix prevents potential errors when processing payments by validating that the payment provider is correctly configured before use.
Original PR description
opw-3097856 Forward-Port-Of: odoo/odoo#256362
Mozambique users were seeing the incorrect Brazilian tax ID label "CPF/CNPJ" on their sales orders and invoices instead of the correct Mozambican label "NUIT". This fix adds the proper tax ID label for Mozambique so users now see the correct terminology on their business documents.
Original PR description
Currently the "Tax ID" title used e.g. on sales orders, invoices, etc. was translated as "CPF/CNPJ" in Portuguese, which is the tax ID used in Brazil. However, in Mozambique, the tax ID is called "NUIT", and there is no language variant for Portuguese in Mozambique. This caused Mozambique users to see "CPF/CNPJ" instead of "NUIT" on their documents, which was wrong. This commit adds a `vat_label` field for Mozambique to display the correct tax ID label. Issue reported by functional support. Forward-Port-Of: odoo/odoo#256603
This fix resolves an issue where the coupon code entry form was being hidden after a customer entered a promotional code in their shopping cart. The form will now remain visible and functional when a pricelist with promotional codes is active, allowing customers to continue applying discount codes without interruption.
Original PR description
Issue: --- If the current pricelist has `E-commerce Promotional Code` set, the coupon form is hidden. Steps to reproduce: --- 1- Create a pricelist and set `E-commerce Promotional Code`. 2- Navigate to the cart in website. 3- Enter pricelist code in the coupon form. Result: Once the code is entered, pricelist is changed and the coupon form is hidden. Cause: --- This is done intentionally on #23713. However, it seems it's not relevant anymore. Fix: --- We can remove `force_coupon` condition from `reduction_code` template. However `force_coupon `is also used inside xpath expression in `reduction_coupon_code` template. In order not to break stable we can keep `t-set="force_coupon"` inside the `reduction_code` template, and remove it on master. opw-5977474 Forward-Port-Of: odoo/odoo#256438 Forward-Port-Of: odoo/odoo#252518
This fix resolves an issue where importing sales and purchase orders with line-level charges (allowances and surcharges) would fail. The system now correctly processes quantity and tax information for these special line items, ensuring orders with complex charge structures can be imported successfully without errors.
Original PR description
When importing orders with line-level charges, the import would fail because the `quantity` key was not being renamed to correct quantity keys (`'product_uom_qty'` for sale order and `'product_qty'` for purchase order) for allowance charge lines. The issue occurred because the key renaming was only applied to the main lines_vals list after calling `_import_lines()`, but not to the `allowance_charges_line_vals` that were created separately. Also the key for taxes returned in `_get_line_vals_list` method in `purchase.order` model is `'taxes_id'` which is not aligned with the `purchase.order.line` model. This fix properly handles the quantity key renaming for both regular lines and allowance charge lines and updates `'taxes_id'` key value to `'tax_ids'`, preventing the AttributeError when accessing the quantity key during order line creation. Forward-Port-Of: odoo/odoo#245411
This fix corrects an issue where loyalty programs were incorrectly matching and accumulating points when price list functionality was disabled. Previously, disabled price lists were still being retained in the system, causing loyalty programs restricted to specific price lists to continue matching incorrectly. This update ensures loyalty programs behave as expected regardless of price list settings.
Original PR description
When `use_pricelist` is disabled, `available_pricelist_ids` retains previously configured pricelists. This caused loyalty programs restricted to a specific pricelist to still match and accumulate points incorrectly. opw-5952960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256398 Forward-Port-Of: odoo/odoo#252718
This fix ensures that guest customer accounts are only archived when automatic invoicing is enabled, and only after the invoice has been successfully sent. Previously, guests were archived immediately after order confirmation, which caused issues when manually sending invoices as the recipient field would be empty. This change also ensures company partners are properly archived along with guest contacts.
Original PR description
Before this fix, when automatic invoicing was disabled, manually sending an invoice by email resulted in an empty "Send To" field because the guest contact had already been archived. To prevent this issue, guest archiving is now triggered only when automatic invoicing is enabled. Additionally, to avoid problems with email delivery, the guest is archived only after the invoice has been sent. This ensures that the email generation process sees the guest as active. If the guest were archived immediately after the Sales Order confirmation, the email generation logic in `mail_thread.py` would skip the archived partner (`pdata['active'] is False`), preventing the invoice email from being sent.
This fix resolves an issue where duplicate "Replace by Attendance" buttons appeared when employees had multiple work entries of the same type on different days. The problem caused the system to crash when users clicked on calendar cells. The fix removes duplicate work entry types from the button list to ensure a clean, functional calendar experience.
Original PR description
### Steps to reproduce: - Download Payroll app - From the top bar 'Employees' > 'Employees', create a new employee - Select the created employee > click 'Work Entries' smart button, add 2 Attendance…
### Steps to reproduce: - Download Payroll app - From the top bar 'Employees' > 'Employees', create a new employee - Select the created employee > click 'Work Entries' smart button, add 2 Attendance work entries on different days, with different creation days (either wait 24h between creations, or adjust one create_date in DB) - Click on any day, you'll find the "Replace by Attendance" smart button replicated > If you activate debug mode and click on any cell > **UncaughtPromiseError > OwlError** ### Cause of issue: https://github.com/odoo/odoo/blob/72be98d705e225f663b65e289e11d0b8642ec6f8/addons/hr_work_entry/static/src/views/work_entry_calendar/work_entry_calendar_model.js#L30-L58 `formattedReadGroup` is called with both `work_entry_type_id` and `create_date:day`. If the user has created several work entries of the same type on different days, we would get multiple group results having the same `work_entry_type_id`. These duplicated records later produce an Owl crash because the button list uses `t-key="workEntry.id"`. https://github.com/odoo/odoo/blob/72be98d705e225f663b65e289e11d0b8642ec6f8/addons/hr_work_entry/static/src/views/work_entry_calendar/work_entry_multi_selection_buttons.xml#L16-L17 ### Fix: Since the goal of the above method is to extract the favorite work entries to later use in smart buttons and `userFavoritesWorkEntriesIds.map((r) => r.work_entry_type_id?.[0]).filter(Boolean)` extracts all the entries' `work_entry_type_id` (including duplicates), the easiest way to get rid of these duplicates is to create a `Set`. opw-5953671 Forward-Port-Of: odoo/odoo#252478 Note about v19.1: Since the bug isn't present in this version, we'll only merge the test.
17 changes
Enhancements to existing features
The repair module has been improved to make the code easier to customize and extend. A new internal method has been created to handle the generation of sales order line information, allowing businesses and developers to more easily modify this behavior for their specific needs without affecting the core functionality.
Original PR description
* This change moves the logic of generating sale.order.line values into a new method _prepare_repair_so_line_vals(), allowing easier extension and override in custom modules. 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#220306 Forward-Port-Of: odoo/odoo#213506
Resolved issues and error corrections
This update adds support for three new fields (price, currency, and support) in the app manifest validation for Odoo's app store. These fields are now recognized as valid manifest keys, allowing app developers to properly list pricing and support information when publishing apps to the Odoo marketplace.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256726 Forward-Port-Of: odoo/odoo#255857
This fix corrects undefined variables in the website store editor that were causing preview elements to display incorrectly. When customizing store layouts, certain design elements like placeholder rectangles were not showing properly. This update ensures all editor previews render with the correct styling and appearance.
Original PR description
The editor previews are not having the expected design due to the `c` and `p` variables being undefined. Steps to reproduce for eg. filmstrip: - Disable the `categories_opt_top` (Categories: top) - Hover the "Top" editor button - See the filmstrip is missing it's placeholder rectangle "text" due to the width style not being applied. task-6047816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255339
This update fixes a bug in the Jordan electronic invoice system where refunds with multiple identical product lines were not being processed correctly. The system now properly matches each refund line to the correct invoice line, preventing duplicate matches and ensuring accurate credit note processing.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#256365 Forward-Port-Of: odoo/odoo#252200
Optional product tables in sales reports were not displaying with the correct styling due to DOM structure differences. This fix applies the proper table styling to ensure optional products appear consistently formatted in sales documents. Users may need to update their document layout settings for color changes to take effect.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430
Users can now successfully search for archived accounts by their account code. Previously, when filtering for inactive accounts and searching by code, the system would not display the archived records because the search logic was only looking at active accounts. This fix ensures that archived accounts are properly included in search results when users specifically filter for them.
Original PR description
# How to reproduce - Go to the chart of account - Archive any record (e.g. Code 101401) - Search with the filters : - Inactive Accounts - Account: 101401 (the code of the record) # The problem The…
# How to reproduce
- Go to the chart of account
- Archive any record (e.g. Code 101401)
- Search with the filters :
- Inactive Accounts
- Account: 101401 (the code of the record)
# The problem
The record that we searched for is not shown
# Cause
The domain for the "Account" filter is the following : https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L147
And this is the domain for "Inactive Accounts":
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L159
This is correct and the search should return what we wanted, but the code's search is overriden by:
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/models/account_account.py#L383-L384
And the search with the `code_store` domain only explicitely looks for accounts that are active, so our "[('active', '=', False)]" is essentialy ignored
This is fixed in 19.1 because this commit (https://github.com/odoo/odoo/commit/de959adf7c806e09864b52fec78d981e66804280) replaced the custom search by a `compute_sql`
# Proposed solution
We change the search with the `code_store` to look for records that are both active and inactive, since the active value will be handled by the parent search
opw-6059404
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#256060Fixed an error that prevented project team members from adding customers to tasks. The system now properly handles customer assignments without triggering permission errors, making it easier for project users to manage task details and customer relationships.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only Project > User access. 2. Create a new task in project. 3. Add a customer on the task. 4. Access error is raised. Issue: - - Project users could not create a task with a customer. - An access error appeared during task creation. Cause: - - When a customer was added to the task, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Added a check before writing to avoid unnecessary writes. - Used sudo() to update the partner phone securely. - Added view-level restriction using base.group_partner_manager to control who can edit the phone number. task-5039657 Forward-Port-Of: odoo/odoo#256755 Forward-Port-Of: odoo/odoo#252406
Users encountered an access rights error when trying to create private tasks (tasks with no project and no assigned users). This fix ensures that when a task is created as private, the creator is automatically assigned to it, giving them proper access rights. This resolves the frustrating error that prevented users from creating private tasks while maintaining the ability to modify existing tasks.
Original PR description
When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. Steps to reproduce: 1.Open the form view to create a new task. 2.Clear…
When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. Steps to reproduce: 1.Open the form view to create a new task. 2.Clear the Project field. When empty, it should display the Private placeholder. 3.Ensure no user is assigned to the task. 4.Create the private task. 5.An access rights error occurs, stating that the user does not have permission to create the record. ⚠️ Note: This access rights error only occurs when the task is created directly as private. If a task is created normally and then its project_id and user_ids are removed afterward, no access rights error occurs. Root cause: When a task is created without a project_id and without assigned users, Odoo checks access rights on creation. Since no project members or assigned users exist, no user has access to the record, including the creator. This results in an access rights error during creation. This issue does not occur when modifying an existing task because, after creation, the creator is automatically added as a follower. As a follower, the creator retains access to the task even if it has no project and no assigned users. Fix (implemented): Tasks that have no assigned users and are not linked to any project (private tasks) did not make sense, as they were effectively assigned to nothing. To address this, we now require at least one user to be assigned to a task when it is not attached to a project. This change was made inside of the "project_task_view.xml" file in the "view_task_form_2" record Versions : 17.0 -> master Task [5403926](https://www.odoo.com/odoo/project/4105/tasks/5403926) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242216
This fix resolves an issue where replacing the contact form on the /contactus page would cause submission errors. The problem occurred because the system was using email settings from the old form configuration even after the form was deleted and recreated. The fix ensures that email settings are only applied when the original form is still present, preventing mismatches during form submission.
Original PR description
Problem: There is a data-for span in the /contactus page that sets specific values on the page's form. If this form is deleted and a new form is added, an error will occur when trying to submit the new form. This is because the value set for website_form_signature will use the email set in the data-for, which will not match with the new form. Purpose: Modify the code that sets the website_form_signature value to ensure that the original form is present as well if using the data-for values. Steps to Reproduce in Runbot: 1. Use the Website Editor to delete the form on the /contactus page and create a new one. 2. Attempt to submit the new form. opw-5956030 Forward-Port-Of: odoo/odoo#253410
Mozambique users were seeing the incorrect Brazilian tax ID label "CPF/CNPJ" on their sales orders and invoices instead of the correct Mozambican label "NUIT". This fix adds the proper tax ID label for Mozambique so users now see the correct terminology on their business documents.
Original PR description
Currently the "Tax ID" title used e.g. on sales orders, invoices, etc. was translated as "CPF/CNPJ" in Portuguese, which is the tax ID used in Brazil. However, in Mozambique, the tax ID is called "NUIT", and there is no language variant for Portuguese in Mozambique. This caused Mozambique users to see "CPF/CNPJ" instead of "NUIT" on their documents, which was wrong. This commit adds a `vat_label` field for Mozambique to display the correct tax ID label. Issue reported by functional support. Forward-Port-Of: odoo/odoo#256603
This update improves the payment demo module by adding validation checks for provider configuration. The fix ensures that payment provider settings are properly validated before use, preventing potential errors and improving system reliability when processing demo payments.
Original PR description
opw-3097856 Forward-Port-Of: odoo/odoo#256362
Fixed a crash that occurred when users deleted text from a toggle list title in the To-Do application. The issue happened because the system tried to check properties of a non-existent element. This fix ensures the system only checks for the next element when it actually exists, preventing the crash and allowing users to delete toggle list titles without errors.
Original PR description
Steps to Reproduce: - Go to To-Do → Create New - Create a toggle list - Type something in the title - Press the delete button Description of the issue: - A traceback occurs. Cause: - In `handleDeleteForwardTitleEnd`, there is a check to verify whether the toggle title’s next sibling matches the toggle selector. However, when there is no next sibling, calling `matches()` results in a traceback. Solution: - Only check `matches()` if the next sibling exists. task-6040479 Forward-Port-Of: odoo/odoo#254557
This fix resolves an issue where the system was not checking archived accounts when validating account codes during unaffected earnings account creation. This was causing upgrade failures for companies using the Saudi Arabia localization module, where an archived account with code 999999 was triggering validation errors. The fix ensures archived accounts are properly considered to prevent false validation conflicts.
Original PR description
Archived accounts are also searched when looking for duplicate codes since https://github.com/odoo/odoo/commit/cd8d9718427e48aaa79be21f9a08e89b79b573f9 We need to check archived accounts as well when creating the unaffected earnings account, to avoid triggering the validation if an archived account has the same code. This is failing on upgrades with `l10n_sa` installed where the account `sa_account_999999` has been archived. Forward-Port-Of: odoo/odoo#256112
Fixed a crash that occurred when using Point of Sale to settle orders containing subscription products with discounts. The system was incorrectly trying to process discount information lines as regular order items, causing the application to crash. The fix treats these informational lines similarly to notes, preventing the error.
Original PR description
**Steps to reproduce:** - Make a subscription product - Make a quotation with it, confirm it, then invoice it - Go back to the sale order and upsell it - Add another product - Go to the PoS to settle the order - A traceback appears **Why the fix:** Why tried to treat the informative line that says that this is a discount as a normal pos order line. We then tried to access the line's template, which caused a crash as the line's template was undefined. We now treat the line as we do a note, meaning to add it to the previous line in the order. We create a function to check if the line is a note and we override it in the **pos_sale_subscription** module. Enterprise PR: https://github.com/odoo/enterprise/pull/107002 opw-5582448 Forward-Port-Of: odoo/odoo#247846
This fix corrects how buttons with custom sizes or shapes are displayed in the website editor's button styling panel. When buttons have size or shape customizations applied, they are now properly recognized as "custom" buttons, ensuring the editor shows the correct styling options to users.
Original PR description
Before this commit: Since the removal of button style options for the preset primary and secondary styling, the type of a primary/secondary button with size or shape defined in the class should be "custom". The fix is made to saas-18.4 cause the custom button option is removed in saas-18.3 and reintroduced only from saas-18.4. The button option removal commit: https://github.com/odoo/odoo/commit/a7b71d700e4997e4a2f646e2ae12f58f20058dc4 The button custom option reintroduction: https://github.com/odoo/odoo/commit/ea22b28bbae009c9eab4ff397affa9a3cb71037a After this commit: when the button has size or shape classes, we consider it as "custom" button. task-6061443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where PDF invoices containing embedded XML attachments organized in a nested structure were not being properly extracted, resulting in empty bills. The system now correctly handles both flat and nested PDF attachment formats, ensuring that invoice data is properly captured regardless of how the PDF organizes its embedded files.
Original PR description
Steps to reproduce: - From the accounting dashboard, upload a PDF containing intermediate /Kids nodes representing separate xml attachments Issue: No xml will be extracted, as result the bill will be empty. However, in the chatter pdf preview, the js pdf toolkit correctly show the xml attachemnts. Analysis: The PDF spec defines two ways to organize embedded files under /EmbeddedFiles in the document's name dictionary: - /Names: a flat array of pairs located directly under /EmbeddedFiles - /Kids: an array of child nodes, each of which carries its own /Names array. The extractor currently only handled the /Names case, not detecting embedded attachments in case of PDF using a /Kids tree. This change add lookup for both structures. opw-5929274 Forward-Port-Of: odoo/odoo#252523
Fixed a bug where gradient text colors were not properly removed when switching to solid colors in the note editor. Previously, when users applied a gradient color and then switched to a solid color, the gradient would incorrectly appear as a background color instead of being replaced. This fix ensures gradients are properly cleared in all cases.
Original PR description
Steps to reproduce: - Go to a To-do note - Select a word - Apply a gradient as the text color - Re-open the color picker - From the Solid tab, select the primary color (o-color-1) Description of the issue: - The gradient is not removed and ends up being displayed as a background color Cause: - In the `colorElement` method, the gradient is removed when applying a text color via inline styles. However, when applying a color via class (e.g., text-*), the gradient is not properly cleared. Only the text-gradient class is replaced, while the gradient style remains, causing it to appear as a background color. Solution: Ensure the gradient is removed in both cases: - when applying a color via class and when applying a color via inline styles in `colorElement`. task-6045533
18 changes
New functionality added to Odoo
This update adds the IoT Base module to Odoo's translation management system (Weblate), enabling the module to be translated into multiple languages. The change includes translation files for over 20 languages, making the IoT Base functionality accessible to users worldwide in their preferred languages.
Original PR description
Related: https://github.com/odoo/enterprise/pull/111141 Forward-Port-Of: odoo/odoo#254996 Forward-Port-Of: odoo/odoo#254667
Enhancements to existing features
This update improves the internal organization of the Repair module by separating the logic that creates sales order line information into its own dedicated method. This makes it easier for developers to customize and extend the repair functionality without modifying the core code, supporting better long-term maintenance and customization.
Original PR description
* This change moves the logic of generating sale.order.line values into a new method _prepare_repair_so_line_vals(), allowing easier extension and override in custom modules. 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#220306 Forward-Port-Of: odoo/odoo#213506
Resolved issues and error corrections
This fix addresses an issue where text formatting (bold, italic, etc.) on iOS Safari was not working correctly due to improper cursor positioning. The change adjusts where the cursor is placed after applying formatting, ensuring that Safari properly recognizes and displays the formatted text. This improves the text editing experience for iOS Safari users.
Original PR description
Before this commit: when we applying format on collapsed cursor, we create a formatted element with ZWS, and set the cursor before the ZWS After this commit: we set the cursor after the ZWS, cause otherwise safari doesn't update the cursor properly leading to unformatted input task-4243977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256370 Forward-Port-Of: odoo/odoo#249253
This update fixes a problem where website assets fail to load properly after design changes in multi-database environments. When a user modifies website styling (like theme colors), the system regenerates assets but couldn't find them immediately due to database synchronization delays. The fix ensures assets are properly available right after regeneration, preventing broken website displays.
Original PR description
When `/web/assets/...` is requested on a readonly route and the bundle is missing, Odoo regenerates it on the primary using a RW cursor. It can then still try to read the freshly created…
When `/web/assets/...` is requested on a readonly route and the bundle is missing, Odoo regenerates it on the primary using a RW cursor. It can then still try to read the freshly created `ir.attachment` through the original RO/replica env. In a primary/replica setup, replication may not have caught up yet, so the new attachment is not visible on the replica. As a result, readonly `/web/assets/...` requests can fail right after asset regeneration when fetching the freshly generated bundle. Steps to reproduce: 1. Configure Odoo with a PostgreSQL primary/replica setup. 2. Open a website in edit mode. 3. Trigger an asset regeneration (for example by changing a theme color). 4. Let the resulting readonly `/web/assets/...` request fetch the freshly generated bundle. Build the response stream from the RW env after regeneration instead of rereading the fresh attachment through the RO/replica env. opw-6034833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255530
Optional product tables in sales documents were not displaying with the correct report styling due to DOM structure differences. This fix applies the proper styling to these tables so they appear consistently with other report tables. Users may need to update their document layout settings for color changes to take effect.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430
This fix resolves an issue where refunds created from invoices with duplicate line items (same product, price, and discount) were incorrectly matched. The system now prevents matching the same invoice line multiple times and ignores line labels during matching, ensuring accurate refund processing for Jordan EDI compliance.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#256365 Forward-Port-Of: odoo/odoo#252200
This fix prevents the system from creating false absence records for employees whose employment contracts haven't started yet. Previously, when running the absence detection process, employees with future contract start dates would incorrectly be marked as absent, creating negative overtime records. The system now properly checks contract dates before flagging absences.
Original PR description
### Steps to reproduce: - Create an employee with contract starts in the future - Activate the Absence Management from attendance settings - Run the cron of Absence Detection - Notice an absence attendance got created for the emp with the future contract ### Cause: We don't check for contracts start dates when fetching absent employees and we get expected attendance for them from their working schedule so we create -ve overtime for them. ### Fix: We filter the absent employees on their running contracts. It has been fixed in since 18.4 in this commit https://github.com/odoo/odoo/commit/5db242416522524849a20eb83df3937c193c98d3 opw-5942239 Forward-Port-Of: odoo/odoo#253358
A typo in the test_views domain has been corrected in the base module's test file. This fix ensures that automated tests run correctly and helps maintain code quality by preventing test failures caused by the typo.
Original PR description
A typo was introduced in #163714 Forward-Port-Of: odoo/odoo#231897 Forward-Port-Of: odoo/odoo#228977
Users encountered an access rights error when trying to create private tasks (tasks with no project and no assigned users). This fix automatically assigns the task creator as a user when a private task is created, ensuring they have proper access to their own task. This resolves a frustrating error that prevented users from creating private tasks while maintaining the ability to modify existing tasks.
Original PR description
When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. Steps to reproduce: 1.Open the form view to create a new task. 2.Clear…
When users would follow the following step as they are makeing a private task, they would be hit by an incorrect access error. Steps to reproduce: 1.Open the form view to create a new task. 2.Clear the Project field. When empty, it should display the Private placeholder. 3.Ensure no user is assigned to the task. 4.Create the private task. 5.An access rights error occurs, stating that the user does not have permission to create the record. ⚠️ Note: This access rights error only occurs when the task is created directly as private. If a task is created normally and then its project_id and user_ids are removed afterward, no access rights error occurs. Root cause: When a task is created without a project_id and without assigned users, Odoo checks access rights on creation. Since no project members or assigned users exist, no user has access to the record, including the creator. This results in an access rights error during creation. This issue does not occur when modifying an existing task because, after creation, the creator is automatically added as a follower. As a follower, the creator retains access to the task even if it has no project and no assigned users. Fix (implemented): Tasks that have no assigned users and are not linked to any project (private tasks) did not make sense, as they were effectively assigned to nothing. To address this, we now require at least one user to be assigned to a task when it is not attached to a project. This change was made inside of the "project_task_view.xml" file in the "view_task_form_2" record Versions : 17.0 -> master Task [5403926](https://www.odoo.com/odoo/project/4105/tasks/5403926) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242216
This update allows Odoo apps in the apps store to include additional manifest fields for price, currency, and support information. The change enables app developers to properly configure these important app store attributes without triggering validation errors.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255857
Mozambique users were seeing the incorrect Brazilian tax ID label "CPF/CNPJ" on their sales orders and invoices instead of the correct Mozambican label "NUIT". This fix adds the proper tax ID label for Mozambique so users now see the correct terminology on their business documents.
Original PR description
Currently the "Tax ID" title used e.g. on sales orders, invoices, etc. was translated as "CPF/CNPJ" in Portuguese, which is the tax ID used in Brazil. However, in Mozambique, the tax ID is called "NUIT", and there is no language variant for Portuguese in Mozambique. This caused Mozambique users to see "CPF/CNPJ" instead of "NUIT" on their documents, which was wrong. This commit adds a `vat_label` field for Mozambique to display the correct tax ID label. Issue reported by functional support. Forward-Port-Of: odoo/odoo#256603
This fix resolves an issue where replacing the contact form on the /contactus page would cause submission errors. The problem occurred because the system was using email settings from the old form configuration even after the form was deleted and recreated. The fix ensures that email settings are only applied when the original form is still present, preventing mismatches during form submission.
Original PR description
Problem: There is a data-for span in the /contactus page that sets specific values on the page's form. If this form is deleted and a new form is added, an error will occur when trying to submit the new form. This is because the value set for website_form_signature will use the email set in the data-for, which will not match with the new form. Purpose: Modify the code that sets the website_form_signature value to ensure that the original form is present as well if using the data-for values. Steps to Reproduce in Runbot: 1. Use the Website Editor to delete the form on the /contactus page and create a new one. 2. Attempt to submit the new form. opw-5956030 Forward-Port-Of: odoo/odoo#253410
This update improves the demo payment provider by adding validation checks to ensure the payment provider is properly configured before processing transactions. This prevents errors and ensures a smoother payment experience for users testing the demo payment functionality.
Original PR description
opw-3097856 Forward-Port-Of: odoo/odoo#256362
Fixed an issue where the bold formatting button would not remove bold styling when the selection included embedded components like files. The editor was incorrectly considering non-editable elements when determining whether to apply or remove bold formatting, causing the toggle to get stuck in "apply" mode. This fix ensures only editable content is evaluated when toggling text styles.
Original PR description
When determining whether the "bold" action is about adding bold or removing bold, non-editable text nodes are also taken into account. Because of this, if the selection contains an embedded component such as `/file`, it always considers bold was not applied on all nodes, and should therefore be applied. The action thus never removes bold. This commit fixes this by only taking into account the editable nodes. Steps to reproduce: - Go to a "To do" note - Add a few lines of text - Add a `/file` in the middle - Select all - Press Ctrl+B: bold is applied on the surrounding text - Press Ctrl+B again => Bold was not removed from the surrounding text task-5955977 Forward-Port-Of: odoo/odoo#249816
This fix improves how Odoo extracts embedded files from PDF documents. Previously, PDFs with a specific organizational structure (/Kids nodes) would not have their embedded attachments extracted, resulting in empty bills when uploading such PDFs to the accounting dashboard. The fix now supports both standard and hierarchical PDF file organization methods, ensuring all embedded content is properly detected and extracted.
Original PR description
Steps to reproduce: - From the accounting dashboard, upload a PDF containing intermediate /Kids nodes representing separate xml attachments Issue: No xml will be extracted, as result the bill will be empty. However, in the chatter pdf preview, the js pdf toolkit correctly show the xml attachemnts. Analysis: The PDF spec defines two ways to organize embedded files under /EmbeddedFiles in the document's name dictionary: - /Names: a flat array of pairs located directly under /EmbeddedFiles - /Kids: an array of child nodes, each of which carries its own /Names array. The extractor currently only handled the /Names case, not detecting embedded attachments in case of PDF using a /Kids tree. This change add lookup for both structures. opw-5929274 Forward-Port-Of: odoo/odoo#252523
This update prevents users from accidentally adding line breaks within section titles in quotation templates. When a quotation template is applied to a sales order, section titles will now remain as single-line text, ensuring consistent and professional formatting. Users who need multiple lines should create separate sections instead.
Original PR description
Steps to produce: --- - Install `Sales` module. - Go to `Sales > Configuration > Sales Orders > Quotation Templates`. - Create a new template and add a section. - In the section name, add text with…
Steps to produce: --- - Install `Sales` module. - Go to `Sales > Configuration > Sales Orders > Quotation Templates`. - Create a new template and add a section. - In the section name, add text with line breaks using `Shift + Enter`. - Go to sale orders > Create new SO > Set quotation template created above. Issue: --- - Line breaks entered in the quotation template section lines are stripped when the template is applied to a sale order. These intentional sections are meant to be single-line titles; users should create a new section instead of using line breaks within one. Root cause: --- - At [1], the `name` field is defined without the `section_and_note_text` widget. This widget is responsible for rendering section lines as a `CharField` instead of a `TextField`, as seen at [2]. Solution: --- - Add `widget="section_and_note_text"` to the `name` field. This ensures section lines consistently use `CharField`, preventing line breaks from being entered. [1]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/sale_management/views/sale_order_template_views.xml#L96 [2]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/account/static/src/components/section_and_note_fields_backend/section_and_note_fields_backend.js#L79-L86 opw-6034255 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a display problem in the website editor where product category previews were not showing correctly. The issue was caused by missing variable definitions that prevented proper styling from being applied. This ensures that when users preview different layout options in the editor, all visual elements display as intended.
Original PR description
The editor previews are not having the expected design due to the `c` and `p` variables being undefined. Steps to reproduce for eg. filmstrip: - Disable the `categories_opt_top` (Categories: top) - Hover the "Top" editor button - See the filmstrip is missing it's placeholder rectangle "text" due to the width style not being applied. task-6047816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where placeholder text in the editor was flickering when users updated content in other fields. The editor now only clears the placeholder hint when the cursor is actively inside the editor, preventing unnecessary blinking that distracted users during editing.
Original PR description
Problem: When the selection is updating, the hint is blinking in the editable. Cause: After 9df2662cc79c2d8277211f7ce0bdb389f783f933, `triggerDebouncedUpdateHints` clears the hint immediately and adds it back using a debounced version of `updateHints` which runs after a few seconds, thus causing this blink. Solution: We only update hint if the selection inside the editable. Steps to reproduce: - Create a new Todo. - Keep the editable empty. - Update the Todo title. - Observe the editable hint blinking. task-6025534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
23 changes
New functionality added to Odoo
This update adds support for multiple French fiscal declaration reports (2033-D, 2033-F, 2033-G, 2031, 2065 SD, and 2069-RCI) to the Odoo system. These reports are part of the "Liasse Fiscale" bundle required for French tax compliance, enabling businesses to generate and submit required tax documentation directly from Odoo.
Original PR description
- **[IMP] l10n_fr_reports: add 2033-D report** - **[IMP] l10n_fr_reports: 2033-F** - **[IMP] l10n_fr_reports: add 2033-G report** - **[IMP] l10n_fr_reports: 2031 tax income report** - **[IMP] l10n_fr_reports: add 2065 SD corporate tax return report** - **[IMP] l10n_fr_reports: add report 2069-RCI** - **[IMP] Fixup commit** - **[IMP] Fixup commit** Task ID: 5913160
This update enables users to share content directly to LinkedIn with higher quality images through LinkedIn's official API. Previously, shares were limited to small preview images. The change improves the social media sharing experience by allowing full-size image posts when users authorize the integration.
Original PR description
The linkedin API allows us to post on behalf of users if they authorize it. Notably this allows us to post large images instead of the tiny preview we get with opengraph. Additionally we move some of the linkedin API logic into a class to make it more easily reusable. task-5059124
Enhancements to existing features
The self-check-in QR code displayed on the frontdesk kiosk now includes the kiosk's selected language, ensuring visitors see the mobile check-in page in the correct language instead of always defaulting to English. This improvement enhances the user experience for international visitors and multi-language facilities.
Original PR description
Previously, the self-check-in QR code did not include the kiosk's selected language, so the mobile page always defaulted to English. Now, the kiosk language is included in the QR code URL, ensuring visitors see the mobile page in the intended language.
Documents now display clear, standardized messages showing who created them, where they came from, and other important details. This makes it easier for users to understand a document's origin and history without confusion or wasted time searching for information.
Original PR description
Currently, when documents are created, their chatter messages are inconsistent, lack important details, or simply do not exist. This creates confusion and wastes users' time when trying to trace a…
Currently, when documents are created, their chatter messages are inconsistent, lack important details, or simply do not exist. This creates confusion and wastes users' time when trying to trace a document's origin. To solve this problem and improve the user experience, this PR introduces a standardized chatter message format that cleanly captures all essential information. Displayed information: - Document Author - Original document name - Document source (e.g., user upload, email, PEPPOL, or an Odoo app) - Notes section (hidden if empty; used to display the related record when saving an attachment from the chatter) Implementation notes: - Hid redundant creation/tracking chatter messages. - Added a new message subtype (`mt_document_source`) to easily retrieve this information later. - These document messages will be used in future AI tasks, so they are posted even if tracking is disabled. However, a `no_documents_creation_message` context flag was added to forcefully disable them when needed.
The payroll dashboard has been improved to provide a cleaner user experience. The 'set schedule' wizard now automatically hides the working hours field when company working hours are already configured, and displays a more helpful placeholder text. Additionally, the schedule confirmation message is removed once the payroll schedule is set, reducing visual clutter and improving dashboard clarity.
Original PR description
Specifications ============== In 'set schedule' wizard: - If Working Hours is set on the company, hide the field - Change the place holder : "Default working hours used for this company" Remove the 'Monthly payrun is scheduled on xxx' line on top once the schedule is set. Task-6067733
Call settings like push-to-talk preferences and voice duration are now stored locally on each device instead of being shared across all your devices. This improvement allows each device to have its own customized call settings, which is more practical since different devices may have different keyboards and input methods.
Original PR description
Currently "use_push_to_talk", "push_to_talk_key", "voice_active_duration" settings are saved on server, which means they are shared among all devices of the user. Different devices are likely to use different input methods / keyboards, therefore these settings should be per device instead. This commit converts these server settings to localStorage. task-5992929 https://github.com/odoo/odoo/pull/255566
This update fixes a data caching issue in the system's core database layer that was affecting relationship fields (like one-to-many and many-to-many connections). The fix prevents stale or incorrect data from being reused, which improves system reliability across multiple modules including HR, planning, and point-of-sale operations. This ensures users always see accurate, up-to-date information.
This update enhances the Belgian payroll DIMONA declaration system with improved views and wizard functionality. The changes make it easier for HR teams to manage employee declarations and related data through a more intuitive interface and streamlined workflows.
Original PR description
Task: [6035146](https://www.odoo.com/odoo/project/1251/tasks/6035146)
This update strengthens the Odoo system by adding comprehensive tests across multiple modules to ensure tracking features work correctly and won't break with future changes. It also fixes several bugs including incorrect data display and missing validation checks. These improvements help maintain system stability and data accuracy across accounting, HR, and customer management features.
This update reorganizes how Belgian employee salary calculations work in the payroll system. The changes simplify the salary rules by using better categorization of different types of pay and deductions, making the system more flexible and easier to maintain. This also enables the ability to create separate payslips for different types of compensation (like commissions) while ensuring taxes and contributions are calculated correctly.
This update improves how tax declarations (281.10) are organized and shared with employees. Documents are now automatically organized into employee-specific Payroll folders, existing files can be overwritten through a confirmation dialog, and employees receive email notifications with document access links regardless of their user status. This makes the tax declaration process more organized and ensures all employees receive their documents.
Original PR description
Currently, when when a tax declaration (281.10) is generated and posted to Documents, the PDF is generated in the main Documents folder, and an email is only sent to the partner of the employee is the employee is a user. If the document already exists, the PDF posting logic skips that document. - Adds logic to create the employee folder in the Payroll folder if it doesn't already exist, and posts the PDF file into the folder. - Adds a wizard to open a dialog box display existing files and prompts the user to confirm whether they should be overwritten. If the user chooses to overwrite the files, the post logic is called again to overwrite the existing files. - Changes the declaration email template to match the payslip email template to send the employee an email with a link to access the document even as a non-user. Task: 5955050
This update enhances the Belgian payroll system to better validate employees' Joint Committee and Employer Category combinations. The improvement helps ensure payroll data accuracy by identifying and warning about incorrect category assignments, reducing potential compliance and payment processing errors.
Original PR description
Task: 5973879
The spreadsheet printing functionality has been enhanced with a dedicated printing wizard that was introduced in the o_spreadsheet library. This improvement allows us to remove the previous printing hook and related print assets, resulting in cleaner and more maintainable code. Users will benefit from a more streamlined and professional printing experience when working with spreadsheets.
Original PR description
A real printing wizard was introduced in o_spreadsheet, we can now remove the `useSpreadsheetPrint` hook in odoo as well as the print asset bundle. Task: [5891329](https://www.odoo.com/web#id=5891329&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
The data cleaning module now uses a single "Similarity Threshold" setting instead of two separate threshold fields, making it simpler to configure. This unified approach works the same way in both manual and automatic merge modes, reducing confusion and configuration complexity.
Original PR description
The data merge model had two separate threshold fields (merge_threshold and create_threshold) that are never used together. This change replaces them with a single field, "Similarity Threshold". Behavior: - Manual merge mode: duplicates with a similarity below the threshold are not suggested - Automatic merge mode: duplicates with a similarity above the threshold are merged automatically task-5892405
This update allows HR teams to filter job applicant offers by the specific benefits package (such as company car or charging station) after the offer is signed. Previously, this filtering capability was not available for applicant-based offers, making it difficult to manage onboarding for candidates with different benefit selections. Now when an offer is fully signed, the system automatically records which benefits package version was selected, enabling proper filtering and reporting.
Original PR description
**Version**: - master **Issue**: - For onboarding purposes, it is currently not possible to filter on the signed version for applicants. (e.g., offers with car, charging station, etc.). **Cause**: - employee_version_id is not set on applicant based offer after the offer is fully signed. **Fix**: - Recompute employee_version_id and set it on applicant based offers when it is fully signed. **Testing**: - Ensure offers still appear in recruitment as they originate from an applicant. - Ensure filtering by employee version works correctly with different benefit values. **Task-5322433**
The system now automatically tracks inventory for products sold through the Urban Piper online food delivery platform. When Urban Piper is enabled for a point of sale location, a dedicated inventory storage location is created to separately manage online orders from regular in-store sales, ensuring accurate stock levels across both channels.
Original PR description
Following this commit: - We will track the inventory for products that are sold online on urban piper side and in our pos sytem also. - As soon as urban piper is enabled for a config then a new `stock.location` is been created for that `pos.config`. - New stock.location is been set in pos.config under `Food Delivery Connector` section. We will track inventory for online order through `urbanpiper_stock_location_id` while normal orders will be tracked through location set in `Inventory` section in pos.config. task-4896303
Resolved issues and error corrections
This fix resolves an error that occurred when HR users opened the employee kanban view. The update adjusts access permissions for the first contract date field to ensure it displays correctly for payroll users, with added tests to prevent future issues.
Original PR description
Description of the issue/feature this PR addresses: . Fix traceback when user with group_hr_user rights open employees kanban-view Current behavior before PR: Desired behavior after PR is merged: . Update first_contract_date access group . Verify that first_contract_date is visible for hr_payroll_user group . Add corresponding tests task-6030294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where XML files were not being generated for quarterly tax returns in the Italian localization module. The problem was caused by incorrect date logic that used the start date instead of the end date for quarterly period detection. The fix ensures that quarterly tax returns can now be properly exported to XML format, and also improves data accuracy by simplifying the calculation method to avoid duplicate carryover amounts.
Original PR description
## Issue: When the tax return periodicity is set to quarterly and the return is validated, the XML file is not generated and downloaded ## Cause: The quarter detection logic was based on the `date_from` field of the return However, for quarterly returns, the correct reference should be `date_to` Using `date_to` also works correctly for monthly returns ## Steps to reproduce: - Install `l10n_it_xml_export` - Switch to the IT Company - Go in the Tax Report (Monthly VAT Report (IT)) to do a Tax Return (Opening Date: 01/01/2025, Periodicity: Quarterly) - If needed change the Tax Return Periodicity in Settings to Quaterly - Select the first report and ignore the error in Review Before the fix, it is only possible to close the return without generating the XML export opw-5707544 Forward-Port-Of: odoo/enterprise#112399 Forward-Port-Of: odoo/enterprise#108548
This update fixes how decimal separators are displayed in financial report pop-ups to match each user's language settings. Previously, the system always used a period (.) regardless of the user's locale, which could cause confusion for users in regions that use commas or other decimal separators. Now the decimal separator will automatically adjust based on the user's language preference.
Original PR description
Description of the issue this commit addresses: The external value pop up doesn't take into account the locale to chose which decimal separator to use. --- Desired behavior after this commit is merged: The decimal separator is the one determined by the language of the user rather than always a dot. --- task-6010533 Forward-Port-Of: odoo/enterprise#112212 Forward-Port-Of: odoo/enterprise#109948
The placeholder text for the NISS field in the Belgian salary configurator was showing an invalid example format that would actually trigger an error. This fix updates the placeholder to display the correct format (xx.xx.xx-xxx.xx) so users understand what input is expected, improving the user experience and reducing confusion.
Original PR description
As of now, the placeholder text for the NISS field on the salary configurator is "00.00.00-000.00 or / for no NISS" but 00.00.00-000.00 is actually not recognized and shows the error that says to put a valid NISS. For this reason, we modify the placeholder to instead show "Input your NISS in the format xx.xx.xx-xxx.xx or / for no NISS". Task: 6067653
This update fixes unreliable automated tests in the Point of Sale system by making test triggers more precise. The change ensures that tests run consistently and reliably, reducing false failures and improving the quality of our testing process.
Original PR description
Fix undeterministic tours by making some triggers more precise in a few steps.
Code cleanup and technical improvements
This update removes an outdated payslip tags feature from the HR Payroll documents module that is no longer needed due to workflow changes. The removal simplifies the settings interface and reduces unnecessary configuration options for users managing payroll documents.
Original PR description
According to the linked task, this is not needed anymore since the workings changed. We can fully remove the override since it's the only thing it's adding Task: 5936989
The web push notification code in the mail system has been streamlined by removing unnecessary utility methods and improving documentation. This cleanup aligns the enterprise version with improvements made in the community version, making the codebase more maintainable without affecting user-facing functionality.
6 changes
Enhancements to existing features
This update adds missing tax exemption reasons to the electronic invoicing system to ensure full compliance with Peppol standards. The change enables businesses to properly document all types of tax exemptions when creating electronic invoices, improving accuracy and regulatory compliance in cross-border transactions.
Original PR description
Some tax exemption reasons were missing, This commit ensures having all the tax exemption reasons introduced by Peppol task-6048561 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The system now allows companies to register PEPPOL numbers from any country, not just those on a predefined list. This removes geographic restrictions and makes the invoicing system more flexible for businesses operating internationally or with international partners.
Original PR description
Before this commit, only numbers on the peppol list were able to be registered. Now is possible to add numbers from other countries. Task-6033336 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This improvement makes product matching during imports more accurate and flexible. Products are now matched regardless of uppercase/lowercase differences (e.g., "Network Cable" matches "network cable"), and the system uses intelligent similarity matching instead of simple substring search to avoid incorrectly pairing unrelated products. This results in fewer import errors and better data accuracy when bringing in product information.
Original PR description
Before this commit: - Product retrieval during import relied on exact name match and substring (ilike) search. - Exact name search was case sensitive, so values like `Network Cable` would not match…
Before this commit: - Product retrieval during import relied on exact name match and substring (ilike) search. - Exact name search was case sensitive, so values like `Network Cable` would not match `Network cable`. - Substring matching could return unrelated products (e.g. `Wireless bluetooth speaker` gets matched with `Wireless bluetooth speaker battery`), leading to unrelated matches. After this commit: - Exact name search is now case insensitive, allowing matches such as `Network Cable` and `network cable`. - Substring based matching has been replaced with a similarity ratio (90%) to reduce false positives and improve matching reliability against customer database product names. Technical: - Replaced `=` with `=ilike` in the exact name search domain to make the lookup case insensitive. - Similarity ratio is computed using Python's `difflib.SequenceMatcher` on product names, with a minimum threshold of 90% to qualify as a match. - Added system parameter for configurable product name similarity threshold. task-5951469
Resolved issues and error corrections
This fix enables the amount-in-words feature to work correctly in Czech. The underlying library had a bug using the wrong language code, which has been corrected through a temporary workaround. This ensures Czech users can now see amounts displayed as written words in their documents and reports.
Original PR description
The `num2words` library has a bug in the language code they used for Czech (`cz` instead of `cs`). This commit adds a monkey patch to map the correct language code to the existing converter class, allowing the amount in words to work in Czech. The issue was fixed in version 0.5.14 of the library, so this patch can be removed once we use Ubuntu >= 25.10 (Python >= 3.13), that contains the fixed version of the library. [opw-6088697](https://www.odoo.com/odoo/project.task/6088697)
Odoo was incorrectly generating separate tax blocks for multiple taxes with the same rate on invoices, causing Peppol validation to fail. This fix consolidates all taxes of the same rate into a single block, ensuring invoices comply with Peppol standards and are accepted by tax authorities.
Original PR description
Peppol invoices are rejected with error `[BR-S-08]` when multiple taxes with the same rate (e.g. 21%) are used on the same invoice. Odoo generates separate `<cac:TaxSubtotal>`` blocks for them due to…
Peppol invoices are rejected with error `[BR-S-08]` when multiple taxes with the same rate (e.g. 21%) are used on the same invoice. Odoo generates separate `<cac:TaxSubtotal>`` blocks for them due to technical differences (like `include_base_amount`), but the standard requires a single consolidated block per rate. Simplify the grouping key used during UBL export by removing `include_base_amount`. This forces all taxes of the same category and rate to be merged into a single subtotal block, ensuring mathematical consistency and satisfying Peppol validation rules. Peppol error: ``` The XML document did not pass the Schematron validation. Schematron Validation failed with error: Fatal: [BR-S-08]-For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is "Standard rated", the VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall equal the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-95) is "Standard rated" and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category rate (BT-119). ``` opw-5891685
This fix corrects how the system calculates paid time off balances when employees request leave retroactively (for dates in the past). Previously, backdated leave requests would incorrectly reduce the current year's balance even when the leave should have been covered by surplus days from the previous year. The fix recalculates balances properly by replaying the accrual history when a backdated leave crosses a year boundary.
Original PR description
Steps to reproduce 1. Create a multi-level accrual plan (e.g., Level 1: 2 days/month, 5-day carryover cap). 2. Accrue for a full year (24 days earned) and pass the carryover date (Jan 1st). 3.…
Steps to reproduce 1. Create a multi-level accrual plan (e.g., Level 1: 2 days/month, 5-day carryover cap). 2. Accrue for a full year (24 days earned) and pass the carryover date (Jan 1st). 3. Observe the balance for the new year is 8.0 (5.0 carried over + 3.0 new grant). 4. Backdate a leave request to November of the previous year (12 days) and validate it. 5. Observe the remaining balance for the current year. 6. Result: The balance drops incorrectly. It fails to recognize that the 12-day leave should have been absorbed by the 19 surplus days (24 earned - 5 cap) discarded during the reset. Issue When a leave is backdated into a previous accrual period (before the most recent carryover), the system uses the current post-carryover allocation balance to evaluate and deduct the leave. It does not account for the fact that the previous period may have had a much higher balance, and that the leave's real impact is only on the carried-over amount — not the full duration. Solution When a backdated leave crossing a carryover boundary is detected, the accrual plan is replayed from scratch to recompute the correct allocation balance. 1. Detection (_get_accrual_allocations_across_carryover in hr.leave): Checks whether a leave's date falls before a carryover boundary that has already been processed (leave.date_from < carryover_date <= alloc.lastcall). This ensures the recompute only triggers for truly backdated leaves crossing a carryover. 2. Replay (_recompute_accrual_allocations in hr.leave.allocation): Creates a temporary allocation and replays _process_accrual_plans from the allocation's start date up to lastcall. The replay uses include_pending_leaves context to count not-yet-validated leaves via virtual_leaves_taken, so the carryover calculation correctly accounts for them at create time. 3. Lifecycle coverage: The recompute is triggered on all leave state changes that affect the allocation balance: create (_check_validity), refuse (action_refuse), delete (unlink), and reset to draft (action_draft). 4. The normal accrual cron (_update_accrual / _process_accrual_plans) continues to use leaves_taken (validated only), preserving existing behavior for forward-looking accrual processing. opw-5870858