Daily updates from Odoo
Navigate
Branch
Wednesday, September 24, 2025
211 changes
6 changes
Resolved issues and error corrections
Fixed an issue that could block sending certain Colombian electronic invoices when a debit note reference was missing. This prevents users from hitting an error during invoice email submission and improves reliability for Colombian localization workflows.
Original PR description
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** -…
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** - Install Accounting and l10n_co_dian modules. - Switch company to "CO Company". - Create new customer invoice. (e.g; Operation Type (CO) = Nota Débito que referencia una factura electrónica) - Click on "Send" button. Ensure DIAN is selected in template and then send it. - Error occurs. **Error:** AttributeError - 'bool' object has no attribute 'isoformat' **Cause:** The issue happens because debit_origin_id is not set, which makes reference_invoice equal to None, leading to an error. - [1] In pervious versions, the operation type could not be modified because it was read-only field. From saas-18.4, it became a stored field. Therefore, without debit note, the operation type cannot be changed directly. In this case, the condition at [2] fails, and the method returns None. **Fix:** This commit ensures that a value is only returned if a reference invoice exists; otherwise, it returns None. [1] - https://github.com/odoo/enterprise/blob/8c0217e4e38903783ab7d70ca3eec1c1e3de03de/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L730 [2] - https://github.com/odoo/enterprise/blob/b67a58ffd70952a06b7dd56a54782c433ff673fb/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1495-L1496 sentry-6810908763
Users applying unsupported filters to image or other binary fields will no longer encounter an unexpected error. The system now records the issue as a warning instead, helping keep filtering workflows stable while still flagging the invalid condition for follow-up.
Original PR description
Currently, an error occurs when user tries to apply an invalid filter on any binary field.
Steps to replicate:
- Add a filter like [('image_1024', 'in', [])] in the custom filter where the image exists(eg, Products) and save.
- Error triggered.
Error:
`ValueError: Binary field stored in attachment, accepts only existence check; skipping domain in condition ('image_1024', 'in', OrderedSet(['']))`
Cause:
- The system encountered an error when users attempted to apply invalid filters on binary fields (e.g., image_1024). The error occurs when operators like 'is in' with empty string values ('') are used, as binary fields are stored as attachments only support existence checks.
Solution:
- Changed the `_logger.exception` to `_logger.warning`.
sentry-6236134077
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFleet manufacturer pages now count only active vehicle models, so totals better reflect the models currently in use. Users can also filter vehicle models to find archived records when needed, improving record visibility without affecting daily workflows.
Original PR description
- Fixed count of models in manufacturer to count only active models. - Added 'Archived' search filter for 'model' model Task - 4921998 Forward-Port-Of: odoo/odoo#228174 Forward-Port-Of: odoo/odoo#222353
This update fixes a failing automated test for Hong Kong payroll accounting related to leave generation changes. It helps keep payroll file validation stable and reduces the risk of blocked releases due to test failures.
Original PR description
Explanation: _generate_leave method is updated in saas-18.1. build_error-229902 Forward-Port-Of: odoo/enterprise#95084
The follow-up report no longer crashes when users load more entries for customers with many invoices. This helps accounting teams reliably review customer payment follow-ups without interruption.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. For partner X, create minimum 90 invoices for `See more/Load more` option into page. 3. In the partner form view, click the Customer…
**Steps to reproduce:**
1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.
**NOTE**
- You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
invoice = env['account.move'].create({
'move_type': 'out_invoice',
'partner_id': 10,
'company_id': env.company.id,
'invoice_line_ids': [(0, 0, {
'product_id': 16,
'quantity': 1,
'price_unit': 100.0,
})],
})
invoice.action_post()
```
**Issue:**
`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.
**Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73
- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />
- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />
**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.
**opw - 5083894**
Forward-Port-Of: odoo/enterprise#95103This update refreshes the spreadsheet component and fixes an issue when sorting certain array formulas. Users should see more reliable spreadsheet behavior when working with formulas and sorted data.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0c9130545 [REL] 18.4.12 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e9cb9e1b9 [FIX] Sort: Allow to sort array formula that do not spread [Task: 5033192](https://www.odoo.com/odoo/2328/tasks/5033192) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
15 changes
Resolved issues and error corrections
Vehicle manufacturers now show counts based only on active vehicle models, preventing archived models from inflating totals. Users can also filter archived vehicle models more easily, making fleet data clearer and easier to manage.
Original PR description
- Fixed count of models in manufacturer to count only active models. - Added 'Archived' search filter for 'model' model Task - 4921998 Forward-Port-Of: odoo/odoo#228174 Forward-Port-Of: odoo/odoo#222353
A payroll accounting test for Hong Kong was updated to match a recent change in how employee leave is generated. This helps keep automated quality checks passing and reduces the risk of delays when validating payroll-related updates.
Original PR description
Explanation: _generate_leave method is updated in saas-18.1. build_error-229902 Forward-Port-Of: odoo/enterprise#95084
Fixed an issue in Accounting reports where the Follow-Up Report could crash when users loaded additional invoice lines for customers with many invoices. This ensures users can review large follow-up reports without interruption.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. For partner X, create minimum 90 invoices for `See more/Load more` option into page. 3. In the partner form view, click the Customer…
**Steps to reproduce:**
1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.
**NOTE**
- You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
invoice = env['account.move'].create({
'move_type': 'out_invoice',
'partner_id': 10,
'company_id': env.company.id,
'invoice_line_ids': [(0, 0, {
'product_id': 16,
'quantity': 1,
'price_unit': 100.0,
})],
})
invoice.action_post()
```
**Issue:**
`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.
**Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73
- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />
- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />
**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.
**opw - 5083894**
Forward-Port-Of: odoo/enterprise#95103The spreadsheet component was updated to the latest version for this Odoo release. This fixes an issue where sorting could fail for certain array formulas, helping users work more reliably with spreadsheet data.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/fb227d71f [REL] 18.3.22 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/220054c18 [FIX] Sort: Allow to sort array formula that do not spread [Task: 5033192](https://www.odoo.com/odoo/2328/tasks/5033192) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
The product category sidebar now displays nested categories with proper alignment. This prevents awkward spacing or height changes in the shop navigation, giving customers a cleaner browsing experience.
Original PR description
__Issue:__ The nested `<li>` in product categories had a width greater than its parent `<ul>`, causing the parent to expand in height before the child. __Fix:__ Increased the negative margin on the parent container from `ms-n2` → `ms-n5` to align the widths. This fixes the visual layout now that the product aside column is flexible `col` instead of fixed `col-3`. - opw-5075226
Fixes an issue where changing the address of a Czech company with demo data could fail with a validation error. Demo accounting entries now use consistent dates, preventing sequence conflicts and allowing company details to be saved normally.
Original PR description
## [FIX] l10n_cz: prevent error with misaligned accounting date and sequence number of demo moves #### Description of the issue/feature this PR addresses: Editing CZ Company address while having demo…
## [FIX] l10n_cz: prevent error with misaligned accounting date and sequence number of demo moves #### Description of the issue/feature this PR addresses: Editing CZ Company address while having demo data throws Validation Error #### Current behavior before PR: When trying to change address of CZ Company while l10n_cz with demo data is present an error popup is displayed and it's not possible to to save the changes. Steps to reproduce: - Install l10n_cz with demo data - Open CZ Company in form view - Change address (e.g. change city Praha -> Brno) - Click Save #### Desired behavior after PR is merged: The address changes are saved without any error. #### Solution: This change adds `taxable_supply_date` date values for CZ demo moves that are compatible with `invoice_date` values to make sure that accounting date values are the same on each recomputatation and do not lead to new sequence numbers that are not aligned with the previous ones which would cause errors being raised by sequence mixin. Related to: #226152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227847
Customers using in-store pickup will now have the default pickup location properly saved at checkout, even if they did not choose it before adding an item to the cart. This prevents a confusing checkout error that blocked customers from continuing to payment when the page appeared to show a valid pickup location.
Original PR description
Description of the issue/feature this PR addresses: This commit fixes the issue where the pickup location does not get set even though it is present on the checkout page. This happens when the user…
Description of the issue/feature this PR addresses: This commit fixes the issue where the pickup location does not get set even though it is present on the checkout page. This happens when the user directly adds an item to cart without specifying the pick up location before adding to cart. This results in the location not being set but at the checkout page, the default pick up location appears as one of the warehouses given the way the default pickup location is set when loading the checkout page values. This makes the user think that the pickup location is set, but when they try to go to the pay page, an error is thrown saying the pick up location was not specified. This commit sets the pickup location data in such a case. [This commit] refactored the way in which the default location would be set on the checkout page but did not take into account the possbility that the customer might not select the pickup location when they are adding to cart, thus only rendering the value at the checkout page but not actually setting it. Refactored the test cases to avoid the redundancy in the setup process. Steps to reproduce on runbot: 1. Set the pick up in store as the default delivery method by updating the sequence 2. Go the shop on the website and add any item to cart which has stock in the specified pickup location, but don't select the pickup location here 3. Go to the cart and click checkout 4. The default pickup location will be set here 5. Click on Confirm 6. An error will appear saying the location was not set opw-4954187 [This commit]: https://github.com/odoo/odoo/commit/1d3942c75e59ac9538d112df43b4e39f2462fee4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Public holiday timesheets now reflect an employee’s flexible working schedule instead of defaulting to the company’s standard 8-hour day. This prevents incorrect time-off entries for employees whose average daily hours differ from the company default.
Original PR description
## Issue: For employees with flexible working hours, when a Public Holiday is added, the timesheet was filled with 8h based on the company’s default calendar instead of the employee’s flexible…
## Issue: For employees with flexible working hours, when a Public Holiday is added, the timesheet was filled with 8h based on the company’s default calendar instead of the employee’s flexible schedule ## Cause: When creating `resource.calendar.leaves`, timesheets call `_work_time_per_day()` This method uses `work_hours_data` containing half-day intervals (tmp_start/tmp_end) These data come from `_attendance_intervals_batch()`, but we were passing an empty resource, so the check for `flexible_hours` failed: https://github.com/odoo/odoo/blob/bd7d5fdf8df3a4d544de3e2493cd4b3966fa7d0b/addons/resource/models/resource_calendar.py#L382-L393 We want to use the calendar itself as the calendar resource to get the `work_hours_data` ## Steps to reproduce: - On an employee, in Work Information, set the Working Hours to Flexible 40 hours/week - Modify Flexible 40 hours/week (Hours per Week: 30, Average Hour per Day: 6) - In Time Off > Configuration > Public Holidays, add a New holiday (You can leave default values) - Go in Timesheets > All Timesheets, before the fix, the flexible employee have 8h in internal for Time Off opw-4881758 Forward-Port-Of: odoo/odoo#225876
Merging timesheet entries from the same helpdesk ticket now keeps them connected to that ticket. This prevents lost ticket history and blocks merges when selected timesheets belong to different helpdesk tickets.
Original PR description
…helpdesk ticket **Steps to reproduce** - Register 2 timesheet lines on 1 helpdesk ticket - Go to the timesheets app and select these 2 lines - Go to Actions -> Merge timesheets Issue: the timesheets are merged but unlinked from the helpdesk ticket. **Change** Preserve the link to the helpdesk ticket when merging timesheets. An error is raised if attempting to merge timesheets not having all the same `helpdesk_ticket_id` value. opw-5086090 Forward-Port-Of: odoo/enterprise#94780
This update fixes an internal automated test for journal reports that could fail when Czech localization was installed. It makes the test validate the actual payment reference value instead of assuming it is blank, helping keep builds stable across localized setups.
Original PR description
test_document_data_for_bank_journal_with_show_payment_option was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which is a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479 Forward-Port-Of: odoo/enterprise#95014
Swiss ISO20022 payment files generated for vendor payments have been corrected to match current Swiss bank validation requirements. This helps companies using Swiss bank batch payments avoid rejected payment files and related payment delays.
Original PR description
Since July, the iso20022 payment method is to not be accepted by some Swiss banks anymore. How to reproduce? Install account_iso20022 and enable batch payments in the accounting settings. Configure your journal adding the payment method "Swiss ISO20022" in the outgoing payments and setting the XML format as "pain.001.001.09". Pay a vendor bill using the "Swiss ISO20022" payment method. Go to the journal payment, select the previous payment and create a batch. On the batch payment, you can find the XML file which is not validated by Swiss banks. test validation on: https://ubs-paymentstandards.ch/login opw-4976852 opw-4675667 opw-4996910 opw-4895258 opw-5006895 task-id: 5000729 Forward-Port-Of: odoo/enterprise#94940 Forward-Port-Of: odoo/enterprise#92532
Italian vendor invoice XML imports now keep the correct TD01 document type instead of being changed to TD05. This helps businesses using Italian e-invoicing avoid incorrect invoice classification and related accounting or compliance confusion.
Original PR description
**Issue** When importing an XML invoice of document type TD01, it is incorrectly assigned type TD05 after processing. **Steps to Reproduce** 1. Install Accounting, l10n_it and l10n_it_edi 2. Go to…
**Issue**
When importing an XML invoice of document type TD01, it is incorrectly assigned type TD05 after processing.
**Steps to Reproduce**
1. Install Accounting, l10n_it and l10n_it_edi
2. Go to Accounting > Vendors > Vendor Bills
3. Upload an XML invoice with TD01 as the document type
4. Upon confirming the bill, observe that the document type is incorrectly set to TD05
**Root Cause**
The document type matching logic fails to assign TD01 because the uploaded invoice has move_type = in_invoice, while TD01 was only configured to match out_invoice. https://github.com/odoo-dev/odoo/blob/7436e8cee2f605c6d5d559cb410e7a3dc8f372b9/addons/l10n_it_edi/models/account_move.py#L886-L891
**Fix**
According to Italian e-invoicing specifications, TD01 applies to both sales and purchase invoices ("Fatture di vendita" and "Fatture d’acquisto"). To reflect this, in_invoice is now added to the list of supported move_types for TD01, allowing correct detection during XML import.
opw-4931438
Forward-Port-Of: odoo/odoo#219310Users can now enter a checkout time directly in the Attendance Gantt popup for open attendances. This fixes a visibility issue that previously blocked manual checkout entry, making attendance corrections faster and less confusing.
Original PR description
The Gantt popup form explicitly set `check_out` invisible when it was empty, which prevented users from manually entering a checkout for an open attendance. This commit removes the overriding xpath so that the form simply inherits the standard `hr_attendance_view_form` behavior, where the `check_out` field is always visible and editable. Users can now set a manual checkout directly from the Gantt modal. task-5026978 Forward-Port-Of: odoo/enterprise#92726
This fix passes the action identifier into the web view setup so Odoo Studio can correctly tell whether an action is editable. It helps prevent incorrect editing options from appearing or being unavailable in Studio.
Original PR description
This information is required so that the studio can determine whether the action can be edited. opw-5066488
This fixes an issue where users could not add custom fields from the optional columns menu in Knowledge article lists. The change ensures Studio correctly recognizes whether the current action can be edited, restoring the expected customization workflow.
Original PR description
Steps to reproduce ================== - Install knowledge, web_studio - Go to knowledge > Articles - Click on the optional columns dropdown - Click on "Add Custom Field" => This action is not editable by Studio Cause of the issue ================== Since https://github.com/odoo/odoo/pull/205129/commits/c18e93191c516f6e37093f068e8934cba8495891 the event ACTION_MANAGER:UI-UPDATED is triggered before the list renderer has a chance to register for it. Solution ======== We don't actually need to listen to that event to get the info we need. The action xml_id was missing, but it was added in the view subenv config. opw-5066488
8 changes
Resolved issues and error corrections
The Accounting reports follow-up view has been corrected so users can load additional invoice lines without hitting an error. This prevents interruptions for teams reviewing customer statements or follow-up reports with many invoices.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. For partner X, create minimum 90 invoices for `See more/Load more` option into page. 3. In the partner form view, click the Customer…
**Steps to reproduce:**
1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.
**NOTE**
- You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
invoice = env['account.move'].create({
'move_type': 'out_invoice',
'partner_id': 10,
'company_id': env.company.id,
'invoice_line_ids': [(0, 0, {
'product_id': 16,
'quantity': 1,
'price_unit': 100.0,
})],
})
invoice.action_post()
```
**Issue:**
`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.
**Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73
- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />
- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />
**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.
**opw - 5083894**
Forward-Port-Of: odoo/enterprise#95103Merging timesheet entries from the same helpdesk ticket now keeps them connected to that ticket. The system also prevents merging entries tied to different tickets, helping avoid lost ticket history and reporting errors.
Original PR description
…helpdesk ticket **Steps to reproduce** - Register 2 timesheet lines on 1 helpdesk ticket - Go to the timesheets app and select these 2 lines - Go to Actions -> Merge timesheets Issue: the timesheets are merged but unlinked from the helpdesk ticket. **Change** Preserve the link to the helpdesk ticket when merging timesheets. An error is raised if attempting to merge timesheets not having all the same `helpdesk_ticket_id` value. opw-5086090 Forward-Port-Of: odoo/enterprise#94780
This change updates a journal report test so it no longer depends on a payment reference staying empty in all country configurations. It helps keep automated builds reliable when Czech localization is installed, reducing false test failures without changing user-facing accounting behavior.
Original PR description
test_document_data_for_bank_journal_with_show_payment_option was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which is a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479 Forward-Port-Of: odoo/enterprise#95014
Users can now enter a checkout time directly from the Attendance Gantt popup when an attendance is still open. This fixes a visibility issue that blocked manual corrections and helps managers complete attendance records without leaving the Gantt view.
Original PR description
The Gantt popup form explicitly set `check_out` invisible when it was empty, which prevented users from manually entering a checkout for an open attendance. This commit removes the overriding xpath so that the form simply inherits the standard `hr_attendance_view_form` behavior, where the `check_out` field is always visible and editable. Users can now set a manual checkout directly from the Gantt modal. task-5026978 Forward-Port-Of: odoo/enterprise#92726
Purchase bills that are moved back to Draft now return to a clean GSTR-2B reconciliation state. This prevents old return-period links or exception flags from carrying over, helping teams reconcile GST data accurately when bills are corrected.
Original PR description
When a purchase invoice (bill) is reset to Draft: - Reset GSTR-2B reconciliation status to "pending" - Unlink from GST return period - Clear any existing exceptions This ensures that the bill returns to its initial stage for proper reconciliation. Task ID: 5095582 Forward-Port-Of: odoo/enterprise#95161 Forward-Port-Of: odoo/enterprise#95026
Chilean electronic delivery guide XML now reports the actual quantity delivered instead of the originally requested quantity. This prevents customers and authorities from seeing overstated quantities when only part of an order is delivered.
Original PR description
**Issue** When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered…
**Issue** When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered quantity (quantity). This results in an incorrect quantity being displayed in the DTE. **Steps to Reproduce** 1. Install the Accounting module, Chilean localization, Sales module, and l10n_cl_edi_stock. 2. Create and confirm a new Sale Order. 3. Click on the Delivery smart button. 4. Adjust the delivered quantity to a value lower than the demand, save, and validate with no backorder. 5. Generate the Delivery Guide. 6. Open the generated DTE XML and observe that the quantity is incorrect. **Root Cause** The quantity displayed in the DTE is taken from product_uom_qty, which represents the planned quantity to be moved, not the actual delivered quantity. The correct field to use is quantity, which reflects the real delivered amount. **Fix** Change the XML output to use quantity instead of product_uom_qty to accurately reflect the actual delivered quantity in the DTE. Opw-4892276 Forward-Port-Of: odoo/enterprise#89633
Chilean electronic invoice imports now correctly treat lines marked with exemption code 6 as negative amounts. This prevents vendor bills from being imported with overstated positive values, improving accounting accuracy for Chilean companies.
Original PR description
### Issue: When, in a DTE file, a line has the code 6 in `IndExe`. The amount of the line is supposed to be negative. (See the [doc](https://www.sii.cl/factura_electronica/formato_dte.pdf) page 31/32) ### Steps to reproduce: - Install 'l10n_cl_edi' and switrch to a Chilean company - Have a DTE file with a line having '6' in `IndExe`: - In Accounting > Vendor > Bills, click the button "Upload" and select the DTE file - The imported move has positive values on the every lines ### Cause: The values of `IndExe` are not considered. ### Solution: Add a condition changing the sign of `price_unit` when 6 is in `IndExe` opw-4954723 Forward-Port-Of: odoo/enterprise#93393
Shiprocket Cash on Delivery orders now include coupon-based discounts when sending shipment details. This prevents overreported COD amounts and keeps Shiprocket totals aligned with what the customer actually owes, including tax-aware discount handling.
Original PR description
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian…
Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.
Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
- Sale price: 1000 INR
- Weight: 100g
- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
- Payment Method: COD
- Set some "Shiprocket Channel"
- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
- Name: 50% off
- Program Type: Coupons
- Change the existing reward to 50% discount on order
- Generate some coupon
- Copy the code of the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
- Shiprocket COD
- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log
--> total_discount is 0
Cause
-----
The problem comes from
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301
There are 2 issues here.
The first and most important one is how we find the discount lines.
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320
Discounts from coupons don't use the `sale_discount_product_id`. We can use the `_can_be_invoiced_alone` function to find both regular and loyalty discounts
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale/models/sale_order_line.py#L1033-L1041
def _can_be_invoiced_alone(self):
""" Whether a given line is meaningful to invoice alone.
It is generally meaningless/confusing or even wrong to invoice some specific SOlines
(delivery, discounts, rewards, ...) without others, unless they are the only left to invoice
in the SO.
"""
self.ensure_one()
return self.product_id.id != self.company_id.sale_discount_product_id.id
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale_loyalty/models/sale_order_line.py#L50-L51
def _can_be_invoiced_alone(self):
return super()._can_be_invoiced_alone() and not self.is_reward_line
We just have to be careful not to accidentally include delivery fees because of
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/delivery/models/sale_order_line.py#L18-L19
def _can_be_invoiced_alone(self):
return super()._can_be_invoiced_alone() and not self.is_delivery
The second issue is that we use the untaxed discount amount.
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321
This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).
-----
Community PR:
https://github.com/odoo/odoo/pull/223517
Ticket:
opw-4755357
Forward-Port-Of: odoo/enterprise#94798
Forward-Port-Of: odoo/enterprise#923101 change
Resolved issues and error corrections
Changing a website theme color and saving immediately no longer triggers an error screen. This makes website customization more reliable, including when debug mode is enabled.
Original PR description
Previously, a traceback occurred when changing the theme color from the color palette and pressing the save button immediately. This PR resolves the issue by adding catch block to handle promise rejections and ensured the correct jquery context is used within the iframe. task-3919146
24 changes
New functionality added to Odoo
Adds a new India reporting module for the ITC-04 Job Work Report. Users can review and export the required job work sections individually or together in the government Excel format, helping with compliance reporting.
Original PR description
This PR adds new module for presenting ITC-04 Job Work Report . It has four sections. - Form 4: Details of goods sent for job work - Form 5A: Details of goods returned by the job worker they were sent to for processing. - Form 5B: Details of goods returned by a different job worker they were sent to for processing. - Form 5C: Details of goods sent to a job worker and later supplied from their premises. It allows user to view and export Table 4, 5A, 5B and 5C individually / altogether into excel as per government stated format. Task ID: 3640321
Enhancements to existing features
Salary offers now record the selected vehicle name, such as a car, ordered car, or bike, in the offer discussion history after signing. This makes it easier for HR teams to review and correct vehicle choices if an employee re-signs using the same offer link.
Original PR description
Purpose ======= After signing a contract in salary config and you chose a car, we'd like it to appear in the chatter of the offer. If the user made a wrong choice and resign with the same link, it'll be useful to track changes Spec ==== Add a field on nenefit model: 'related_offer_field_id' that will be used to set additonal info regarding a benefit, notably the name of the chosen vehicles: car, new car, bike. Task-4962922
The work entries planning view now makes duration differences easier to spot by showing duration values when they differ from expectations. Row totals are displayed directly in the schedule, using normal styling when they match expected time and warning styling when they do not.
Original PR description
Display duration if it's not the expected value Display the row duration sum in column and black if it's the expected value, or in warning task-5068597 Forward-Port-Of: odoo/enterprise#94454
The payroll pay run employee list is clearer and easier to use. Employees are now sorted by name, the list has a more descriptive label, and pay schedule information is shown to help payroll teams choose the right employees faster.
Original PR description
Changed name of the list, sorted it by employee name, and added pay schedule field. task-5067639
Users can now archive return types in accounting reports instead of keeping all records active. This helps businesses keep operational lists cleaner while preserving historical setup information when return types are no longer used.
Automatic reconciliation model names now use the account's display name directly, without adding extra numbers. This keeps generated names clearer for accounting users now that duplicate names are allowed.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/9cdc519a7aa7e40cad31d2eb6dcc8858df831e9b we change the way the reco model name were made by going back to just the display name of the account. For prior version 19.0, a unique constraint on the name was there so we added a number after the name of the account to avoid duplicate. The constraint has been removed and so this code is no longer needed. no task id Forward-Port-Of: odoo/enterprise#95130
Resolved issues and error corrections
The point of sale test setup now avoids relying on a fixed calendar year when selecting invoices to settle. This makes automated checks more reliable over time and reduces false test failures without changing day-to-day user behavior.
Original PR description
Remove hardcoded year date for selecting invoices to settle. rb-error: 230713 community PR: https://github.com/odoo/odoo/pull/224171 Forward-Port-Of: odoo/enterprise#93166
This fix prevents online bank synchronization from sending a payment reference field when the related optional accounting module is not installed. It helps avoid failed transaction creation for customers using Odoofin without that extra module.
Original PR description
Odoofin always give the 'end_to_end_uuid' info. But it's a field that is only defined in account_iso20022. So we should not give this field in the create if the module is not installed. Forward-Port-Of: odoo/enterprise#95321
A journal report test was adjusted so it works consistently across different localization setups, including Czech accounting rules. This reduces false build failures and helps keep accounting report updates moving smoothly.
Original PR description
test_document_data_for_bank_journal_with_show_payment_option was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which is a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479 Forward-Port-Of: odoo/enterprise#95014
Refreshing appointment time slots could fail when no resource was selected, preventing capacity from being calculated correctly. This fix handles empty selections safely so users can continue browsing and booking available appointment slots without errors.
Original PR description
When refreshing the slots, it's possible that the resource_selected_id is equal to None, False or just empty string. This was leading to some error when parsing it to an integer. This commit move the parsing into the method computing the max possible capacity after checking if we got a value. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5102895 Forward-Port-Of: odoo/enterprise#95144
The Belgian payroll Dimona module now prevents direct editing of the student status on employee records when that value comes from the employee version record. This avoids inconsistent HR data and reduces the chance of payroll or reporting errors.
Original PR description
This commit marks `l10n_be_is_student` field as readonly in `hr.employee` model since it is a related field of `hr.version` and it is not editable in `hr.version` and so there is no reason to make in editable in employee model. runbot-error-231303 Forward-Port-Of: odoo/enterprise#95208
Colombian electronic invoices no longer fail when users send an invoice with a debit note operation type but no linked reference invoice. This prevents a blocking error during email/DIAN submission and makes invoice sending more reliable for Colombian companies.
Original PR description
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** -…
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** - Install Accounting and l10n_co_dian modules. - Switch company to "CO Company". - Create new customer invoice. (e.g; Operation Type (CO) = Nota Débito que referencia una factura electrónica) - Click on "Send" button. Ensure DIAN is selected in template and then send it. - Error occurs. **Error:** AttributeError - 'bool' object has no attribute 'isoformat' **Cause:** The issue happens because debit_origin_id is not set, which makes reference_invoice equal to None, leading to an error. - [1] In pervious versions, the operation type could not be modified because it was read-only field. From saas-18.4, it became a stored field. Therefore, without debit note, the operation type cannot be changed directly. In this case, the condition at [2] fails, and the method returns None. **Fix:** This commit ensures that a value is only returned if a reference invoice exists; otherwise, it returns None. [1] - https://github.com/odoo/enterprise/blob/8c0217e4e38903783ab7d70ca3eec1c1e3de03de/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L730 [2] - https://github.com/odoo/enterprise/blob/b67a58ffd70952a06b7dd56a54782c433ff673fb/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1495-L1496 sentry-6810908763 Forward-Port-Of: odoo/enterprise#92714
The Studio sidebar now has a maximum width outside XML editor mode. This keeps the editing workspace easier to use and prevents the sidebar from taking up too much screen space.
Original PR description
This commit puts a hard limit to the studio sidebar width. task-4935942
This update fixes issues in Colombia DIAN electronic invoicing where new vendor bills did not show the correct commercial status and repeated event submissions could block the workflow. It also corrects issuer acceptance events so they are accepted properly by DIAN, helping accounting teams process supplier documents more reliably.
Original PR description
this commit solves following issues: - the commercial status was missing on newly created vendor bills - the flow got stuck when an event had already been sent and we tried to send it again - The accept by issuer event generated errors on DIAN's side task: 5064534
The payslip form now hides the warnings area when there are no issues to show. This removes unnecessary empty space and makes the payroll screen cleaner for users.
Original PR description
Before this change, the `issues` field was always rendered on the payslip form, even when there were no warnings to display. This resulted in unnecessary empty space being shown in the UI. task-5071223 Forward-Port-Of: odoo/enterprise#94489
Users can now manually enter a checkout time directly from the Attendance Gantt popup when an attendance is still open. This fixes a visibility issue that previously forced users to leave the Gantt view to complete the checkout information.
Original PR description
The Gantt popup form explicitly set `check_out` invisible when it was empty, which prevented users from manually entering a checkout for an open attendance. This commit removes the overriding xpath so that the form simply inherits the standard `hr_attendance_view_form` behavior, where the `check_out` field is always visible and editable. Users can now set a manual checkout directly from the Gantt modal. task-5026978 Forward-Port-Of: odoo/enterprise#92726
A typo in an accounting reports error message has been fixed so blocked changes are displayed as a properly formatted list. This makes the warning clearer for users when lock dates prevent edits to report external values.
Original PR description
[FIX] account_reports: typo in error message typo in generation of error message saying that lock dates are blocking the modification of a report external value See odoo/enterprise#92949 Forward-Port-Of: odoo/enterprise#95175
Planning now correctly calculates weekly progress for flexible shifts that span across two weeks. This prevents managers from seeing all allocated hours counted in the first week, making workload tracking more reliable.
Original PR description
### Steps to reproduce: - Install Planning app - Create a shift for a flexible employee that starts on Friday and end on the following Tuesday for example - Go to the gantt view for the week that the shift should start at - Notice the progress bar is showing the whole allocated hours not just the week's hours ### Cause: This mainly happening because when the employee is flexible we are getting the value by multiplying the hours_per_day of his schedule by the period.days and the period is the shift period ### Fix: We use the interval we are just checking as the period now so if the shift is extended to the next week we are just going to use the end of the week as the interval end not the shift's end_datetime opw-5022800 Forward-Port-Of: odoo/enterprise#95279 Forward-Port-Of: odoo/enterprise#93404
Barcode lookups now fill in product information only when the relevant fields are empty, instead of replacing an existing eCommerce description. This helps merchants keep their manually written online product descriptions intact while still benefiting from barcode database enrichment.
Original PR description
Scenario: - enable "Barcode Database" in general settings - set an eCommerce description on a product - set a barcode in the database on that product (eg. 799439112766) Result: the eCommerce description has been overwritten by the barcode lookup result. Fix: do like other _update_product_by_barcodelookup methods and only update value that are not yet set. Note: also fixes the return of the overridden methods. opw-5061231 Forward-Port-Of: odoo/enterprise#94098
The Belgian POS blackbox reports no longer show the message "THIS IS NOT A VALID VAT TICKET" on invoices and daily reports. This avoids confusion because the warning is only relevant for POS receipts that are not final VAT tickets.
Original PR description
- Remove the message "THIS IS NOT A VALID VAT TICKET" from the invoices and POS daily reports views. This message is only necessary on POS receipts that are not final TVA tickets. task-id: 5013860 Forward-Port-Of: odoo/enterprise#92287
Merging timesheet entries from the same helpdesk ticket now keeps them connected to that ticket. This prevents lost ticket history and blocks merges when selected timesheets belong to different helpdesk tickets.
Original PR description
…helpdesk ticket **Steps to reproduce** - Register 2 timesheet lines on 1 helpdesk ticket - Go to the timesheets app and select these 2 lines - Go to Actions -> Merge timesheets Issue: the timesheets are merged but unlinked from the helpdesk ticket. **Change** Preserve the link to the helpdesk ticket when merging timesheets. An error is raised if attempting to merge timesheets not having all the same `helpdesk_ticket_id` value. opw-5086090 Forward-Port-Of: odoo/enterprise#94780
The website generator help page now points users to the correct support contact instead of an outdated or wrong email. This helps customers reach the right assistance channel when they need help during website setup.
Original PR description
Changing wrong email into the support /help page. Task: odoo.com/odoo/project.task/5100049?menu_id=4720 Forward-Port-Of: odoo/enterprise#95282
This fix prevents an error when users open sale order line details from a product form that includes related invoice lines. It ensures the dialog uses the current record information instead of relying on a search view that is not available there, improving stability for customized product workflows.
Original PR description
…in a dialog Steps to reproduce ================== Prerequisites: Having a product with an SO and an Invoice confirmed. Steps: - Open Product Variant Form - Open Studio - Add new O2M to SOL: Product (Sale Order Line) - Edit subview form - Add invoice_lines - Quit Studio - Click on SOL on Product view → It crashes => TypeError: can't access property "context", ctx.env.searchModel is undefined Cause of the issue ================== In form view dialogs, we don't have a search model Solution ======== We should use the context from the current record opw-4921186 Forward-Port-Of: odoo/enterprise#95259
The Mexican electronic invoicing flow now handles customer names entered with accents when comparing them to official legal names that omit accents. This helps prevent failed invoice validation for self-invoicing customers after point-of-sale purchases.
Original PR description
Currently, the self-invoicing portal lets client request an invoice after making a purchase in PoS. A form allows them to enter their personal informations such as their name. Many of them enter their name with accents, however the government has all the names without any accents which causes errors when trying to match the requesting party with their legal name during the stamping process of the CFDI. task-4952174 Forward-Port-Of: odoo/enterprise#95280 Forward-Port-Of: odoo/enterprise#95207
33 changes
Enhancements to existing features
Users can now open the activity scheduling wizard from the command palette anywhere in Odoo, using the new Alt+Shift+A shortcut. This makes it faster to create personal follow-ups, and when used on a relevant form it automatically links the activity to the current record.
Original PR description
Task: task-5065655
Automatic reconciliation models now use the account’s display name directly, without adding extra numbers to make each name unique. This keeps rule names clearer for users now that duplicate names are allowed.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/9cdc519a7aa7e40cad31d2eb6dcc8858df831e9b we change the way the reco model name were made by going back to just the display name of the account. For prior version 19.0, a unique constraint on the name was there so we added a number after the name of the account to avoid duplicate. The constraint has been removed and so this code is no longer needed. no task id
Resolved issues and error corrections
The Mexican electronic invoicing flow now handles customer legal names entered with accents when creating invoices from the self-invoicing portal. This prevents avoidable invoice stamping failures when government records store the same names without accents.
Original PR description
Currently, the self-invoicing portal lets client request an invoice after making a purchase in PoS. A form allows them to enter their personal informations such as their name. Many of them enter their name with accents, however the government has all the names without any accents which causes errors when trying to match the requesting party with their legal name during the stamping process of the CFDI. task-4952174 Forward-Port-Of: odoo/enterprise#95207
Refreshing appointment slots could fail when no resource was selected because the system tried to read an empty value as a number. This fix handles missing resource selections safely, keeping appointment availability and capacity updates working reliably.
Original PR description
When refreshing the slots, it's possible that the resource_selected_id is equal to None, False or just empty string. This was leading to some error when parsing it to an integer. This commit move the parsing into the method computing the max possible capacity after checking if we got a value. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5102895 Forward-Port-Of: odoo/enterprise#95144
Fleet manufacturer records now count only active vehicle models, so the displayed totals better reflect currently used data. Users can also filter vehicle models to view archived entries when needed, improving data review without affecting daily workflows.
Original PR description
- Fixed count of models in manufacturer to count only active models. - Added 'Archived' search filter for 'model' model Task - 4921998 Forward-Port-Of: odoo/odoo#228174 Forward-Port-Of: odoo/odoo#222353
Fixes an issue that could block delivery validation when proceeding with products using expiration tracking but missing a removal date. This helps warehouse users complete affected deliveries without encountering an unexpected error.
Original PR description
currently an error occur when user proceed except expired delivery. Steps to Reproduce: - Install the `product_expiry` module. - Create a product with the configuration: - In `Track Inventory`,…
currently an error occur when user proceed except expired delivery. Steps to Reproduce: - Install the `product_expiry` module. - Create a product with the configuration: - In `Track Inventory`, select `By Lots`. - In the `Inventory tab`, check `Expiration Date`. - In the newly created product, click `Lot/Serial Numbers` button, create a new `Lot/Serial Number`, and clear the `Removal Date` of that Lot/Serial Number. - Go back to the newly created product and update the `Quantity On Hand` of the linked `Lot/Serial Number` by clicking `Update`. - Now go to `deliveries` and create a new `delivery` and add the newly created product and `validate` > `Proceed except expired`. `TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime'` This error occurs when user proceed except expired delivery, The removal_date of the move line is computed based on the lot's removal date and the move line's expiration date. If the lot does not have a removal date and the move line also does not have an expiration date, then removal_date on the move line is set to False [1], which raises the error here [2] This commit ensures that it only compares with the move line removal_date if it is present. [1]- https://github.com/odoo/odoo/blob/70a7babcc830f72bd069a5bb1504748363e4e848/addons/product_expiry/models/stock_move_line.py#L56 [2]-https://github.com/odoo/odoo/blob/70a7babcc830f72bd069a5bb1504748363e4e848/addons/product_expiry/wizard/confirm_expiry.py#L48 sentry-6864176071 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226025
Product images on website sales pages now keep their original quality instead of being compressed to a lower setting. This improves the visual presentation of products, especially where image detail matters for customer confidence and purchasing decisions.
Original PR description
Product image quality was set to 75% not good enough in some cases. So it increased to 100% to keep the original quality of the image. opw-5094063 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix updates automated website test journeys so they correctly wait when a page reloads or redirects. It helps keep Odoo's validation pipeline stable and reduces false failures in website, event booth, and click-and-collect flows.
Original PR description
\* = website_event_booth_exhibitor, website_event_booth_sale_exhibitor, website_sale_collect **Issue:** 1. Several tours across multiple modules were failing on runbot because some steps triggered a…
\* = website_event_booth_exhibitor, website_event_booth_sale_exhibitor, website_sale_collect **Issue:** 1. Several tours across multiple modules were failing on runbot because some steps triggered a page reload or redirect without using `expectUnloadPage: true`, which caused those steps to fail. 2. In the `webooth_exhibitor_register` tour, the behavior of the last step before calling the `_getSteps` function differs depending on the installed modules: - With only `website_event_booth_exhibitor` installed, the last step does not trigger a page reload. - With `website_event_booth_sale_exhibitor` also installed, the same step triggers a redirect to the checkout page, which caused the tour to fail. **Fix:** 1. Added `expectUnloadPage: true` to steps that trigger a reload/redirect, so the tour now waits for the new page to load before continuing. 2. Updated `_getSteps` in both modules: - Moved the problematic step of the `webooth_exhibitor_register` tour inside `_getSteps`. - In `website_event_booth_sale_exhibitor`, the same step was updated with `expectUnloadPage: true` to correctly handle the checkout redirection during the payment flow. runbot-[231586](https://runbot.odoo.com/odoo/error/231586) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226276
The Accounting reports page no longer crashes when users load more lines in a Follow-Up Report with many invoices. This improves reliability for customers reviewing large partner statements or follow-up details.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. For partner X, create minimum 90 invoices for `See more/Load more` option into page. 3. In the partner form view, click the Customer…
**Steps to reproduce:**
1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.
**NOTE**
- You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
invoice = env['account.move'].create({
'move_type': 'out_invoice',
'partner_id': 10,
'company_id': env.company.id,
'invoice_line_ids': [(0, 0, {
'product_id': 16,
'quantity': 1,
'price_unit': 100.0,
})],
})
invoice.action_post()
```
**Issue:**
`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.
**Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73
- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />
- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />
**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.
**opw - 5083894**
Forward-Port-Of: odoo/enterprise#95103This update refreshes Odoo’s spreadsheet component and fixes several small user-facing issues. Users should see more reliable spreadsheet sorting and cleaner chart and carousel visuals, improving day-to-day reporting and dashboard presentation.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/87b774dfa [REL] 19.0.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/87b774dfa [REL] 19.0.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/c84edcb45 [FIX] Sort: Allow to sort array formula that do not spread [Task: 5033192](https://www.odoo.com/odoo/2328/tasks/5033192) https://github.com/odoo/o-spreadsheet/commit/0e823e20a [FIX] Carousel: the sidepanel cogwheel has a weird look [Task: 5090177](https://www.odoo.com/odoo/2328/tasks/5090177) https://github.com/odoo/o-spreadsheet/commit/b2aec82f2 [FIX] charts: truncate radar chart labels correctly [Task: 5078858](https://www.odoo.com/odoo/2328/tasks/5078858) https://github.com/odoo/o-spreadsheet/commit/b1f21db41 [FIX] carousel: missing color for empty carousel header [Task: 5082459](https://www.odoo.com/odoo/2328/tasks/5082459) https://github.com/odoo/o-spreadsheet/commit/13482eefd [IMP] test: improve `expect.toHaveStyle` jest matcher [Task: 5059476](https://www.odoo.com/odoo/2328/tasks/5059476) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This update prevents crashes for public website visitors using older Safari versions by adding missing browser support needed for translation caching. Visitors on Safari before version 17 should now be able to load pages normally instead of encountering failures at launch.
Original PR description
Safari < 17 (09/2023) doesn't support Set.difference. This function is used in our indexeddb wrapper, which runs also in the frontend, even for public (non logged-in) users, to fetch and cache translations. As a consequence, those people have a crash at each page launch. Safari 17 being recent enough for public users, we add a polyfill (for frontend only). 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#228120
This update fixes a failing automated test related to Hong Kong payroll accounting after an internal leave-generation method changed. It helps keep payroll quality checks reliable without changing day-to-day user functionality.
Original PR description
Explanation: _generate_leave method is updated in saas-18.1. build_error-229902 Forward-Port-Of: odoo/enterprise#95084
This update removes a fixed year from point of sale settlement tests, preventing failures when dates change over time. It helps keep automated checks stable so future point of sale updates can be validated more reliably.
Original PR description
Remove hardcoded year date for selecting invoices to settle. rb-error: 230713 community PR: https://github.com/odoo/odoo/pull/224171 Forward-Port-Of: odoo/enterprise#93166
Invoice PDFs now include both the product name and its description when a product has extra descriptive text. This prevents important product identification from being omitted on customer-facing invoice documents.
Original PR description
When printing an invoice for a product that has a description, only the description appears on the PDF. Commit https://github.com/odoo/odoo/commit/7e553d25890d1e236123f0fa7e11ce86f59448ab removed the concatenation of the product name and description in updateLabel (in product_name_and_description in product module). This commit reintroduce the concatenation of the product name and the product description for invoices by overriding updateLabel in product_label_section_and_note_field in account. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4988340) opw-4988340 Forward-Port-Of: odoo/odoo#222589
Odoo now handles printer setup errors more gracefully when the system cannot add a printer, such as on read-only devices or when a printer name is invalid. Instead of stopping the printer interface, the error is logged and printing services can continue running.
Original PR description
Before this commit, if CUPS raised an error when adding a printer in the `supported()` method of the printer driver, the exception would not be caught causing the printer interface to stop. This can happen for example if the filesystem is read-only or the printer has an invalid name. After this commit, we catch any CUPS errors and log them, allowing the printer interface to continue running. We also enter write mode before adding the printer to prevent any read-only errors. task-5086036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227307 Forward-Port-Of: odoo/odoo#227121
Fixes an issue that could block sending certain Colombian customer invoices when a debit-note-related operation type was selected without a linked reference invoice. This prevents an error during the send process and helps users complete DIAN invoice delivery smoothly.
Original PR description
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** -…
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** - Install Accounting and l10n_co_dian modules. - Switch company to "CO Company". - Create new customer invoice. (e.g; Operation Type (CO) = Nota Débito que referencia una factura electrónica) - Click on "Send" button. Ensure DIAN is selected in template and then send it. - Error occurs. **Error:** AttributeError - 'bool' object has no attribute 'isoformat' **Cause:** The issue happens because debit_origin_id is not set, which makes reference_invoice equal to None, leading to an error. - [1] In pervious versions, the operation type could not be modified because it was read-only field. From saas-18.4, it became a stored field. Therefore, without debit note, the operation type cannot be changed directly. In this case, the condition at [2] fails, and the method returns None. **Fix:** This commit ensures that a value is only returned if a reference invoice exists; otherwise, it returns None. [1] - https://github.com/odoo/enterprise/blob/8c0217e4e38903783ab7d70ca3eec1c1e3de03de/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L730 [2] - https://github.com/odoo/enterprise/blob/b67a58ffd70952a06b7dd56a54782c433ff673fb/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1495-L1496 sentry-6810908763 Forward-Port-Of: odoo/enterprise#92714
This change stabilizes an accounting test that could fail unpredictably due to ambiguous domestic fiscal position data. It also adds a safeguard to warn about future localization data that could recreate the issue, helping maintain accounting reliability across countries.
Original PR description
#### Issue: `test_domestic_fp` randomly fail #### Cause: While computing domestic fiscal position, there are 2 fiscal position candidates for being domestic as they got the same `sequence` and no `country_id`. It happens randomly that the second one is fetch instead of the first one. #### Solution: The failing assert checks a case that doesn't exist in any fiscal position data. Therefore, this commits remove this part of the test, but add a warning in `test_all_l10n` to ensure this case won't happen in new data. runbot-231686 This PR is linked to [this PR](https://github.com/odoo/odoo/pull/224599) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226336
Merging timesheet entries from the same helpdesk ticket now keeps them connected to that ticket. The system also prevents merging entries from different tickets, helping avoid lost ticket history and reporting errors.
Original PR description
…helpdesk ticket **Steps to reproduce** - Register 2 timesheet lines on 1 helpdesk ticket - Go to the timesheets app and select these 2 lines - Go to Actions -> Merge timesheets Issue: the timesheets are merged but unlinked from the helpdesk ticket. **Change** Preserve the link to the helpdesk ticket when merging timesheets. An error is raised if attempting to merge timesheets not having all the same `helpdesk_ticket_id` value. opw-5086090 Forward-Port-Of: odoo/enterprise#94780
This update fixes an issue in the Point of Sale order summary caused by relying on an outdated internal method. It helps ensure order information is prepared correctly, reducing the risk of errors during checkout or order handling.
Original PR description
Replace usage of `serialize` (method that was previously removed) by `serializeForORM` in `OrderSummary`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225982 Forward-Port-Of: odoo/odoo#225583
This fixes automated point of sale localization tests so they no longer depend on a hardcoded invoice year. The change helps keep test results stable over time and reduces false failures during maintenance.
Original PR description
Remove hardcoded year date for selecting invoices to settle. rb-error: 230713 enterprise PR: https://github.com/odoo/enterprise/pull/93166 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224171
This update fixes an internal test issue in accounting reports that could fail when Czech localization was installed. It makes the test adapt to the actual payment reference value, helping keep builds stable without changing user-facing behavior.
Original PR description
test_document_data_for_bank_journal_with_show_payment_option was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which is a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479 Forward-Port-Of: odoo/enterprise#95014
This fixes an inconsistency in Belgian payroll employee records by making the student status field read-only where it is shown on employees. This prevents users from editing a value that is controlled elsewhere, reducing confusion and avoiding data mismatches.
Original PR description
This commit marks `l10n_be_is_student` field as readonly in `hr.employee` model since it is a related field of `hr.version` and it is not editable in `hr.version` and so there is no reason to make in editable in employee model. runbot-error-231303 Forward-Port-Of: odoo/enterprise#95208
This fix ensures employee version records can be updated correctly even when the selected records belong to different employees. It prevents update failures in HR workflows that manage multiple employee histories at once.
Original PR description
Problem: the write method on the version is not working if the versions are coming from multiple employees. This commit fixes the issue by taking care if the versions belong to different employees. task-5085086 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#227117
Italian XML invoices marked as TD01 are now kept as the correct document type when imported as vendor bills. This prevents purchase invoices from being mislabeled as TD05, improving compliance accuracy and reducing manual corrections.
Original PR description
**Issue** When importing an XML invoice of document type TD01, it is incorrectly assigned type TD05 after processing. **Steps to Reproduce** 1. Install Accounting, l10n_it and l10n_it_edi 2. Go to…
**Issue**
When importing an XML invoice of document type TD01, it is incorrectly assigned type TD05 after processing.
**Steps to Reproduce**
1. Install Accounting, l10n_it and l10n_it_edi
2. Go to Accounting > Vendors > Vendor Bills
3. Upload an XML invoice with TD01 as the document type
4. Upon confirming the bill, observe that the document type is incorrectly set to TD05
**Root Cause**
The document type matching logic fails to assign TD01 because the uploaded invoice has move_type = in_invoice, while TD01 was only configured to match out_invoice. https://github.com/odoo-dev/odoo/blob/7436e8cee2f605c6d5d559cb410e7a3dc8f372b9/addons/l10n_it_edi/models/account_move.py#L886-L891
**Fix**
According to Italian e-invoicing specifications, TD01 applies to both sales and purchase invoices ("Fatture di vendita" and "Fatture d’acquisto"). To reflect this, in_invoice is now added to the list of supported move_types for TD01, allowing correct detection during XML import.
opw-4931438
Forward-Port-Of: odoo/odoo#219310Employees and managers can now enter a checkout time directly from the Attendance Gantt popup for open attendance records. This fixes a visibility issue that previously blocked manual checkout entry in that view.
Original PR description
The Gantt popup form explicitly set `check_out` invisible when it was empty, which prevented users from manually entering a checkout for an open attendance. This commit removes the overriding xpath so that the form simply inherits the standard `hr_attendance_view_form` behavior, where the `check_out` field is always visible and editable. Users can now set a manual checkout directly from the Gantt modal. task-5026978 Forward-Port-Of: odoo/enterprise#92726
The display of “Back on X” messages for employees on leave has been made consistent across chat sidebars, member lists, popovers, and conversation areas. This fixes uneven text size, color, spacing, and alert styling so users see a cleaner and more uniform interface.
Original PR description
- size and color of "Back on X" text when someone is on leave was inconsistent on UI. - discuss sidebar item and member list with "Back on X" had too much height `lh-base` => `lh-sm`. - floating text "Back on X" above conversation had old style of alert instead of newer one that is not rounded nor has margin. Before <img width="1917" height="722" alt="Screenshot 2025-09-23 at 18 18 22" src="https://github.com/user-attachments/assets/ffa12430-1ff6-4271-9b11-c818b262888d" /> After <img width="1918" height="724" alt="Screenshot 2025-09-23 at 18 17 02" src="https://github.com/user-attachments/assets/bbf9c529-b1ae-4340-897d-69a121408189" />
Fixed a typo that caused bullet points in an accounting report error message to display with incorrect spacing. This makes lock date warnings easier for users to read when report external values cannot be modified.
Original PR description
[FIX] account_reports: typo in error message typo in generation of error message saying that lock dates are blocking the modification of a report external value See odoo/enterprise#92949 Forward-Port-Of: odoo/enterprise#95175
Pasting tables from sources such as Google Docs now works more reliably in Odoo editors. Tables remain visible and empty cells are prepared correctly, reducing manual cleanup for users creating website or rich-text content.
Original PR description
### Steps to Reproduce: - Go to the website. - Copy a table from Google Docs. - Paste the table into the editor. - Observe that the table is not visible because some required classes are missing. - Notice that there is no base container inside the empty `<td>` elements. ### Description of the issue/feature this PR addresses: - When content is pasted from other source (e.g., Google Docs inside iframe), attribute nodes coming from another JavaScript context do not match the `Attr` prototype of the current context. ### Desired behavior after PR is merged: - Use `item.nodeType === Node.ATTRIBUTE_NODE` instead of `instanceof Attr` to detect attribute nodes. - Insert a base container into empty `<td>` elements when pasting tables from external sources. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227378
The Discuss app no longer flickers when users press Alt to view keyboard shortcuts, creating a steadier experience. Mobile message action controls are also positioned closer to the relevant message, making conversations easier to use on small screens.
Original PR description
When pressing "ALT" to see hotkey, discuss app was flickering. This happens because the size of action list button is inconsistent with the hotkey overlay. This commit simplifies code around style of…
When pressing "ALT" to see hotkey, discuss app was flickering. This happens because the size of action list button is inconsistent with the hotkey overlay. This commit simplifies code around style of action list, so that the height is deduced from padding like any other button in the rest of UI. Padding and spacing has been adjusted to take into account the removal of imposed height, which fixes the flicker issue. Also fixes an issue where the message action "..." in mobile was too far away from message bubble for other people messages. This comes from long press dropdown also putting empty message action for spacing but it doesn't take into account on message alignment. This now puts the action always at the end of message action. Flicker Before  Flicker After  Mobile Before <img width="408" height="498" alt="mobile-before" src="https://github.com/user-attachments/assets/b3af85d8-7ef5-49aa-a62f-81d57f56a560" /> Mobile After <img width="407" height="503" alt="mobile-after" src="https://github.com/user-attachments/assets/0832761c-fc7c-41c5-b04f-3c9df8ae8799" />
This fixes an issue where Ctrl+Backspace behaved differently in Firefox and Safari compared with Chrome when editing empty or boundary paragraphs. Users now get more predictable text editing behavior across supported browsers.
Original PR description
**Current behavior before PR:**
In Firefox or Safari, `<p>abc def</p><p>[]<br></p>` => `ctrl + backspace` ends up with `<p>abc []</p>` which is different o/p than Chrome (`<p>abc def[]</p>`).
This happens because Firefox's Selection.modify("extend", "backward|forward", "word") behaves differently than Chrome when the cursor is at the start or end of a block (or in an empty block). This behavior breaks the output when pressing ctrl + backspace.
**Desired behavior after PR:**
This PR ensures that in such case deletion behavior is same across browsers as Chrome. In other words `<p>abc def</p><p>[]<br></p>` => `ctrl + backspace` should be `<p>abc def[]</p>` .
task-5055135
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#226040Spreadsheet imports now correctly handle values that look like dates when they belong in text fields, preventing failed imports and confusing error messages. This helps users re-import exported records, such as pricelist rules, without manual cleanup when date-like values appear in names or other text fields.
Original PR description
*: test_import_export ### Steps to reproduce: - Go to Sales/Prodcuts/Pricelists - Create a new pricelist with a rule with a set Valid Period - Export that record adding the Pricelist Rule/Start Date…
*: test_import_export ### Steps to reproduce: - Go to Sales/Prodcuts/Pricelists - Create a new pricelist with a rule with a set Valid Period - Export that record adding the Pricelist Rule/Start Date (item_ids/date_start) as XLSX format - Delete the record and test the import the XLSX file #### Uncaught Promise: > Invalid props for component 'ImportDataColumnError' :'resultNames' is undefined (should be a array) ### Cause of the Issue: The issue is raised by the error message: https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1428-L1432 which is not properly handled by the `ImportDataColumnError` component. However, in the present situation, the issue is just that this error message itself should not be raised in the first place. #### Details: Since commit 630b2683d3aad203b0bbf7d2d63b88cd4d3bd9d7, date and datetime formatted cells in spreadsheets are no longer Char field. Instead, they are imported as date and datetime objects. This was intended to allow importing columns with mixed encodings (e.g., some values stored as strings, others as dates in the spreadsheet). However, a side effect of this change is that if a char-type field contains values that a spreadsheet interprets as dates or datetimes, the import fails. For example, an account move name "21/12/2025" may be interpreted as a date. Attempting to perform a join on this string expected value causes a traceback here: https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1628-L1632 To address this discrepancy, commit 91dca74b3e395c8ee410db18784990ba3a6a7e6e introduced a check raising an error if the imported field type is not appropriate to carry a `date/datetime` value. This fix has two major issues: 1) It still does not handle the above use case correctly—it remains impossible to import "21/12/2025" as a record name. 2) (The present issue) It does not properly check the type of related fields. For example, a field like "company_id/partner_id/membership_start" is not considered as an allowed date field. The current check on allowed date fields being overly simplistic: https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1416-L1421 ### Fix: We propose reverting commit 91dca74b3e395c8ee410db18784990ba3a6a7e6e. And instead of recursively computing the related model and the appropriate types of related fields (including property-type relational fields), we will simply stringify values when they are written into char-like fields (e.g., char or text). Note: this may also require an adjustment in master for the html type. opw-4935423 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226807
The Point of Sale now blocks changes to a product when that same product is already in the current order. This helps avoid inconsistent product details in active carts and reduces checkout errors for staff.
Original PR description
- Prevent update of product via POS when the product is already in the current order (to avoid leading to inconcistent data on this product for the current order). task-id: 4943650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219209
Automation rule screens now include archived rules by default without carrying that setting into unrelated lookup dialogs. This prevents users from seeing archived records when searching for related records while configuring automated actions.
Original PR description
**Before** - the active_test context key is part of the main base_automation action (base_automation_act), but this context key stays in the context further, leading to unwanted filtering in i.e. the…
**Before** - the active_test context key is part of the main base_automation action (base_automation_act), but this context key stays in the context further, leading to unwanted filtering in i.e. the action_server_ids.resource_ref search view dialog. - Steps to reproduce: - have base_automation installed - create an automation rule targeting the res.users model - add an Update server action targeting the Partner field - in the resource_ref autocomplete, click on Search More... - the search view dialogs displays archived records **After** - we chose to instead have a default filter in the base_automation_act action to include archived records by default. As the context key to activate the default filter starts with 'search_default_', it is already cleared from the context when opening the form view (standard behavior). - when you reproduce the same steps as before, the archived records are no longer displayed in the search view dialog. **Additional Note** This fix requires to upgrade the base_automation module. opw-4886487 Forward-Port-Of: odoo/odoo#225146
5 changes
Resolved issues and error corrections
Fleet manufacturers now show counts based only on active vehicle models, making the displayed numbers more accurate for day-to-day use. An Archived filter was also added so users can more easily find inactive vehicle models when needed.
Original PR description
- Fixed count of models in manufacturer to count only active models. - Added 'Archived' search filter for 'model' model Task - 4921998 Forward-Port-Of: odoo/odoo#228174 Forward-Port-Of: odoo/odoo#222353
The Czech VAT return now places invoices without a partner VAT number in section A5 regardless of their value. It also consistently classifies special VAT regime entries for travel services and margin schemes in A5, helping businesses submit more accurate VAT control statements.
Original PR description
Before this commit, the l10n_cz VAT return report classified entries in section A4 if their total amount exceeded 10,000 CZK, and in section A5 if the amount was 10,000 CZK or less. - In l10n_cz, create an invoice with a cz partner without vat, over 10000. - In tax return the entry will be in section A4. With this commit: - Entries with no partner VAT number are now always classified under A5, regardless of the total amount. - Entries using a special VAT regime (l10n_cz_scheme_code), corresponding to Section 89 – travel services and Section 90 – margin scheme) are also always classified under A5, regardless of the amount. opw-4953787
The online shop price range filter now uses the corrected search term when a customer's search is automatically adjusted for a close match. This keeps price filtering available and accurate after fuzzy searches, improving the shopping experience.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Navigate to the website shop page.
2. Search for a term that is close to an existing one, but not exact ("dask" instead of "desk" for example)
Issue
-----
The price range filter will stop functioning
Cause
-----
The domain used to get the minimum and maximum prices for the price range filter used the original search term regardless of whether the actual search results are from a fuzzy search term or not
Solution
--------
When there is a fuzzy search term use it to get the minimum and maximum prices for the price range filter instead of the original search term
opw-5020545
Forward-Port-Of: odoo/odoo#226059Odoo now validates Taiwanese business tax numbers using Taiwan’s revised official checksum rule. This prevents valid newly issued numbers from being rejected as the available number range expands.
Original PR description
As the number of UBN in taiwan is expected to be exhausted, the numbers have been expended. To do so, the verification logic has been revised from the checksum being divisible by 10 to it being divisible by 5. stdnum is not yet supporting this new validation, and if it does it will take some time for Odoo to use the updated package, so we will handle the validation ourselves from now on. see https://www.ntbna.gov.tw/singlehtml/bbabfd4af20541b7859b4c5a099081f6?cntId=0625114d47274366baab1d3317f866ab task-5064712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228093 Forward-Port-Of: odoo/odoo#225468
Users with viewer access can now mark documents as favorites using the keyboard shortcut without hitting an access error. This makes the Documents app more consistent and avoids interruptions for users who rely on shortcuts.
Original PR description
steps to reproduce =================== - Select a document where you have viewer permission. - Try to toggle the favorite through a hotkey. - Access Error when toggling favorite. Technical =========== - To maintain compatibility with stable versions and avoid changing the return type of the existing method, created the helper method, which will call `toggle_favorited` as we need to handle it for multiple records. After this commit ================== - This commit handles the accessError for shortcut flow. As in 18.3 we already have documents_favorite widget https://github.com/odoo/enterprise/pull/82639 which will work for manually favoriting the document, but it is not handling the shortcut flow. Task-4910326
8 changes
New functionality added to Odoo
Adds a new Pakistan e-invoicing module that lets businesses send invoices to the Pakistan government through an API service. This supports local compliance requirements and adds related setup, product, unit of measure, invoice, and reporting fields needed for the process.
Original PR description
A new module to send invoices to the Pakistan Government using API service. Task [link](https://www.odoo.com/odoo/project/967/tasks/2879519) task-2879519
Resolved issues and error corrections
Imported Chilean supplier invoices now correctly treat lines marked with exemption code 6 as negative amounts. This prevents vendor bills from being recorded with overstated positive values, improving accounting accuracy for affected DTE imports.
Original PR description
### Issue: When, in a DTE file, a line has the code 6 in `IndExe`. The amount of the line is supposed to be negative. (See the [doc](https://www.sii.cl/factura_electronica/formato_dte.pdf) page 31/32) ### Steps to reproduce: - Install 'l10n_cl_edi' and switrch to a Chilean company - Have a DTE file with a line having '6' in `IndExe`: - In Accounting > Vendor > Bills, click the button "Upload" and select the DTE file - The imported move has positive values on the every lines ### Cause: The values of `IndExe` are not considered. ### Solution: Add a condition changing the sign of `price_unit` when 6 is in `IndExe` opw-4954723
Odoo now accepts Taiwan VAT numbers under the latest official validation rules. This prevents valid new Taiwanese business identifiers from being incorrectly rejected as number ranges expand.
Original PR description
As the number of UBN in taiwan is expected to be exhausted, the numbers have been expended. To do so, the verification logic has been revised from the checksum being divisible by 10 to it being divisible by 5. stdnum is not yet supporting this new validation, and if it does it will take some time for Odoo to use the updated package, so we will handle the validation ourselves from now on. see https://www.ntbna.gov.tw/singlehtml/bbabfd4af20541b7859b4c5a099081f6?cntId=0625114d47274366baab1d3317f866ab task-5064712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225468
Subscriptions linked to archived companies are now skipped by the automatic recurring invoice process. This prevents hidden or unexpected invoices from being created for companies that users have intentionally archived, reducing cleanup work and billing confusion.
Original PR description
This commit is a backport of: https://github.com/odoo/enterprise/commit/a93e7eccc1b6bc39ad50771c696cb9cd6fef2ba4 Currently, when a company which has recurring orders (subscriptions) active is…
This commit is a backport of: https://github.com/odoo/enterprise/commit/a93e7eccc1b6bc39ad50771c696cb9cd6fef2ba4 Currently, when a company which has recurring orders (subscriptions) active is archived, the cron still periodically invoices them as usual but the user is not able to see it because they don't show up in the views. To avoid having to unarchive the comany and check every subscription one by one, this PR aims at making the cron ignore any subscription tied to an archived company, as intended. The only modified cron is the one that creates invoices since the other one of interest (the one that sends reminders) operates only on invoiced orders, which we avoid having with this change. Also added a test to ensure that if the company related to a subscription sale order is archived, the cron won't invoice it. ## Steps to reproduce: - Create a company A - Create a subscription belonging to company A with a next invoice date <= today - Archive the company - Run the scheduled action “Sale Subscription: generate recurring invoices and payments” The deferred information in the Settings must be correct - Unarchive the company and check the subscription. It has been invoiced. You may need to add back the Company A from the Allowed Companies of the user backport-of: a93e7ec opw-4904325
This fix prevents users from accidentally trying to send a WhatsApp message without choosing a required template. Instead of causing an unexpected error, the system now blocks the action and guides users to select a template first.
Original PR description
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the templates. 2. Open any contact and click the **WhatsApp** button next to the phone number. 3. Remove the template and click **Send Message**. **Error:** `ValueError - Expected singleton: whatsapp.template()` **Cause:** At [1], it attempts to fetch the formatted body and header from the template ID. Since no template is selected, it results in an error. **Fix:** This commit makes the field `wa_template_id` required, preventing users from sending a whatsapp message without a template. In stable versions, raise a validation error if a user attempts to send a message without selecting a template. [1] - https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/whatsapp/wizard/whatsapp_composer.py#L319 sentry-6854466874
This fixes a regression that prevented portal users from creating project tasks by sending an email to a project alias. It restores an expected collaboration workflow, so external users can continue submitting tasks without manual intervention.
Original PR description
The new safety belt introduced in 745f3accaf775550294d6f1bf562a0dcc15f7a08 made it impossible for portal users to create tasks by sending emails to the project alias. @moduon MT-11332 Forward-Port-Of: odoo/odoo#225321
The online shop now updates available stock correctly when customers add either a kit product or one of its components to their cart. This prevents shoppers from seeing misleading availability and helps avoid overselling when kit and component products share the same inventory.
Original PR description
### Steps to reproduce: - In the settings website > Shop: - Disable `Out-of-Stock: Continue Selling`. - Enable `Show Available Qty` if below 5 units. - Create 2 storable products published on the…
### Steps to reproduce:
- In the settings website > Shop:
- Disable `Out-of-Stock: Continue Selling`.
- Enable `Show Available Qty` if below 5 units.
- Create 2 storable products published on the website:
- COMP, put 1 unit in stock.
- KIT with bom of type Kit using 1 x COMP.
- With a private window go to the shop.
- Add 1 x COMP or KIT to the chart.
#### > This is not reflected on the available quantity in stock of the other product
### Cause of the issue:
The availability on the website is computed from the product availability using the `free_qty` fetched because of this override: https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/controllers/variant.py#L10-L13 from which the cart quantity of the product itself is deduced before re-render:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L49-L51 https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L83-L86 While the `free_qty` is correctly computed from kit products based on the component availability:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/mrp/models/product.py#L211-L221 The qties in the virtual cart quantities are not recomputed base on kits.
opw-4889956
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSale orders now avoid automatically selecting a sales team from a company the user cannot access. This prevents save errors when shared customers have sales teams assigned in another company, making multi-company order entry more reliable.
Original PR description
**Steps to reproduce:** - Create two companies. - Create two sales teams, each assigned to a different company. - Create a customer without a company (shared across both companies), and assign it a sales team from the first company. - Create a user belonging to the second company and its sales team. - With this user, create a new sale order for the shared customer. - The sales team field is automatically populated with the team from the other company. - An error is raised when saving the order. **Issue:** `_compute_team_id` does not validate allowed companies when determining `default_team_id`. As a result, `order.partner_id.team_id` could be used even if the user did not have access to the company of this team. **Fix:** Explicitly check if the proposed teams are available to the user in `self.env.companies.ids`. opw-4920130 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr