Daily updates from Odoo
Navigate
Branch
Wednesday, June 10, 2026
323 changes
20 changes
Enhancements to existing features
This update improves the Swiss payroll payslip report by incorporating the necessary source tax rate information. This ensures accurate tax calculations and reporting for Swiss businesses using the Odoo Enterprise system. It's a key update for compliance with Swiss tax regulations.
Original PR description
This commit adds the source tax rate in the payslip report for Swiss payroll. task-4979330 Forward-Port-Of: odoo/enterprise#112842
Resolved issues and error corrections
This update fixes a minor visual issue in the manufacturing process. The 'days' text was missing from the lead time field, creating a slightly confusing user experience. The fix ensures the 'days' label is always displayed correctly, improving clarity and usability for users managing manufacturing schedules.
Original PR description
Step to reproduce: 1. Go to Manufacturing 2. Create a new BoM or open an existing one 3. Go to the Miscellaneous tab 4. The 'days' text is missing after the manufacturing lead time field Fix: - Display the missing 'days' text after the manufacturing lead time field. - Fix the layout so that 'days' is perfectly aligned for both fields. Task-6246424
This update fixes a bug where users were unexpectedly locked out of list views after attempting to edit a row. The fix ensures the system correctly exits edit mode when a user deselects a row, preventing the view from becoming unusable and allowing normal operation.
Original PR description
Problem: When a user selects a row, attempts to edit a cell, and then clicks away without saving, the view becomes unusable. The selected row remains highlighted, and the system prevents the selection of other lines. The user is locked out until they click the "Save" or "Discard" buttons. Cause: The UI becomes stuck in edit mode. The `onGlobalClick` event handler within `documents_list_renderer` was missing the method call to exit edit mode. Solution: Updated `onGlobalClick` to correctly trigger the method to leave edit mode. task-6059836 Forward-Port-Of: odoo/enterprise#119594 Forward-Port-Of: odoo/enterprise#113000
This update resolves an issue where the timesheet assistant wouldn't function correctly when a rule was created without a template. The fix ensures the template field is required, allowing the assistant to build display names for key events accurately. This improves the reliability of the timesheet reporting feature.
Original PR description
## [FIX] timesheet_grid: make template field required in AW rule Before this commit, the template field in AW rule was not required and if one rule without any template is set, timesheet assistant will not be able to work correctly to build the display name for the key events found. This commit makes sure the template field is required. ## [FIX] timesheet_grid: ignore rules without template defined Before this commit, when the user creates a rule without any template set, the timesheet assistant will no longer work because it assumes the template is required. This commit adds a condition in the domain when we fetch all AW rules, to ignore the ones without template set. Forward-Port-Of: odoo/enterprise#119451 Forward-Port-Of: odoo/enterprise#119411
This update fixes an issue where the project template dropdown in demo mode had a cluttered appearance, making it difficult to read. The fix removes a styling element that caused text to overlap, ensuring a clean and user-friendly experience for all users.
Original PR description
Steps to reproduce: == - Login as demo/onboarding user - Open Project app - Click on New - Observe the template dropdown list Issue: == The template dropdown items are rendered with collapsed row height and poor vertical spacing in demo mode, making the list hard to read. Cause: == The template dropdown items utilized the `pe-0` utility class, which removed the padding at the end of the element. For non-admin users this caused the template name to touch the right edge of the container. Fix: == Removed the `pe-0` from the `DropdownItem` to restore standard right-side padding, and ensure consistent and readable row heights for both Admin and Demo users. task-5338191 Forward-Port-Of: odoo/odoo#267610 Forward-Port-Of: odoo/odoo#242983
This update resolves a test failure caused by incorrectly sending raw PDF data instead of the expected base64 encoded format. The fix ensures test data is properly formatted, preventing errors and maintaining the stability of the payroll accounting module.
Original PR description
This commit fixes an error when running the `test_employee_job_change` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw PDF content was being passed when a base64 representation was actually expected (which is obviously invalid base64). runbot-938173 Forward-Port-Of: odoo/enterprise#119786 Forward-Port-Of: odoo/enterprise#118523
This update optimizes how default suppliers are selected in purchase orders, significantly reducing the number of database queries. The change eliminates a performance bottleneck that was slowing down order processing, resulting in a 90% reduction in query time. This improves overall system speed and efficiency.
Original PR description
Currently, computing effective_vendor_id and supplier_id_placeholder presents N+1 query issues. Since every call to _get_default_rule() eventually triggers a _read_group() in _search_rule_for_warehouses(). However we can get rid of this entirely, since the subsequent call to _get_matching_supplier() with an empty values dict depends entirely on the product and not the rule. Another query is also avoided in _get_matching_supplier() which eventually calls ref(). ref() can be substituted with the private method since we are checking against the rule's existing route_id. Benchmark web_search_read by effective_vendor_id on 12,000 orderpoints | |Query Count|Exec Time| |------|-----------|---------| |Before|15,519 |17.46s | |After |722 |3.21s | opw-6186351 Forward-Port-Of: odoo/odoo#269165 Forward-Port-Of: odoo/odoo#268315
This update ensures credit limit warnings accurately reflect a customer's outstanding balance, including recent bank payments. Previously, the system incorrectly flagged over-limit warnings when bank payments were received. Now, the system correctly calculates outstanding balances, preventing unnecessary alerts and improving financial reporting.
Original PR description
Before this fix: The credit limit warning calculation only considered credit notes but ignored outstanding bank payments when computing the partner's effective outstanding balance. For example, if a…
Before this fix: The credit limit warning calculation only considered credit notes but ignored outstanding bank payments when computing the partner's effective outstanding balance. For example, if a customer had a credit limit of 1,000 and an invoice of 2,000 was created, then a bank payment of 1,500 was received, the warning would still incorrectly appear showing the customer exceeded their limit (2,000 > 1,000), even though the actual outstanding amount was only 500. After this fix: The credit limit warning now properly includes outstanding bank payments in the calculation. Two cases are handled: - Bank payments received but not yet matched to any invoice, these are identified by their open suspense account entry and deducted from the partner's outstanding exposure. - Bank payments already matched to the invoice, the reconciled amount is read from the invoice's receivable line and deducted accordingly. So with this fix, after a 1,500 bank payment, the system correctly recognises the outstanding amount as 500 and does not show a warning since it is within the 1,000 credit limit. task-5427613 Forward-Port-Of: odoo/enterprise#119829 Forward-Port-Of: odoo/enterprise#118957
This update resolves a bug where cancelled journal entries were incorrectly displayed in the reconciliation view, preventing successful reconciliation and causing data inconsistencies. The fix removes a previous refactor that inadvertently allowed cancelled entries to appear, ensuring accurate reconciliation processes.
Original PR description
Issue: Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused…
Issue: Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused reconciliation failures, no reconciliation happened, and the cancelled record remained in the view. This regression was introduced during a refactor to allow draft entries in the reconciliation view, where the posted-state condition was removed from the domain: Enterprise commit: https://github.com/odoo/enterprise/commit/003cffabda7d91a6d10d58942ed972ca5e17366d As a result, cancelled journal items also became visible, causing reconciliation attempts to fail while the records remained in the view. Also, we are not allowed to reconcile cancelled move lines, and we already have the validation for this [here](https://github.com/odoo/odoo/blame/a236f67776616f6facdefb0117a6ffdde9b7c84c/addons/account/models/account_move_line.py#L2627) Issue is reproducible on runbot. Here is the video reference: https://drive.google.com/file/d/1ojIDxHn5Yst8gVFy8JyhwtJoDSSSJsmK/view?usp=sharing - OPW: 6247870 Forward-Port-Of: odoo/enterprise#119017 Forward-Port-Of: odoo/enterprise#118773
This update resolves an issue where users were unintentionally able to select properties within the field selector widget. The fix adds a new option to the widget and includes a corresponding test to ensure proper functionality. This improves the user experience and prevents potential data entry errors.
Original PR description
- Backporting this [commit], for adding the `allow_properties` option to `field_selector` widget in `saas-18.2` for using the functionality in linked enterprise commit. - Also, added a test for `allow_properties` option. - For forward ports, only the test will be merged, as `allow_properties` is already included in the original commit. [commit]: https://github.com/odoo/odoo/pull/215767/changes/7cd18c07b5e008bff072d10375c908eb77434fde sentry-7378769090 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268545 Forward-Port-Of: odoo/odoo#257833
This update resolves an issue where users were encountering errors when attempting to use property fields within auto-fill fields in the Sign module. The fix restricts property field selection, ensuring data integrity and preventing the error. This improves the usability of the Sign module.
Original PR description
Currently, an error occurs when user tries to select a property field in auto field. Steps to replicate: - Install `sale_management` and `sign`. - Open Sales > Products > Products > Open any product.…
Currently, an error occurs when user tries to select a property field in auto field.
Steps to replicate:
- Install `sale_management` and `sign`.
- Open Sales > Products > Products > Open any product.
- From the Gear icon, Click Edit Properties and save the record.
- Enable Debug mode if you are using a version lower than 19.0 .
- Open Sign > Configuration > Field Types.
- Create a new Field > Give a name > Select model as `Product`.
- Select Field as `Property > Property 1` and click save.
Error:
- saas-18.3 and later:
```
File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py', line 57, in _check_auto_field_exists
auto_field_value = record.mapped(sign_type.auto_field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5472, in mapped
field = records._fields[field_name]
^^^^^^^^^^^^^^^
AttributeError: 'Property' object has no attribute '_fields'. Did you mean: 'field'?
```
- saas-18.2:
```
File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py, line 41, in _check_auto_field_exists
auto_field_value = record.mapped(sign_type.auto_field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5744, in mapped
if len(records) > PREFETCH_MAX:
^^^^^^^^^^^^
TypeError: object of type 'bool' has no len()
```
Cause:
- As the user gave auto fill field as a Property field the [line] called `mapped()` to access its value, this caused the error to occur.
- This occurs because `mapped()` expects a `recordset` (models.Model), but instead it receives a Property object, which does not have `_fields`.
Solution:
- Using `'allow_properties': 'False'`, the property fields wont appear in the list of field selection.
[line]: https://github.com/odoo/enterprise/blob/cdaeb79e1f623831fffa553dbb658698367c7e19/sign/models/sign_item_type.py#L41
sentry-7378769090
Forward-Port-Of: odoo/enterprise#119535
Forward-Port-Of: odoo/enterprise#113091This update resolves a potential error in the Hong Kong payroll calculations. Specifically, it prevents a division-by-zero issue that could occur when a resource calendar is missing or when an employee has zero hours per week. This ensures accurate payroll processing for Hong Kong businesses.
Original PR description
. Add a check for a null resource calendar and zero hours per week. task-6229271 Forward-Port-Of: odoo/enterprise#117685
This update corrects a problem where users could lose access to payrun details when switching between companies while running payroll. The fix ensures seamless access to payrun information regardless of company changes, improving payroll processing efficiency. This resolves a potential disruption for HR and finance teams.
Original PR description
todo details Task-6008140
This update resolves a technical issue where Odoo could crash if an offer didn't have a specified start date. The change ensures correct date calculations, particularly when running simulations for past employee versions, preventing inaccurate data and system instability. This improves the reliability of payroll and contract management.
Original PR description
Prevents various crashes from happening in case the contract_start_date isn't set on the offer as it's not required from SQL no related task
This update fixes an issue where subtype information was lost when messages were moved between records in Odoo. Now, users will see the subtype description in the chatter interface, providing clearer context for conversations. This enhancement improves communication and data transparency.
Original PR description
Currently, when we move a message from one record to another, the subtype is cleared.Because of this, the description is not visible and the transferred record shows it as empty. In this commit, we append the subtype description into the message body.So the user can see the subtype description in chatter. task-6227750 Forward-Port-Of: odoo/odoo#265003
This update resolves an error that occurred when sending invoices with Danish VAT numbers via Peppol. Now, customers in Denmark can use VAT numbers without the 'DK' prefix, and the system will correctly generate the Peppol endpoint. This ensures invoices are processed correctly and avoids potential errors during international electronic invoicing.
Original PR description
Current behavior before PR: - Currently, when we include `DK` country prefix in the VAT number, it automatically computes the peppol endpoint with the `DK` prefix for customer from Denmark. - However, there are cases where the VAT number may not include `DK` country prefix, while the corresponding peppol endpoint still does. - In such situations, when sending an invoice via Peppol, the following error occurs: "Errors occurred while creating the EDI document (format: UBL BIS Billing 3.0.12): The VAT of the customer should be prefixed with its country code." Desired behavior after PR is merged: - Now customer from Denmark can have vat without country prefix `DK` and peppol endpoint with prefix `DK` and can send invoice via peppol. task-6119563 Forward-Port-Of: odoo/odoo#263262
This update resolves an issue where generating PDFs with fillable forms containing no data would cause a system error. The fix skips the PDF merging process when no content is present, preventing an error and ensuring PDFs are always generated correctly. This improves the reliability of PDF reports.
Original PR description
Version: 19.0 Issue: - Uploading a fillable PDF with no filled-in values caused an error. Cause: - When all form fields are empty, nothing is drawn on the ReportLab overlay canvas, producing a 0-page PDF. - Calling getPage(0) on an empty page list raised an IndexError. Fix: - Skip the page merge when the overlay has no pages to avoid the IndexError on empty fillable forms. Forward-Port-Of: odoo/enterprise#119803 Forward-Port-Of: odoo/enterprise#119677
This update fixes a confusing error message displayed when sending invoices via Peppol. Previously, users received a generic 'no VAT' error, even when they'd correctly entered customer VAT information. Now, the system accurately identifies the missing Peppol VAT (like a Belgian Company Registry or French SIRET), guiding users to the correct data.
Original PR description
When a user sends a move via Peppol to a customer that has a VAT number set but not a Peppol endpoint, we show the user a generic error ("no VAT").
This makes the user confused, as he already filled the VAT field of his customer, It's the Peppol VAT that is missing (it could be: Belgian Company Registry, France SIRET, ...etc, depending on the customer's country)
This PR makes the error message more accurate by showing exactly the missing required field.
task-5499707
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#266993
Forward-Port-Of: odoo/odoo#245915This update fixes a visual issue in the portal chatter interface, specifically the alignment of the Follow/Unfollow button. The problem was caused by duplicate padding settings that have now been removed. This ensures a cleaner and more professional look for users interacting with shared projects.
Original PR description
**Steps to reproduce:** 1. Log in as a portal user. 2. Open a shared project and then open any task within it. 3. Observe the vertical spacing above the Follow/Unfollow button and the chatter…
**Steps to reproduce:** 1. Log in as a portal user. 2. Open a shared project and then open any task within it. 3. Observe the vertical spacing above the Follow/Unfollow button and the chatter component. **Issue:** The chatter UI has incorrect vertical spacing, causing elements like the Follow/Unfollow button to sit too far down and appear misaligned. **Cause:** The pt-2 padding class was hardcoded in two separate locations: 1. The compileChatter wrapper in project_sharing_form_compiler.js. 2. The portal.Chatter XML template. When combined this caused a double-padding effect forcing excessive space. **Fix:** Removed the hardcoded pt-2 class from both the JavaScript compiler wrapper and the core XML template. This eliminates the double-padding conflict. This resolves the alignment issue in Project Sharing and does not affect the layout or functionality of other portal components. task-4203362 Forward-Port-Of: odoo/odoo#268977 Forward-Port-Of: odoo/odoo#257490
This update resolves a technical issue where refund orders were generating duplicate invoice numbers for the Spanish tax authority (TicketBAI), leading to rejection of the refund documents. The fix ensures unique invoice numbers are used for refund orders by modifying how the document name is generated, preventing this duplication and improving compliance.
Original PR description
Refund orders use a display name based on the original ticket. The rectificativa was then submitted with a duplicate Serie/NumFactura and rejected with TicketBAI error 5040. Steps to reproduce:…
Refund orders use a display name based on the original ticket. The rectificativa was then submitted with a duplicate Serie/NumFactura and rejected with TicketBAI error 5040. Steps to reproduce: ------------------- * Enable TicketBAI for a Spanish company with POS * Create an order and complete payment (TicketBAI sent) * Refund that order from the POS and complete payment * Open the new TicketBAI XML (downloadable on the order in the backend) > Observation: `CabeceraFactura` `NumFactura` matches the original sale; tax authority returns 5040 (duplicate invoice for same issuer/series/year). Why the fix: ------------ The TicketBAI document `name` was set from `pos.order.name`, so `_get_tbai_seq_from_name` extracted the same numeric part as the original sale. `l10n_es_edi_tbai.document` derives Serie/Num from `name` via `_get_tbai_seq_from_name`. Refund POS names intentionally echo the original order label, so we derive the document name from the same components as non-refund orders (`get_reference_last_part()`), which is unique per receipt. opw-6067965 Forward-Port-Of: odoo/odoo#257475
27 changes
New functionality added to Odoo
This update adds support for the Hacienda Foral de Navarra tax agency within Odoo's SII invoicing system. It adjusts the system to handle the specific XML format and endpoint requirements of this agency, ensuring accurate invoice submissions. This expansion broadens Odoo's compliance capabilities for businesses operating in the Navarra region.
Original PR description
The Hacienda Foral de Navarra uses the same SII XML format as AEAT but sends invoices to a different endpoint. Additionally, Navarra requires explicit XML namespace declarations in the SOAP envelope header, which the standard zeep serializer does not include by default. This adds the Navarra tax agency as a new option in the company SII configuration, defines its production and test endpoints, and injects the required namespaces in the request header when the Navarra agency is selected. task-5946583 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268438 Forward-Port-Of: odoo/odoo#263048
Resolved issues and error corrections
This update resolves an issue where the 'Show Sub-Tasks' option was incorrectly displayed in the mobile My Tasks menu. The fix ensures that this button is hidden in project_todo views, aligning with the functionality of To-do items which do not support subtasks. This improves the user experience on mobile devices.
Original PR description
Steps to reproduce: - Install project - Open the My Tasks menu on mobile view Issue: The "Show Sub-Tasks" option was visible in the My Tasks menu on mobile view. Cause: The condition only applied `showTaskOptions` to the desktop part of the expression, so the dropdown was still rendered on mobile when there were no embedded actions. Apply `showTaskOptions` to the whole condition to properly hide the dropdown in the My Tasks mobile view. Fix-2: Steps to reproduce: - Install project_todo Issue: The Show Sub-Tasks button was visible in project_todo views even though To-do items do not support subtasks. Fix: Ensure that the Show Sub-Tasks button is hidden in project_todo views. task-6026239 Forward-Port-Of: odoo/odoo#255283
This update fixes a visual issue in the portal chatter interface where elements like the Follow/Unfollow button appeared misaligned due to excessive padding. The fix removed a duplicated padding setting that was previously hardcoded in the system, ensuring a cleaner and more professional look for users. This improves the overall user experience within the portal.
Original PR description
**Steps to reproduce:** 1. Log in as a portal user. 2. Open a shared project and then open any task within it. 3. Observe the vertical spacing above the Follow/Unfollow button and the chatter…
**Steps to reproduce:** 1. Log in as a portal user. 2. Open a shared project and then open any task within it. 3. Observe the vertical spacing above the Follow/Unfollow button and the chatter component. **Issue:** The chatter UI has incorrect vertical spacing, causing elements like the Follow/Unfollow button to sit too far down and appear misaligned. **Cause:** The pt-2 padding class was hardcoded in two separate locations: 1. The compileChatter wrapper in project_sharing_form_compiler.js. 2. The portal.Chatter XML template. When combined this caused a double-padding effect forcing excessive space. **Fix:** Removed the hardcoded pt-2 class from both the JavaScript compiler wrapper and the core XML template. This eliminates the double-padding conflict. This resolves the alignment issue in Project Sharing and does not affect the layout or functionality of other portal components. task-4203362 Forward-Port-Of: odoo/odoo#268977 Forward-Port-Of: odoo/odoo#257490
This update resolves an issue where cancelled journal entries were incorrectly showing in the reconciliation view, preventing successful reconciliation and causing data inconsistencies. The fix removes a previous refactor that allowed draft entries, ensuring cancelled entries are properly excluded from reconciliation processes.
Original PR description
Issue: Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused…
Issue: Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused reconciliation failures, no reconciliation happened, and the cancelled record remained in the view. This regression was introduced during a refactor to allow draft entries in the reconciliation view, where the posted-state condition was removed from the domain: Enterprise commit: https://github.com/odoo/enterprise/commit/003cffabda7d91a6d10d58942ed972ca5e17366d As a result, cancelled journal items also became visible, causing reconciliation attempts to fail while the records remained in the view. Also, we are not allowed to reconcile cancelled move lines, and we already have the validation for this [here](https://github.com/odoo/odoo/blame/a236f67776616f6facdefb0117a6ffdde9b7c84c/addons/account/models/account_move_line.py#L2627) Issue is reproducible on runbot. Here is the video reference: https://drive.google.com/file/d/1ojIDxHn5Yst8gVFy8JyhwtJoDSSSJsmK/view?usp=sharing - OPW: 6247870 Forward-Port-Of: odoo/enterprise#119017 Forward-Port-Of: odoo/enterprise#118773
This update corrects a potential error in the Hong Kong payroll calculations. Specifically, it now checks for situations where a company's resource calendar is missing or if an employee has zero hours per week, preventing a division-by-zero error. This ensures accurate payroll processing for Hong Kong businesses.
Original PR description
. Add a check for a null resource calendar and zero hours per week. task-6229271 Forward-Port-Of: odoo/enterprise#117685
This update resolves an issue where the database upgrade process failed due to dependency on a live NAV service during the Hungarian chart template reload. The fix bypasses the credential validation step, allowing the upgrade to proceed without relying on external connectivity, ensuring smoother updates.
Original PR description
Steps to Reproduce: * Create a Hungarian company on 19.0 (or earlier). * Configure NAV credentials through Settings. * Upgrade the database to saas~19.2. Issue: * The upgrade fails while reloading…
Steps to Reproduce:
* Create a Hungarian company on 19.0 (or earlier).
* Configure NAV credentials through Settings.
* Upgrade the database to saas~19.2.
Issue:
* The upgrade fails while reloading the Hungarian chart template.
```python3
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-19.2/odoo/service/server.py", line 1626, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/tools/func.py", line 65, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/registry.py", line 202, in new
load_modules(
File "/home/odoo/src/odoo/saas-19.2/odoo/modules/loading.py", line 502, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/saas-19.2/odoo/modules/migration.py", line 215, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, version)
File "/home/odoo/src/odoo/saas-19.2/odoo/modules/migration.py", line 253, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu/migrations/3.1/end-migrate_update_taxes.py", line 7, in migrate
env['account.chart.template'].try_loading('hu', company)
File "/home/odoo/src/odoo/saas-19.2/addons/account/models/chart_template.py", line 181, in try_loading
return self._load(template_code, company, install_demo, force_create)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/template_hu.py", line 11, in _load
company._l10n_hu_edi_configure_company()
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_company.py", line 79, in _l10n_hu_edi_configure_company
res_config_id = self.env['res.config.settings'].create({
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/decorators.py", line 363, in create
return method(self, vals_list)
^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/hr_payroll/models/res_config_settings.py", line 39, in create
return super().create(vals_list)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/decorators.py", line 363, in create
return method(self, vals_list)
^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_config_settings.py", line 48, in create
record.company_id._l10n_hu_edi_test_credentials()
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_company.py", line 107, in _l10n_hu_edi_test_credentials
raise UserError(
odoo.exceptions.UserError: Helytelen NAV hitelesítő adatok! Ellenőrizze, hogy a cég adószáma helyesen van-e beállítva.
Hiba részletei: HTTPSConnectionPool(host='api.onlineszamla.nav.gov.hu', port=443): Max retries exceeded with url: /invoiceService/v3/tokenExchange (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x798a970f1fd0>: Failed to establish a new connection: [Errno 111] Connection refused'))
```
Cause:
* Since the introduction of the Hungarian tax migration using `account.chart.template.try_loading('hu', company)` in saas~19.1, upgrades reload the Hungarian chart template.
* When `l10n_hu_edi` is installed, chart template loading triggers `_l10n_hu_edi_configure_company()`, which performs NAV credential validation through `_l10n_hu_edi_test_credentials()`.
* The credential validation performs a live request to the NAV service, making the upgrade dependent on an external service. https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_hu_edi/models/res_company.py#L99-L109 https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_hu_edi/models/template_hu.py#L11
Fix:
* Bypass NAV credential validation during the migration.
* The migration only updates localization data and does not modify the configured EDI credentials.
* This prevents temporary NAV connectivity issues from aborting the upgrade process.
see https://github.com/odoo/odoo/pull/253556
opw-6253523
upg-4326247
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#268178This update fixes a visual glitch in the website builder's carousel feature. Previously, changing image sizes or adding borders could cause layout issues and a jarring effect. The update now automatically adjusts carousel item heights to maintain a consistent display, ensuring a smoother and more reliable user experience.
Original PR description
In a carousel snippet all carousel items keep a consistent height to prevent layout jitter when sliding. The height synchronization was broken in the `s_carousel` snippet when item dimensions were modified via border overlays (padding changes). The issue was caused by the resize event being triggered from a different jQuery instance than the one used to register the height synchronization listener, preventing the handler from being executed. Steps to reproduce (Border Overlay): 1. In the website builder, add the `s_carousel` snippet. 2. Drag the lower border overlay so that the height of an image increases. 3. Navigate through the carousel and observe height changes causing a jitter effect. Task: [5135520](https://www.odoo.com/odoo/project/974/tasks/5135520) Forward-Port-Of: odoo/odoo#268722 Forward-Port-Of: odoo/odoo#265549
This update fixes an issue where subtype information was lost when messages were moved between records in Odoo. Now, users will see the subtype description clearly in the chatter interface, providing better context and understanding of the message's purpose. This enhances communication and reduces potential confusion.
Original PR description
Currently, when we move a message from one record to another, the subtype is cleared.Because of this, the description is not visible and the transferred record shows it as empty. In this commit, we append the subtype description into the message body.So the user can see the subtype description in chatter. task-6227750 Forward-Port-Of: odoo/odoo#265003
This update resolves an error that occurred when sending invoices with Danish VAT numbers via Peppol. Now, customers in Denmark can use VAT numbers without the 'DK' prefix, and the system will automatically generate the correct Peppol endpoint. This ensures invoices are properly processed and avoids errors during Peppol transmission.
Original PR description
Current behavior before PR: - Currently, when we include `DK` country prefix in the VAT number, it automatically computes the peppol endpoint with the `DK` prefix for customer from Denmark. - However, there are cases where the VAT number may not include `DK` country prefix, while the corresponding peppol endpoint still does. - In such situations, when sending an invoice via Peppol, the following error occurs: "Errors occurred while creating the EDI document (format: UBL BIS Billing 3.0.12): The VAT of the customer should be prefixed with its country code." Desired behavior after PR is merged: - Now customer from Denmark can have vat without country prefix `DK` and peppol endpoint with prefix `DK` and can send invoice via peppol. task-6119563 Forward-Port-Of: odoo/odoo#263262
This update clarifies error messages when sending invoices via Peppol. Previously, users received a generic "no VAT" message, which was confusing. Now, the system accurately identifies the missing Peppol VAT information (like a Belgian Company Registry), guiding users to complete the required details for successful transmission.
Original PR description
When a user sends a move via Peppol to a customer that has a VAT number set but not a Peppol endpoint, we show the user a generic error ("no VAT").
This makes the user confused, as he already filled the VAT field of his customer, It's the Peppol VAT that is missing (it could be: Belgian Company Registry, France SIRET, ...etc, depending on the customer's country)
This PR makes the error message more accurate by showing exactly the missing required field.
task-5499707
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#266993
Forward-Port-Of: odoo/odoo#245915This update resolves a technical issue where refund orders were generating duplicate invoice numbers for the Spanish tax authority (TicketBAI). The fix ensures unique invoice numbers are used for refund orders, preventing rejection by the tax authority and streamlining the refund process. This improves compliance and avoids delays.
Original PR description
Refund orders use a display name based on the original ticket. The rectificativa was then submitted with a duplicate Serie/NumFactura and rejected with TicketBAI error 5040. Steps to reproduce:…
Refund orders use a display name based on the original ticket. The rectificativa was then submitted with a duplicate Serie/NumFactura and rejected with TicketBAI error 5040. Steps to reproduce: ------------------- * Enable TicketBAI for a Spanish company with POS * Create an order and complete payment (TicketBAI sent) * Refund that order from the POS and complete payment * Open the new TicketBAI XML (downloadable on the order in the backend) > Observation: `CabeceraFactura` `NumFactura` matches the original sale; tax authority returns 5040 (duplicate invoice for same issuer/series/year). Why the fix: ------------ The TicketBAI document `name` was set from `pos.order.name`, so `_get_tbai_seq_from_name` extracted the same numeric part as the original sale. `l10n_es_edi_tbai.document` derives Serie/Num from `name` via `_get_tbai_seq_from_name`. Refund POS names intentionally echo the original order label, so we derive the document name from the same components as non-refund orders (`get_reference_last_part()`), which is unique per receipt. opw-6067965 Forward-Port-Of: odoo/odoo#257475
This update resolves an issue where the 'Add to Cart' button wasn't functioning correctly for alternative products on the website. The fix ensures that users can successfully add these alternative products to their cart, improving the shopping experience. The change was made to correctly identify the button element within the product display.
Original PR description
Steps to reproduce: --- - Install `website_sale`. - Create a product and from the Sales tab, add alternative products, making sure all products are published on the website. - Open the main product…
Steps to reproduce: --- - Install `website_sale`. - Create a product and from the Sales tab, add alternative products, making sure all products are published on the website. - Open the main product on the website. - In the alternative products section, open the editor, click the `brush` icon under `card design`. - Under Actions > Buttons, click on the `cart` icon. - Save the changes and click the `Add to Cart` button on an alternative product. Issue: --- - Clicking the `Add to Cart` button on alternative products does nothing. Root cause: --- - At [1], the `AddToCart` interaction uses the selector `.oe_website_sale button[name="add_to_cart"]` to find and attach click handlers. When the dynamic snippet renders alternative products, `startInteractions` is called on the `.dynamic_snippet_template` div. It searches for the button inside that div, but at [2], no element wrapping the button has the `oe_website_sale` class in the rendered product card template. So the selector matches nothing, and no click handler is attached. Fix: --- - Add `oe_website_sale` to the `o_wsale_product_btn` wrapper div in the product card template so the button becomes a descendant of `.oe_website_sale` within the injected content, allowing the interaction to attach correctly. [1]https://github.com/odoo/odoo/blob/cbc446bfcaeeb4787cb512ddffbbeb2a154a6dde/addons/website_sale/static/src/interactions/add_to_cart.js#L5 [2]https://github.com/odoo/odoo/blob/cbc446bfcaeeb4787cb512ddffbbeb2a154a6dde/addons/website_sale/templates/snippets/product_snippet_template_data.xml#L95-L113 opw-6197375 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263253
This update resolves an issue where the CODA integration incorrectly prioritized journals. The change creates two journals, selecting the one with the lower ID by default. This ensures the correct currency journal takes precedence, improving the accuracy of CODA reporting and financial data.
Original PR description
The journals[0] is not ideal if the user has one journal with no currency and one with currency that fits the CODA's currency. We'll have two journals and we take the first one at random. Thus if it has a lower id, the journal with no currency will be selected instead of the one whose currency is correct. The latter should take precedence over the former. task-6226835
This update prevents empty ICS calendar files from being generated when users attempt to add open shifts to their calendars. Previously, the system would create an empty file when a matching shift slot wasn't found. Now, the ‘Add to Calendar’ button is hidden and the ICS file is only generated when a valid shift slot is linked to an employee.
Original PR description
**Step:** - install planning - create a resource - create an open shift for a future date - in Gantt view: - publish shift and select the created resource - click “Publish & Send” - check the email and click “Add to Calendar” **Issue:** Currently, clicking “Add to Calendar” generates an empty ics file. **Reason:** During ics file generation, the planning token to find a slot using the planning date and employee. but, no matching slot is found, so the process returns an empty slot, resulting in an empty ics file. **Fix:** Generate the `planning_url_ics` only when a slot is linked with an employee. Otherwise, hide the “Add to Calendar” button and do not generate the ics file. Forward-Port-Of: odoo/enterprise#119838 Forward-Port-Of: odoo/enterprise#118978
This update ensures that new lines added to a sale order from a delivery always include the product's full description, rather than just the display name. Previously, this caused inconsistencies in sales order reporting and tracking. This fix improves data accuracy and reporting reliability.
Original PR description
When a line is added to a delivery related to a sale order, the corresponding line created in the sale order uses only the display_name as a description. This commit makes sure that if a previous SO line exists for the product, the new line uses the same description. Otherwise we call `get_product_multiline_description_sale()` Steps to reproduce: - Create a product with a description in the Sales tab - Create a quotation with any product (can be said product) and confirm it - Go to the delivery action, and add a new line with the product in the view, set delivered quantity to 1 - After Validating, you'll notice that the new line in the Quotation doesn't have a description opw-6175891 Forward-Port-Of: odoo/odoo#267425 Forward-Port-Of: odoo/odoo#262276
This update resolves a crash in the payslip PDF report that occurred when employees didn't have a bank account configured. The fix adds a conditional check to the report template, ensuring the bank account section is only displayed if an employee has at least one linked bank account. This improves report reliability for all users.
Original PR description
The payslip PDF report crashed when the employee had no bank account configured because the template tried to access bank_account_ids[0] unconditionally. Add a t-if guard on the bank account div to only render it when the employee has at least one bank account linked. Forward-Port-Of: odoo/enterprise#115893
This update enhances the SMS account registration process by adding clear error messages to the IAP system. Specifically, it now identifies issues like unsupported countries or inactive database records, providing better guidance to users. This improves the reliability and user experience of the SMS feature.
Original PR description
This commit add some error messages (country_not_supported, not_active_db) received by IAP. Task-6240200 IAP: https://github.com/odoo/iap-apps/pull/1612 Forward-Port-Of: odoo/odoo#267459
Previously, a sign request scheduled for a later date would immediately appear on the portal for the signer. This fix corrects a technical issue where the system incorrectly displayed scheduled requests. Now, requests are only shown on the portal after the scheduled date, ensuring a smoother user experience.
Original PR description
## Issue When scheduling a sign request, the request appears immediately on the portal for the requested signer. ## Steps to reproduce 1. Install *Sign* (`sign`) 2. Create and send a sign request -…
## Issue
When scheduling a sign request, the request appears immediately on the portal for the requested signer.
## Steps to reproduce
1. Install *Sign* (`sign`)
2. Create and send a sign request
- Signer 1: Any portal user (e.g., Joel Willis)
- Use the clock icon to schedule the signature request to a future date
3. Log in as the portal user used in step 2
4. Navigate to Signature Requests
5. **The signature request already appears in the list, even though it was scheduled for a future date.**
## Cause
The portal filters the sign requests shown based on the `is_mail_sent` field, which does not properly reflect when the signature request is shared to the user.
https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/controllers/portal.py#L40
In fact, when scheduling a signature request, the `is_mail_sent` field is unconditionally set to `True`, even if the signature request will only be sent later.
https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/models/sign_request_item.py#L289
## Fix
Since the `"scheduled"` `sign_request_item.state` option introduced by https://github.com/odoo/enterprise/commit/ed8d5a653e01b1378f0020e2f7a7c2d39fadf3e9 in 19.1, we can easily filter out the sign request items that are scheduled. That state is automatically updated by the `_cron_update_state`, introduced by the same commit as the `"scheduled"` option.
https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/models/sign_request.py#L493-L503
opw-6227472
Forward-Port-Of: odoo/enterprise#118491This update ensures that fiscal categories and related products are automatically loaded when using the self-order blackbox feature. Previously, this process was inconsistent, leading to potential errors. This change improves the reliability and accuracy of self-order transactions.
Original PR description
Before this commit, the fiscal category and the products work in and work out weren't necessarily automatically loaded when using the self with a blackbox, it is now the case. Forward-Port-Of: odoo/enterprise#117288 Forward-Port-Of: odoo/enterprise#117044
This update fixes an issue where tax calculations within Point of Sale (POS) were consistently showing positive tax base amounts, regardless of the actual tax amount. This resulted in inaccurate tax reporting in the accounting system. The fix ensures that tax base amounts accurately reflect the tax liability, aligning POS transactions with financial reporting.
Original PR description
Issue: While creating an account move line from POS, the tax_base_amount of tax line is always positive although it might be negative. Steps to reproduce: - with point_of_sale and account_reports - open register - Sale a product with taxes - close register - Go to Accounting -> Tax Report - Switch to current month - On a line click on the tree dots -> Audit Current Behavior: - POS AMLs always have a positive tax base amount for tax lines. Expected behavior: - POS AMLs have a positive or negative base amount for tax lines depending on the move. opw-5975658 Forward-Port-Of: odoo/odoo#265479
This update fixes an issue where untaxed invoice lines in German accounting reports incorrectly inherited datev code from the previous line. The fix ensures that untaxed lines now properly display an empty datev code, aligning with German tax regulations and improving the accuracy of Datev reports. This resolves a reporting discrepancy impacting financial data.
Original PR description
**PROBLEM** Untaxed move lines would take the datev code of the previous line instead of having no datev code like they should. **STEP TO REPRODUCE** 1. On a german company, create an invoice with a line with tax 19% I, and a line that is untaxed (with a non-null price). 2. On the general ledger, generate the datev zip. 3. Unzip, and open the account entries csv, and notice the 2nd line of the invoice as the datev code set to something instead of it being empty (column BU-Schlüssel). opw-6141003 Forward-Port-Of: odoo/enterprise#118486
This update resolves an issue where invoices for Persona Natura customers in Colombia were incorrectly formatted for export to the DIAN tax authority. The fix ensures the correct XML structure is generated, addressing a misinterpretation of customer types and preventing export errors. This ensures accurate tax reporting for Colombian businesses.
Original PR description
Issue: Colombian partner being Persona Natura are misinterpreted as Person Juridica. It raises issue while exporting XMLs for dian. Steps to reproduce: - In a Colombian company - Create a Customer with NIT and "Obligaciones y Responsabilidades" to "R-99-PN" - Create an invoice - Send the invoice Current behavior: - node <cbc:AdditionalAccountID> is set to 1 and node PartyIdentification is missing Expected behavior: - node <cbc:AdditionalAccountID> is set to 2 and there is a PartyIdentification node Cause: Colombian partners having a NIT have is_company to True. However, Persona Natura have NIT but aren't companies. opw-6206308 Forward-Port-Of: odoo/enterprise#118193
This update resolves an issue where DHL delivery confirmations were failing due to incorrect scheduled dates (past or missing). The system now automatically sets a future delivery date (one hour ahead) to prevent the error and ensure successful order confirmations.
Original PR description
When confirming the delivery of an order using DHL shipping method we get an error that the date must be in the future. This happens when the scheduled date was not set, or set for a time in the past. This commit automatically sets the time to 1 hour in the future and bypasses the user error. opw-6148927 Forward-Port-Of: odoo/enterprise#116211
This update fixes an issue where the 'Cancel Reason' wasn't being properly transmitted to the Peruvian EDI (SUNAT) documents when reversing invoices. Now, the credit note accurately reflects both the refund code and the user-provided cancellation explanation, ensuring compliance with Peruvian regulations. This improves data accuracy for financial reporting and audit trails.
Original PR description
### Issue before this commit: When reversing an invoice in a Peruvian company, the "Cancel Reason" entered in the credit note window is not propagated to the Peruvian EDI tab of the resulting Credit…
### Issue before this commit: When reversing an invoice in a Peruvian company, the "Cancel Reason" entered in the credit note window is not propagated to the Peruvian EDI tab of the resulting Credit Note. Only the Credit Reason is successfully reported. ### Steps to reproduce the issue: 1. Download Accounting and l10n_pe 2. Switch to PE company 3. Create an invoice and confirm it 4. Create a credit note for the invoice with a cancel reason and a credit reason and click the reverse button 5. See that in the Peruvian EDI tab only the Credit Reason is reported but not the Cancel Reason ### Cause of the issue: In the l10n_pe_edi module, the override of the _prepare_default_reversal method maps the l10n_pe_edi_refund_reason to the new move's values, but completely omits the mapping of the wizard's textual reason field to the l10n_pe_edi_cancel_reason field of the resulting credit note. ### Reason to introduce the fix: To ensure the generated credit notes contain all required information for the Peruvian EDI (SUNAT). Mapping the cancel reason guarantees that the electronic document accurately reflects both the refund code and the descriptive cancellation text provided by the user. opw-6238525 Forward-Port-Of: odoo/enterprise#119610 Forward-Port-Of: odoo/enterprise#118479
This update fixes an issue where grouped payments were incorrectly linking to unrelated invoices after reconciliation. The process has been updated to ensure payments are accurately associated with the invoices they cover, preventing data duplication and improving payment reconciliation accuracy. This resolves a previous bug impacting payment reporting.
Original PR description
Steps to reproduce --- 1. Register a grouped customer payment over several invoices, leaving one of them only partially paid. 2. Register a second grouped payment over two invoices: the partially…
Steps to reproduce --- 1. Register a grouped customer payment over several invoices, leaving one of them only partially paid. 2. Register a second grouped payment over two invoices: the partially paid one and a brand new invoice. 3. Open the first payment, its "Reconciled Invoices" smart button now lists the new invoice from the second payment, which it never paid. Issue --- The smart button is built from the stored `invoice_ids` many2many, which shares its relation table with `account.move.matched_payment_ids`. After reconciling, the register wizard links the payment to its invoices with `lines.move_id.matched_payment_ids += payment` at https://github.com/odoo/odoo/blob/f726393267a28cedd5febd2106de17ae3838f3ff/addons/account/wizard/account_payment_register.py#L1212. When the payment groups several invoices, `lines.move_id` is a multi-record recordset. Reading `matched_payment_ids` on it returns the union of the payments already linked to all those invoices, and `+=` writes that union back to every invoice as a `(6, 0, ...)` replace command. So an invoice already paid by an earlier payment spreads that earlier payment onto every other invoice grouped in the new one, including brand new invoices, which then wrongly appear on the earlier payment. opw-6188013 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267968
This update removes a specific footer message from invoices when the PEPPOL process isn't used, which was inappropriate for Business-to-Consumer (B2C) customers. The change ensures a cleaner and more professional invoice experience for B2C users. This improves clarity and aligns with customer communication standards.
Original PR description
Currently, if the invoice was not sent through PEPPOL, it is indicated in the mail footer. However, this message is not appropriate for B2C customers. To avoid this, we remove this footer for customers with empty or '/' VAT (B2C). task-6167439 Forward-Port-Of: odoo/odoo#268826 Forward-Port-Of: odoo/odoo#262412
This update significantly speeds up the process of adding and removing participants from marketing campaigns. By optimizing the underlying code, the sync time has been reduced from over 51 seconds to just 0.65 seconds, even with a large campaign of 115,000 participants. This improves campaign performance and responsiveness.
Original PR description
Replace search_read with search_fetch to avoid unnecessary _read_format call in backend context. Use OrderedSet instead of a custom _uniquify_list helper to get O(1) membership tests when computing records to add or remove from campaigns. Benchmark on a campaign with 115k participants: | Before PR | After PR | |:---------:|:--------:| | 51.71s | 0.652s | opw-6055334 Forward-Port-Of: odoo/enterprise#119589 Forward-Port-Of: odoo/enterprise#117656
24 changes
New functionality added to Odoo
This update expands Odoo's SII (Société d'Investissements et d'Innovation) functionality to include support for the Hacienda Foral de Navarra tax agency in Spain. It adds a new configuration option to handle the agency's specific invoice formatting and endpoint requirements, ensuring accurate tax reporting for businesses operating in the Navarra region. This improves compliance and supports a wider range of Spanish businesses.
Original PR description
The Hacienda Foral de Navarra uses the same SII XML format as AEAT but sends invoices to a different endpoint. Additionally, Navarra requires explicit XML namespace declarations in the SOAP envelope header, which the standard zeep serializer does not include by default. This adds the Navarra tax agency as a new option in the company SII configuration, defines its production and test endpoints, and injects the required namespaces in the request header when the Navarra agency is selected. task-5946583 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268438 Forward-Port-Of: odoo/odoo#263048
Resolved issues and error corrections
This update optimizes how Odoo identifies default suppliers for purchase orders, significantly speeding up the process. By eliminating redundant queries, the system now responds much faster – reducing query counts by over 90%. This improvement directly impacts order processing speed and efficiency.
Original PR description
Currently, computing effective_vendor_id and supplier_id_placeholder presents N+1 query issues. Since every call to _get_default_rule() eventually triggers a _read_group() in _search_rule_for_warehouses(). However we can get rid of this entirely, since the subsequent call to _get_matching_supplier() with an empty values dict depends entirely on the product and not the rule. Another query is also avoided in _get_matching_supplier() which eventually calls ref(). ref() can be substituted with the private method since we are checking against the rule's existing route_id. Benchmark web_search_read by effective_vendor_id on 12,000 orderpoints | |Query Count|Exec Time| |------|-----------|---------| |Before|15,519 |17.46s | |After |722 |3.21s | opw-6186351 Forward-Port-Of: odoo/odoo#268315
This update prevents empty ICS calendar files from being generated when users attempt to add open shifts to their calendars. Previously, the system would create an empty file when a matching shift slot wasn't found. Now, the ‘Add to Calendar’ button is hidden and the ICS file is only generated when a valid shift slot is linked to an employee.
Original PR description
**Step:** - install planning - create a resource - create an open shift for a future date - in Gantt view: - publish shift and select the created resource - click “Publish & Send” - check the email and click “Add to Calendar” **Issue:** Currently, clicking “Add to Calendar” generates an empty ics file. **Reason:** During ics file generation, the planning token to find a slot using the planning date and employee. but, no matching slot is found, so the process returns an empty slot, resulting in an empty ics file. **Fix:** Generate the `planning_url_ics` only when a slot is linked with an employee. Otherwise, hide the “Add to Calendar” button and do not generate the ics file. Forward-Port-Of: odoo/enterprise#119838 Forward-Port-Of: odoo/enterprise#118978
This update resolves a bug where splitting orders incorrectly applied tax settings. When an order was split, the new order defaulted to the system's standard settings instead of the original order's tax configuration. This change ensures that split orders accurately reflect the tax settings of the original order, improving financial reporting and accuracy.
Original PR description
When splitting an order, `createNewOrder()` was called with no preset,so the new order silently fell back to the config's default preset. The moved orderlines kept their original price_unit and tax_ids while the new order header used the wrong fiscal_position_id and pricelist_id. Steps to reproduce: - Order with two products, switch to a preset that adds tax - Split, select one line, Payment, Validate - Pay the other line, Validate - open order in backend, first line has default price_unit and no tax, second line has correct price_unit and tax -opw-6246434 Forward-Port-Of: odoo/odoo#268862 Forward-Port-Of: odoo/odoo#268772
This update resolves a bug where cancelled journal entries were incorrectly displayed in the reconciliation view, preventing successful reconciliation and causing data inconsistencies. The fix removes a previous refactor that allowed draft entries, which inadvertently exposed cancelled entries. This ensures accurate reconciliation processes.
Original PR description
Issue: Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused…
Issue: Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused reconciliation failures, no reconciliation happened, and the cancelled record remained in the view. This regression was introduced during a refactor to allow draft entries in the reconciliation view, where the posted-state condition was removed from the domain: Enterprise commit: https://github.com/odoo/enterprise/commit/003cffabda7d91a6d10d58942ed972ca5e17366d As a result, cancelled journal items also became visible, causing reconciliation attempts to fail while the records remained in the view. Also, we are not allowed to reconcile cancelled move lines, and we already have the validation for this [here](https://github.com/odoo/odoo/blame/a236f67776616f6facdefb0117a6ffdde9b7c84c/addons/account/models/account_move_line.py#L2627) Issue is reproducible on runbot. Here is the video reference: https://drive.google.com/file/d/1ojIDxHn5Yst8gVFy8JyhwtJoDSSSJsmK/view?usp=sharing - OPW: 6247870 Forward-Port-Of: odoo/enterprise#119017 Forward-Port-Of: odoo/enterprise#118773
This update removes a duplicate button from the channel management interface. Previously, users encountered errors when attempting to copy channels, and this feature didn't provide a useful function. This change simplifies the channel management process and resolves a minor usability issue.
Original PR description
duplicating channels does not provide much value. when you try to copy channel error comes like `you do not have enough rights to access the field ai_agent_id on Discussion Channel (discuss.channel).` now we are remove the duplicate button from channels form view cog menu as its does make sense to use it there at all. task-5494736 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268999
This update fixes a visual issue where the carousel display would sometimes become unstable when images were resized or changed. The fix uses a new monitoring system to ensure all carousel items maintain a consistent height, preventing layout problems and improving the overall user experience. This ensures a smoother and more reliable carousel display for website visitors.
Original PR description
In a carousel snippet all carousel items keep a consistent height to prevent layout jitter when sliding. The height synchronization was broken in the `s_carousel` snippet when item dimensions were modified via border overlays (padding changes). The issue was caused by the resize event being triggered from a different jQuery instance than the one used to register the height synchronization listener, preventing the handler from being executed. Steps to reproduce (Border Overlay): 1. In the website builder, add the `s_carousel` snippet. 2. Drag the lower border overlay so that the height of an image increases. 3. Navigate through the carousel and observe height changes causing a jitter effect. Task: [5135520](https://www.odoo.com/odoo/project/974/tasks/5135520) Forward-Port-Of: odoo/odoo#268722 Forward-Port-Of: odoo/odoo#265549
This update fixes an issue where subtype information was lost when moving messages within Odoo. Now, users will see the subtype description in chatter, providing clearer context for conversations and improving message clarity. This enhancement ensures users have a complete view of message details.
Original PR description
Currently, when we move a message from one record to another, the subtype is cleared.Because of this, the description is not visible and the transferred record shows it as empty. In this commit, we append the subtype description into the message body.So the user can see the subtype description in chatter. task-6227750 Forward-Port-Of: odoo/odoo#265003
This update resolves an error that occurred when sending invoices with Danish VAT numbers via Peppol. Now, customers in Denmark can use VAT numbers without the 'DK' prefix, and the system will correctly generate the Peppol endpoint with the required prefix. This ensures invoices are processed correctly and avoids errors during international electronic invoicing.
Original PR description
Current behavior before PR: - Currently, when we include `DK` country prefix in the VAT number, it automatically computes the peppol endpoint with the `DK` prefix for customer from Denmark. - However, there are cases where the VAT number may not include `DK` country prefix, while the corresponding peppol endpoint still does. - In such situations, when sending an invoice via Peppol, the following error occurs: "Errors occurred while creating the EDI document (format: UBL BIS Billing 3.0.12): The VAT of the customer should be prefixed with its country code." Desired behavior after PR is merged: - Now customer from Denmark can have vat without country prefix `DK` and peppol endpoint with prefix `DK` and can send invoice via peppol. task-6119563 Forward-Port-Of: odoo/odoo#263262
This update resolves an issue where refund orders were generating duplicate invoice numbers for the Spanish tax authority (TicketBAI). The fix ensures unique invoice numbers are used for refunds, preventing rejection by the tax authority and streamlining the refund process. This improves compliance and reduces manual intervention.
Original PR description
Refund orders use a display name based on the original ticket. The rectificativa was then submitted with a duplicate Serie/NumFactura and rejected with TicketBAI error 5040. Steps to reproduce:…
Refund orders use a display name based on the original ticket. The rectificativa was then submitted with a duplicate Serie/NumFactura and rejected with TicketBAI error 5040. Steps to reproduce: ------------------- * Enable TicketBAI for a Spanish company with POS * Create an order and complete payment (TicketBAI sent) * Refund that order from the POS and complete payment * Open the new TicketBAI XML (downloadable on the order in the backend) > Observation: `CabeceraFactura` `NumFactura` matches the original sale; tax authority returns 5040 (duplicate invoice for same issuer/series/year). Why the fix: ------------ The TicketBAI document `name` was set from `pos.order.name`, so `_get_tbai_seq_from_name` extracted the same numeric part as the original sale. `l10n_es_edi_tbai.document` derives Serie/Num from `name` via `_get_tbai_seq_from_name`. Refund POS names intentionally echo the original order label, so we derive the document name from the same components as non-refund orders (`get_reference_last_part()`), which is unique per receipt. opw-6067965 Forward-Port-Of: odoo/odoo#257475
This update resolves a potential error in the Hong Kong payroll calculations. The fix prevents a division-by-zero issue that could occur when a resource calendar is missing or when an employee has zero hours per week. This ensures accurate payroll processing for Hong Kong businesses.
Original PR description
. Add a check for a null resource calendar and zero hours per week. task-6229271 Forward-Port-Of: odoo/enterprise#117685
This update fixes an issue where the product image carousel wouldn't scroll correctly after a product variant was selected on the e-commerce site. The fix ensures that the carousel properly updates and responds to user interactions like scrolling, improving the shopping experience. This was caused by a technical glitch in how the system handles carousel updates.
Original PR description
Steps to produce: --- - Install `website_sale` module. - Create a product with a variant and add the images from the sale tab. - Go to the product on the e-commerce and change the variant. - Attempt…
Steps to produce: --- - Install `website_sale` module. - Create a product with a variant and add the images from the sale tab. - Go to the product on the e-commerce and change the variant. - Attempt to scroll through the product images (using the mouse wheel). Issue: --- - After changing a product variant on the eCommerce product page, attempting to scroll through the product images (using mouse wheel) has no effect. Root cause: --- - When a product variant is changed, `_updateProductImage` dynamically replaces the product image carousel DOM element (`#o-carousel-product`) by injecting new HTML and removing the old one. - The old CarouselProduct interaction instance remains in memory, causing a resource and event listener leak on the detached old DOM element. - The newly inserted `#o-carousel-product` element is ignored by the interaction service, meaning that the CarouselProduct interaction is never initialized on the new carousel. This leaves the new carousel static and unresponsive to user interactions. Solution: --- - Before replacing the carousel DOM node, manually notify the public.interactions service to clean up any active interactions on the old element. After the new DOM node is queried, start the interactions on the new element. opw-6229291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265537
This update optimizes the performance of account reports when hovering over tables with many columns. Previously, hovering caused significant lag due to complex CSS calculations. This change reduces these calculations by targeting specific table cells, resulting in a smoother user experience.
Original PR description
Forward-Port-Of: odoo/enterprise#119242
This update resolves a crash in the payslip PDF report that occurred when employees didn't have a bank account configured. The fix adds a simple check to ensure the bank account section is only displayed if an employee actually has a linked bank account, improving report stability and preventing errors.
Original PR description
The payslip PDF report crashed when the employee had no bank account configured because the template tried to access bank_account_ids[0] unconditionally. Add a t-if guard on the bank account div to only render it when the employee has at least one bank account linked. Forward-Port-Of: odoo/enterprise#115893
This update streamlines spreadsheet document management by disabling versioning for spreadsheets and frozen spreadsheets. This reduces unnecessary data storage and improves performance, as spreadsheets already track their history through revisions. The change also hides the versioning action for these document types.
Original PR description
This PR consists of two commits. The first commit hides the Manage Versions action button for spreadsheet and frozen spreadsheet documents, since versioning is disabled for those records. The second commit is a backport of enterprise commit 0e319d0. It disables document versioning for spreadsheet and frozen spreadsheet documents, as spreadsheets already manage their history through spreadsheet revisions. This avoids creating unnecessary document history attachments when spreadsheet data is written or when a spreadsheet is copied. Task: [6236496](https://www.odoo.com/odoo/project/2328/tasks/6236496) Forward-Port-Of: odoo/enterprise#119689 Forward-Port-Of: odoo/enterprise#118484
This update ensures that descriptions for sale order lines created from deliveries now accurately reflect the product's description, rather than just the product name. Previously, a new line added to a delivery would lack a description in the related sale order. This improves data clarity and reporting accuracy.
Original PR description
When a line is added to a delivery related to a sale order, the corresponding line created in the sale order uses only the display_name as a description. This commit makes sure that if a previous SO line exists for the product, the new line uses the same description. Otherwise we call `get_product_multiline_description_sale()` Steps to reproduce: - Create a product with a description in the Sales tab - Create a quotation with any product (can be said product) and confirm it - Go to the delivery action, and add a new line with the product in the view, set delivered quantity to 1 - After Validating, you'll notice that the new line in the Quotation doesn't have a description opw-6175891 Forward-Port-Of: odoo/odoo#267425 Forward-Port-Of: odoo/odoo#262276
This update enhances the SMS account registration process by adding clear error messages to the IAP system. Specifically, it now identifies issues like unsupported countries or inactive database records, providing better guidance to users. This improves the reliability and user experience of the SMS functionality.
Original PR description
This commit add some error messages (country_not_supported, not_active_db) received by IAP. Task-6240200 IAP: https://github.com/odoo/iap-apps/pull/1612 Forward-Port-Of: odoo/odoo#267459
This update resolves an issue where SEPA QR codes were occasionally displaying incorrect decimal places due to floating-point calculations in the system. The change ensures the QR code accurately reflects the payment amount with the correct currency precision, improving payment accuracy and reducing potential errors. This impacts vendor bill payments.
Original PR description
**Description of the issue/feature this PR addresses:** When generating a SEPA QR code for a vendor bill payment, the embedded amount could occasionally contain excess decimal places instead of…
**Description of the issue/feature this PR addresses:** When generating a SEPA QR code for a vendor bill payment, the embedded amount could occasionally contain excess decimal places instead of respecting the currency's expected precision. This occurs because the `amount` variable in `_get_qr_vals` was being converted directly using `str(amount)`. Due to Python's floating-point arithmetic, the float value in memory can contain decimal drift. Directly casting it to a string exposes this drift in the payload. This commit resolves the issue by replacing `str(amount)` with `float_repr(amount, currency.decimal_places)`. This safely bypasses the float representation issue, ensuring the string strictly respects the currency's configured decimal precision before being injected into the QR code. opw-5504258 **Steps to reproduce:** - Select company “My Belgian Company” - Create a 23% purchase tax - Create vendor bill - Select Vendor “BE Company CoA” - Choose any single product, change price to 37.18 and choose the 23% tax. The Untaxed Amount should be 37.18, VAT tax should be 8.55, and Total should be 45.73 - Confirm > Register Payment > scan QR code. EUR45.730000000000004 should show **Current behavior before PR:** - When generating a SEPA QR code for a payment, the embedded amount can contain excess decimal places due to floating-point drift. **Desired behavior after PR is merged:** - The SEPA QR code is generated with the correct number of decimal places. Forward-Port-Of: odoo/odoo#267293
This update fixes an issue where undoing the auto-plan feature would reset shift workloads, leading to inaccurate resource allocation. The change ensures that allocated hours remain consistent after undoing, allowing for more reliable planning and scheduling. This improves the accuracy of workload assignments.
Original PR description
Steps to Reproduce --- 1. Open the Planning module 2. Create an open shift with allocated_hours 3. Click Auto Plan 4. Click Undo on the auto-plan notification Issue --- Undoing an auto-plan operation…
Steps to Reproduce --- 1. Open the Planning module 2. Create an open shift with allocated_hours 3. Click Auto Plan 4. Click Undo on the auto-plan notification Issue --- Undoing an auto-plan operation triggers recomputation of allocated_hours, causing the shift to lose its original workload value. Current Behaviour --- When resource_id is set to False during undo: - _compute_allocated_hours is triggered (depends on resource_id) - _compute_allocated_percentage is triggered (depends on allocated_hours) - Both fields are recalculated, potentially changing allocated_hours from its pre-assignment value Expected Behaviour --- Undoing auto-plan should preserve allocated_hours at its pre-assignment value while allowing allocated_percentage to adapt to the new context (open slot vs assigned resource). Fix --- Use protecting context manager in action_rollback_auto_plan_ids to prevent allocated_hours from being recomputed when resource_id is removed. This allows allocated_percentage to recalculate naturally based on slot duration while keeping allocated_hours stable. task - 4952149 Forward-Port-Of: odoo/enterprise#119772 Forward-Port-Of: odoo/enterprise#102864
This update fixes an issue where tax calculations within Point of Sale (POS) were consistently showing positive tax base amounts, regardless of the actual tax amount. This resulted in inaccurate tax reporting in the accounting system. The fix ensures that tax base amounts accurately reflect the tax liability, providing correct financial reporting.
Original PR description
Issue: While creating an account move line from POS, the tax_base_amount of tax line is always positive although it might be negative. Steps to reproduce: - with point_of_sale and account_reports - open register - Sale a product with taxes - close register - Go to Accounting -> Tax Report - Switch to current month - On a line click on the tree dots -> Audit Current Behavior: - POS AMLs always have a positive tax base amount for tax lines. Expected behavior: - POS AMLs have a positive or negative base amount for tax lines depending on the move. opw-5975658 Forward-Port-Of: odoo/odoo#265479
This update fixes a bug in the Datev reporting process for German companies. Previously, untaxed invoice lines incorrectly inherited the Datev code from the preceding line, resulting in inaccurate reports. This change ensures that untaxed lines properly display an empty Datev code, aligning with correct accounting practices.
Original PR description
**PROBLEM** Untaxed move lines would take the datev code of the previous line instead of having no datev code like they should. **STEP TO REPRODUCE** 1. On a german company, create an invoice with a line with tax 19% I, and a line that is untaxed (with a non-null price). 2. On the general ledger, generate the datev zip. 3. Unzip, and open the account entries csv, and notice the 2nd line of the invoice as the datev code set to something instead of it being empty (column BU-Schlüssel). opw-6141003 Forward-Port-Of: odoo/enterprise#118486
This update resolves an error that occurred when confirming DHL deliveries, specifically when the scheduled delivery date was missing or set in the past. The change automatically adds one hour to the delivery date, preventing the error and ensuring successful order confirmations.
Original PR description
When confirming the delivery of an order using DHL shipping method we get an error that the date must be in the future. This happens when the scheduled date was not set, or set for a time in the past. This commit automatically sets the time to 1 hour in the future and bypasses the user error. opw-6148927 Forward-Port-Of: odoo/enterprise#116211
A bug was causing grouped payments to incorrectly link existing invoices with new ones. This update fixes the way payments are linked to invoices, ensuring that payments are accurately associated with the intended invoices, regardless of whether they are part of a grouped payment.
Original PR description
Steps to reproduce --- 1. Register a grouped customer payment over several invoices, leaving one of them only partially paid. 2. Register a second grouped payment over two invoices: the partially…
Steps to reproduce --- 1. Register a grouped customer payment over several invoices, leaving one of them only partially paid. 2. Register a second grouped payment over two invoices: the partially paid one and a brand new invoice. 3. Open the first payment, its "Reconciled Invoices" smart button now lists the new invoice from the second payment, which it never paid. Issue --- The smart button is built from the stored `invoice_ids` many2many, which shares its relation table with `account.move.matched_payment_ids`. After reconciling, the register wizard links the payment to its invoices with `lines.move_id.matched_payment_ids += payment` at https://github.com/odoo/odoo/blob/f726393267a28cedd5febd2106de17ae3838f3ff/addons/account/wizard/account_payment_register.py#L1212. When the payment groups several invoices, `lines.move_id` is a multi-record recordset. Reading `matched_payment_ids` on it returns the union of the payments already linked to all those invoices, and `+=` writes that union back to every invoice as a `(6, 0, ...)` replace command. So an invoice already paid by an earlier payment spreads that earlier payment onto every other invoice grouped in the new one, including brand new invoices, which then wrongly appear on the earlier payment. opw-6188013 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267968
This update removes a specific message from invoices sent outside of PEPPOL, which was inappropriate for Business-to-Consumer (B2C) customers. The change ensures that B2C invoices are cleaner and more professional, aligning with customer expectations. This improves the overall customer experience.
Original PR description
Currently, if the invoice was not sent through PEPPOL, it is indicated in the mail footer. However, this message is not appropriate for B2C customers. To avoid this, we remove this footer for customers with empty or '/' VAT (B2C). task-6167439 Forward-Port-Of: odoo/odoo#268826 Forward-Port-Of: odoo/odoo#262412
7 changes
Resolved issues and error corrections
This update fixes an issue where adding a recurring product to a confirmed sales order without a linked subscription plan would cause an error. The change adds a validation step to prevent this, ensuring that recurring products are only added when a valid subscription is present, improving data integrity.
Original PR description
Steps to reproduce: - Go to Sales → Products. - Create a Service product and enable the Recurring option. - Open an already confirmed Sales Order that does not contain any recurring products. - Add the newly created recurring product to the confirmed order. - Click Save. - Observe that a traceback occurs. Cause: - When adding a recurring product without a subscription plan to a confirmed Sale Order, _timesheet_create_task() attempts to compute a start date using order.next_invoice_date, which is not set. - This leads to a TypeError when `order.next_invoice_date` receives `False`. Solution: - Add a validation to prevent adding recurring products without a subscription plan and raise a proper `UserError` instead of allowing the code to reach task generation logic. task-5932700 Forward-Port-Of: odoo/enterprise#119847 Forward-Port-Of: odoo/enterprise#107691
This update fixes an error in the Colombian DIAN reporting process. Previously, the system incorrectly flagged invoices due to a timezone mismatch between UTC and Bogota time. The fix ensures invoices are validated against the correct local date, allowing accurate DIAN document submissions and avoiding potential reporting issues.
Original PR description
**Steps to reproduce:** * Install `l10n_co_edi` module with DEMO DIAN mode enabled. * Go to Accounting > Vendor > Bills and create a new bill. * Select any Colombian partner different from…
**Steps to reproduce:** * Install `l10n_co_edi` module with DEMO DIAN mode enabled. * Go to Accounting > Vendor > Bills and create a new bill. * Select any Colombian partner different from `Consumidor Final`. * Set the invoice date to 6 days in the past. * Select the DIAN Support Documents journal and a product with UNSPSC category. * Confirm the bill and click `Send Support Document to DIAN` after 5 PM Colombia time. **Observed behavior:** * An error is raised stating the issue date cannot be older than 6 days or more than 6 days in the future, even though the invoice date is within the allowed window in Colombia local time. **Cause:** * The date window validation in `_check_move_configuration` used `fields.Datetime.now()` which returns UTC time. Since Colombia is UTC-5, after 5 PM local time the UTC clock has already rolled over to the next calendar day, making a 6-day-old invoice appear 7 days old and failing the validation incorrectly. **Fix:** * Convert the current UTC datetime to the `America/Bogota` timezone and extract its local date before computing the allowed date window. * Compare directly against `move.invoice_date` (a `date` field) instead of using `fields.Datetime.to_datetime()`, keeping the comparison consistent as `date` vs `date`. opw-6011502 Forward-Port-Of: odoo/enterprise#119794 Forward-Port-Of: odoo/enterprise#115256
This update corrects a missing field on Fedex shipping labels, specifically the 'REF' field. This field is required by the Fedex API and was previously left blank, causing delivery issues. The fix ensures accurate label generation and proper communication with the shipping carrier.
Original PR description
Backport of bb4f8bf Original PR #116870 Forward-Port-Of: odoo/enterprise#118967 Forward-Port-Of: odoo/enterprise#117873
This update resolves an issue where the barcode inventory count feature would fail when using archived units of measure. The fix ensures that archived UOMs are correctly included in the inventory count cache, allowing accurate counts to be performed. This prevents errors during physical inventory adjustments.
Original PR description
### Steps to reproduce: - In the settings enable: "Units of Measure & Packagings", "Storage Locations" - Create a product in units and register 1 unit in stock - Inventory > Operations > Adjustments…
### Steps to reproduce: - In the settings enable: "Units of Measure & Packagings", "Storage Locations" - Create a product in units and register 1 unit in stock - Inventory > Operations > Adjustments > Physical Inventory - Select your line and request a count > Set Current Value - Inventory > Configurations > units of measures > UOM categories - Select unit and archive it - Go to the barcode app > Click Count inventory ### > Owl error: Uncaught promise ### Cause of the issue: Since the uom used on the quant is archived, it is not found by the search used to fill the barcodeCache: https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/models/stock_quant.py#L104-L106 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_model.js#L37-L39 However, if the uom is not present in the barcode cache the `BarcodeQautnModel` will fail to createLinesState whihc raises a missing error: https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_quant_model.js#L712 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/lazy_barcode_cache.js#L107-L110 opw-6250090 Forward-Port-Of: odoo/enterprise#118987 Forward-Port-Of: odoo/enterprise#118813
This update fixes an issue where undoing the auto-plan feature would reset the allocated hours for shifts, leading to inaccurate workload calculations. The change ensures that shift workloads remain consistent after undoing the auto-plan, improving the reliability of resource planning.
Original PR description
Steps to Reproduce --- 1. Open the Planning module 2. Create an open shift with allocated_hours 3. Click Auto Plan 4. Click Undo on the auto-plan notification Issue --- Undoing an auto-plan operation…
Steps to Reproduce --- 1. Open the Planning module 2. Create an open shift with allocated_hours 3. Click Auto Plan 4. Click Undo on the auto-plan notification Issue --- Undoing an auto-plan operation triggers recomputation of allocated_hours, causing the shift to lose its original workload value. Current Behaviour --- When resource_id is set to False during undo: - _compute_allocated_hours is triggered (depends on resource_id) - _compute_allocated_percentage is triggered (depends on allocated_hours) - Both fields are recalculated, potentially changing allocated_hours from its pre-assignment value Expected Behaviour --- Undoing auto-plan should preserve allocated_hours at its pre-assignment value while allowing allocated_percentage to adapt to the new context (open slot vs assigned resource). Fix --- Use protecting context manager in action_rollback_auto_plan_ids to prevent allocated_hours from being recomputed when resource_id is removed. This allows allocated_percentage to recalculate naturally based on slot duration while keeping allocated_hours stable. task - 4952149 Forward-Port-Of: odoo/enterprise#119772 Forward-Port-Of: odoo/enterprise#102864
This update fixes a bug where untaxed invoice lines in German accounting reports incorrectly copied the datev code from the previous line. The fix ensures that untaxed lines now properly display an empty datev code, aligning with German tax regulations. This prevents reporting discrepancies and ensures accurate financial data for our German clients.
Original PR description
**PROBLEM** Untaxed move lines would take the datev code of the previous line instead of having no datev code like they should. **STEP TO REPRODUCE** 1. On a german company, create an invoice with a line with tax 19% I, and a line that is untaxed (with a non-null price). 2. On the general ledger, generate the datev zip. 3. Unzip, and open the account entries csv, and notice the 2nd line of the invoice as the datev code set to something instead of it being empty (column BU-Schlüssel). opw-6141003 Forward-Port-Of: odoo/enterprise#118486
This update resolves an error that occurred when confirming DHL deliveries. The system now automatically sets a future delivery date (one hour ahead) to avoid the 'date must be in the future' error, which previously prevented successful order confirmations. This ensures DHL delivery confirmations function correctly.
Original PR description
When confirming the delivery of an order using DHL shipping method we get an error that the date must be in the future. This happens when the scheduled date was not set, or set for a time in the past. This commit automatically sets the time to 1 hour in the future and bypasses the user error. opw-6148927 Forward-Port-Of: odoo/enterprise#116211
9 changes
Resolved issues and error corrections
This update resolves a bug where importing XML bills with identical filenames would create multiple vendor bills. The fix ensures attachments are correctly linked to the appropriate accounting records, preventing duplicate bill creation. This improves data accuracy and simplifies invoice processing.
Original PR description
Fixup of https://github.com/odoo-dev/odoo/commit/3fc85b6ed7936956abbaf8e8364bb2b288cbe289 Issue 1 - Import XML bill into documents app - Create vendor bill from the document Issue: Only the main attachment would be found in the created bill opw-6267888 Issue 2 - From the accounting app import XML bill containing two identically named documents Issue: Two bills were created opw-6231265 Forward-Port-Of: odoo/odoo#268850 Forward-Port-Of: odoo/odoo#268310
This update prevents placeholder images from being sent during menu synchronization, ensuring that only actual product images are transmitted. This improves the efficiency of data transfer and reduces unnecessary data usage, leading to a smoother user experience for customers viewing product menus.
Original PR description
This commit prevents placeholder images from being included in the menu sync payload and only sends `img_url` when an actual image is configured on the product or category. Task-6251430 Forward-Port-Of: odoo/enterprise#119720 Forward-Port-Of: odoo/enterprise#119482
This update fixes an issue where adding a recurring product to a confirmed sales order without a linked subscription plan would cause an error. The change prevents this by validating the product setup, ensuring recurring products are always associated with a subscription, and providing a clear error message to the user.
Original PR description
Steps to reproduce: - Go to Sales → Products. - Create a Service product and enable the Recurring option. - Open an already confirmed Sales Order that does not contain any recurring products. - Add the newly created recurring product to the confirmed order. - Click Save. - Observe that a traceback occurs. Cause: - When adding a recurring product without a subscription plan to a confirmed Sale Order, _timesheet_create_task() attempts to compute a start date using order.next_invoice_date, which is not set. - This leads to a TypeError when `order.next_invoice_date` receives `False`. Solution: - Add a validation to prevent adding recurring products without a subscription plan and raise a proper `UserError` instead of allowing the code to reach task generation logic. task-5932700 Forward-Port-Of: odoo/enterprise#119847 Forward-Port-Of: odoo/enterprise#107691
This update fixes an error in the Colombian DIAN invoice processing flow. Previously, the system incorrectly flagged invoices due after 5 PM Colombia time as invalid due to a timezone mismatch. The fix ensures invoices are validated against the correct Bogota local time, resolving the issue and allowing proper DIAN document submission.
Original PR description
**Steps to reproduce:** * Install `l10n_co_edi` module with DEMO DIAN mode enabled. * Go to Accounting > Vendor > Bills and create a new bill. * Select any Colombian partner different from…
**Steps to reproduce:** * Install `l10n_co_edi` module with DEMO DIAN mode enabled. * Go to Accounting > Vendor > Bills and create a new bill. * Select any Colombian partner different from `Consumidor Final`. * Set the invoice date to 6 days in the past. * Select the DIAN Support Documents journal and a product with UNSPSC category. * Confirm the bill and click `Send Support Document to DIAN` after 5 PM Colombia time. **Observed behavior:** * An error is raised stating the issue date cannot be older than 6 days or more than 6 days in the future, even though the invoice date is within the allowed window in Colombia local time. **Cause:** * The date window validation in `_check_move_configuration` used `fields.Datetime.now()` which returns UTC time. Since Colombia is UTC-5, after 5 PM local time the UTC clock has already rolled over to the next calendar day, making a 6-day-old invoice appear 7 days old and failing the validation incorrectly. **Fix:** * Convert the current UTC datetime to the `America/Bogota` timezone and extract its local date before computing the allowed date window. * Compare directly against `move.invoice_date` (a `date` field) instead of using `fields.Datetime.to_datetime()`, keeping the comparison consistent as `date` vs `date`. opw-6011502 Forward-Port-Of: odoo/enterprise#119794 Forward-Port-Of: odoo/enterprise#115256
This update resolves an error that occurred when sending invoices with Danish VAT numbers via Peppol. Now, customers in Denmark can use VAT numbers without the 'DK' prefix, and the system will correctly generate the Peppol endpoint with the required prefix. This ensures invoices are properly formatted and successfully transmitted.
Original PR description
Current behavior before PR: - Currently, when we include `DK` country prefix in the VAT number, it automatically computes the peppol endpoint with the `DK` prefix for customer from Denmark. - However, there are cases where the VAT number may not include `DK` country prefix, while the corresponding peppol endpoint still does. - In such situations, when sending an invoice via Peppol, the following error occurs: "Errors occurred while creating the EDI document (format: UBL BIS Billing 3.0.12): The VAT of the customer should be prefixed with its country code." Desired behavior after PR is merged: - Now customer from Denmark can have vat without country prefix `DK` and peppol endpoint with prefix `DK` and can send invoice via peppol. task-6119563 Forward-Port-Of: odoo/odoo#263262
This update corrects a missing reference field on Fedex shipping labels. The label now includes a 'CustomerReference' field, as required by the Fedex API, ensuring accurate tracking and documentation of stock transfers. This resolves an issue where the reference was absent, potentially causing delays or discrepancies in shipping processes.
Original PR description
Backport of bb4f8bf Original PR #116870 Forward-Port-Of: odoo/enterprise#118967 Forward-Port-Of: odoo/enterprise#117873
This update fixes an issue where SEPA QR codes generated for vendor payments occasionally displayed incorrect decimal precision due to floating-point calculations. The change ensures the QR code accurately reflects the intended payment amount, resolving potential discrepancies and improving payment accuracy. This impacts the generation of QR codes for vendor bills.
Original PR description
**Description of the issue/feature this PR addresses:** When generating a SEPA QR code for a vendor bill payment, the embedded amount could occasionally contain excess decimal places instead of…
**Description of the issue/feature this PR addresses:** When generating a SEPA QR code for a vendor bill payment, the embedded amount could occasionally contain excess decimal places instead of respecting the currency's expected precision. This occurs because the `amount` variable in `_get_qr_vals` was being converted directly using `str(amount)`. Due to Python's floating-point arithmetic, the float value in memory can contain decimal drift. Directly casting it to a string exposes this drift in the payload. This commit resolves the issue by replacing `str(amount)` with `float_repr(amount, currency.decimal_places)`. This safely bypasses the float representation issue, ensuring the string strictly respects the currency's configured decimal precision before being injected into the QR code. opw-5504258 **Steps to reproduce:** - Select company “My Belgian Company” - Create a 23% purchase tax - Create vendor bill - Select Vendor “BE Company CoA” - Choose any single product, change price to 37.18 and choose the 23% tax. The Untaxed Amount should be 37.18, VAT tax should be 8.55, and Total should be 45.73 - Confirm > Register Payment > scan QR code. EUR45.730000000000004 should show **Current behavior before PR:** - When generating a SEPA QR code for a payment, the embedded amount can contain excess decimal places due to floating-point drift. **Desired behavior after PR is merged:** - The SEPA QR code is generated with the correct number of decimal places. Forward-Port-Of: odoo/odoo#267293
A recent update was causing the Asset Depreciation Schedule report to crash when dealing with a large number of assets grouped together. This fix ensures the report handles missing data correctly, preventing errors and allowing users to accurately analyze their assets even with extensive groupings. This resolves a critical issue impacting report usability for our customers.
Original PR description
#### Description of the issue/feature this PR addresses: Opening the Asset Depreciation Schedule report with a period comparison enabled crashes with KeyError: 'no_format' when prefix grouping is…
#### Description of the issue/feature this PR addresses:
Opening the Asset Depreciation Schedule report with a period comparison enabled crashes with KeyError: 'no_format' when prefix grouping is active (large number of assets in one account group). The report becomes unusable for affected customers.
#### Current behavior before PR:
_regroup_lines_by_name_prefix sums each subline column by indexing prefix_subline['columns'][i]['no_format'] directly. Empty columns are built as {} by _build_column_dict (both col_value and col_data are None), so they have no 'no_format' key. With a comparison period enabled, an asset that has no value in the comparison period produces an empty column for that period; once prefix grouping fires (len(lines) >= prefix_groups_threshold, default 4000), the direct lookup hits that empty dict and raises KeyError: 'no_format'.
#### Desired behavior after PR is merged:
The prefix group total treats a missing 'no_format' as 0, matching the sibling caller in account_asset/models/account_assets_report.py that already guards with .get('no_format', 0). The report builds without crashing and the empty comparison column contributes 0 to the prefix group total.
opw-6225639
Forward-Port-Of: odoo/enterprise#119088Features or functions removed from Odoo
This update removes a message from invoices sent outside of PEPPOL, specifically targeting B2C customers. This footer was misleading and has been removed to improve the customer experience. The change ensures a cleaner invoice presentation for B2C transactions.
Original PR description
Currently, if the invoice was not sent through PEPPOL, it is indicated in the mail footer. However, this message is not appropriate for B2C customers. To avoid this, we remove this footer for customers with empty or '/' VAT (B2C). task-6167439 Forward-Port-Of: odoo/odoo#268826 Forward-Port-Of: odoo/odoo#262412
2 changes
Resolved issues and error corrections
This update resolves an issue where both units of a quality check would be incorrectly moved to the failure location after a partial failure. The fix ensures that the destination of a move line is only updated when there's no remaining demand, preventing unintended movement to the failure location. This improves the accuracy of quality control processes.
Original PR description
Version: ---------- - 18.0+ Steps to reproduce: ------------------- 1. Install *quality_control* module. 2. Go to *Settings* and enable *Storage Locations*. 3. Open Quality module go to the Quality…
Version:
----------
- 18.0+
Steps to reproduce:
-------------------
1. Install *quality_control* module.
2. Go to *Settings* and enable *Storage Locations*.
3. Open Quality module go to the Quality control -> Quality points
4. Create a *Quality Point* with:
* *Product* set.
* *Control per* set to *Quantity*.
* *Operation* set to *Receipts*.
* *Failure Location* set to *WH/Stock/Shelf1*.
5. Create a *Receipt* with demand of *2 units* for the product used in QP.
6. Mark the quality check as *To Do*.
7. Update the *Done Quantity* to *1*.
8. Open the quality check and click *Fail*.
9. Update the *Done Quantity* back to *2* and save.
10. Open the quality check again, click *Pass*, and validate the receipt.
11. Open the *Detailed Operations* to inspect move lines.
Issue:
------
* Both units (failed and passed) are moved to the *failure location*.
Cause:
------
When a user fails a move line via the QC wizard, the flow is:
do_fail() → show_failure_message() → confirm_fail()
→ check._move_to_failure_location(failure_location_id, failed_qty)
Inside `_move_to_failure_location`, when `failed_qty == move_line.quantity`,
the condition:
https://github.com/odoo/enterprise/blob/a33f580455a54a81d89a848f7b493d9dcc9ba2b2/quality_control/models/quality.py#L458
e.g. 1 == 1
was True even when `move.product_uom_qty = 2` (demand still 2). It only
compared the done quantities, ignoring that unfulfilled demand remained.
As a result, `move.location_dest_id` was set to the failure location.
Later, when the user increases the quantity from 1 to 2 on the move form,
the flow is:
_set_quantity → process_increase → _set_quantity_done → _prepare_move_line_vals
In `_prepare_move_line_vals` :
'location_dest_id': self.location_dest_id.id,
https://github.com/odoo/odoo/blob/47bf284e1e9d8be0d4255418e0a3f67c74fa5114/addons/stock/models/stock_move.py#L1688
The new move line inherits `move.location_dest_id` directly, which at this
point is already the failure location.
When the user then calls `do_pass()` on the second unit, `do_pass()` only
writes `quality_state = 'pass'` and never touches `location_dest_id`. So
the second (passed) move line silently retains the failure location.
Solution:
---------
Add the guard `move.product_uom_qty <= move_line.quantity` to the condition
so the entire move's destination is only redirected when there is genuinely
no remaining unfulfilled demand:
When demand > done qty, the else-branch runs instead: it reduces the
original move's demand and creates a new separate move pointing to the
failure location, leaving the original move's `location_dest_id` pointing
to stock. Any subsequent move lines created on the original move therefore
correctly inherit the stock destination.
---
opw-6080871
Forward-Port-Of: odoo/enterprise#112859This update resolves a problem where the journal report incorrectly displayed multi-country tax grids, leading to missing country information when more than two countries were selected. The fix ensures accurate tax grid presentation for users managing multiple international tax scenarios.
Original PR description
When more than 2 country are used in the taxes, the colspan of the header is wrong. When more than 2 country are used in tax grids, the country isn't displayed anymore. Forward-Port-Of: odoo/enterprise#119348
5 changes
Enhancements to existing features
This update clarifies who created replenishment orders in the Odoo chatter logs. Previously, all replenishments were attributed to 'OdooBot,' making it difficult to track manual actions. Now, the creator is accurately recorded, enhancing accountability and auditability for replenishment orders.
Original PR description
Purpose: ================= When a user replenishes a product by clicking the `Order button` in the `Master Production Schedule` view, a `Manufacturing Order` is created. Currently, the chatter logs…
Purpose: ================= When a user replenishes a product by clicking the `Order button` in the `Master Production Schedule` view, a `Manufacturing Order` is created. Currently, the chatter logs show `OdooBot` as the creator of the record. This makes it unclear, as all replenishment records show OdooBot as the creator, preventing users from distinguishing manually placed replenishment from those automatically generated by OdooBot. Recording the actual user (logged-in user) in the chatter who triggered a manual replenishment improves accountability and provides clear visibility, making it easier to audit. With This Commit: ================= When a user triggers a manual replenishment, the system sets the creator of the record to `current user` for manual replenishment or otherwise to `OdooBot` for auto-generated replenishments. This ensures the chatter correctly shows who actually created the record. This makes it easier to track who placed manual replenishments and improves accountability. Community PR : https://github.com/odoo/odoo/pull/227827 TaskID–4893809
Resolved issues and error corrections
This update ensures field service technicians are routed to the correct job site by automatically selecting the delivery address associated with a project or task, instead of the company headquarters. This resolves issues where technicians were directed to the wrong location, improving efficiency and accuracy.
Original PR description
Currently, when creating a planning shift and selecting a project or task, the shift's customer (`partner_id`) defaults to the main partner (the parent company). This causes issues for field service technicians, as the Map view routes them to the company headquarters instead of the actual physical job site. This commit improves the behavior by attempting to fetch the 'delivery' child contact of the partner linked to the task or project. If a delivery address exists, it is set as the default on the shift. If it does not exist, it falls back to the main partner. Task-6132902
This update resolves a test failure caused by incorrectly formatted data being passed. Specifically, the system was sending raw PDF content instead of the expected base64 encoded data, leading to an error. This fix ensures the tests run correctly and maintains data integrity.
Original PR description
This commit fixes an error when running the `test_employee_job_change` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw PDF content was being passed when a base64 representation was actually expected (which is obviously invalid base64). runbot-938173 Forward-Port-Of: odoo/enterprise#119786 Forward-Port-Of: odoo/enterprise#118523
This update resolves a potential error in the Hong Kong payroll calculation that could have occurred when specific conditions were met (null resource calendar or zero hours per week). The fix adds a check to prevent division by zero, ensuring accurate payroll processing for Hong Kong employees. This improves the reliability of the payroll system.
Original PR description
. Add a check for a null resource calendar and zero hours per week. task-6229271 Forward-Port-Of: odoo/enterprise#117685
Code cleanup and technical improvements
This update refactors the Web Studio module to use a more modern and efficient approach to data handling. Specifically, it utilizes 'contextvars' to manage data within the module, leading to better performance and maintainability. This change improves the underlying code structure without impacting how users interact with Web Studio.
Original PR description
https://github.com/odoo/odoo/pull/256688
3 changes
Resolved issues and error corrections
This update resolves a test failure caused by incorrectly formatted data being passed to the system. Specifically, the system was receiving raw PDF content instead of the expected base64 encoded data, leading to an error. This ensures the tests run successfully and maintains data integrity.
Original PR description
This commit fixes an error when running the `test_employee_job_change` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw PDF content was being passed when a base64 representation was actually expected (which is obviously invalid base64). runbot-938173 Forward-Port-Of: odoo/enterprise#119786 Forward-Port-Of: odoo/enterprise#118523
This update corrects a technical issue with the Stripe integration for expense cards, ensuring accurate address formatting. The previous implementation incorrectly used ISO 3166-2 codes, causing failures when processing US payments. This fix ensures compatibility with Stripe's requirements and prepares for the upcoming US release.
Original PR description
Stripe says that address.state is "State, county, province, or region (ISO 3166-2)". There didn't seems to be any issues since it seems that it's not checked for the EU. However, this is still wrong and could raise an issue if Stripe decide to start checking them. Also, with the US coming soon, it's being checked and failed.
This update fixes an issue where planned dates were lost when converting projects to project templates. The change ensures that the original planned dates are retained in the new template, streamlining project management and preventing data loss. This improves the accuracy of project timelines.
Original PR description
Steps to reproduce: -------- - Open a project with a planned date set. - Create Template of that project. - Observe the created project template. Issue: ---------- The planned dates of the project are lost when converting the project into a template. Cause: ----- When we create a project template from a project, the project gets archived.Because a new project template record is created, and the start and expiration fields have copy=False, those dates are not being copied. Fix: ------- Explicitly pass the planned date when copying the project, so the project template keeps the original planned date. task-5872500 Forward-Port-Of: odoo/enterprise#115035
3 changes
Resolved issues and error corrections
This update fixes an issue where holiday allocation hours were incorrectly set to zero for employees with no working schedule. The change ensures accurate hour calculations, particularly for flexible employees, preventing misallocation of time off. This improves the reliability of holiday tracking.
Original PR description
Pre-requisite: ------------------------------ 1. Install the Time Off module with the demo 2. Working schedule > Duplicate 'Standard 40 hours/week' schedule 3. Rename it > Add any Date in 'Starting…
Pre-requisite: ------------------------------ 1. Install the Time Off module with the demo 2. Working schedule > Duplicate 'Standard 40 hours/week' schedule 3. Rename it > Add any Date in 'Starting Date' for all days of the schedule 4. Create a new employee with this New Working Schedule 5. Create a new Time off type with 'Take Time Off in' field set to 'Hours' Steps to reproduce: ------------------------------ 1. Time off > Management > Allocations 2. Click 'New' > Change time off type to Newly created time off type 3. Add the Newly Created Employee to Allocation Observation: ------------------------------ 1. Allocation hours are automatically set to 0 2. Even after manually updating the hours, saving the record resets them to 0 Issue: ------------------------------ The computed field `number_of_hours_display` relies on `_get_hours_per_day` method to get the hours per day. In the `_get_hours_per_day` method, it will return the calendar hours even when they are 0 and return 24h for the employee with no calendar (fully flexible). This results in allocation hours always being computed as 0 In the previous version, it was not the issue, as we had statically passed 8 hours, If the calendar has no `hours_per_day` https://github.com/odoo/odoo/blob/97bde303ab3dae81215f8a1c52714d44916d79e1/addons/hr_holidays/models/hr_leave_allocation.py#L236 Solution: ------------------------------ 1. For an employee with no working schedule (Fully flexible) returns 24 2. Returned HOURS_PER_DAY (8h) if the calendar has 0 working hours, as allocation with 0 hours makes no sense opw-6042203
This update resolves a problem where the journal report incorrectly displayed tax grids when multiple countries were selected. The fix ensures that all countries are accurately represented in the report, regardless of the number of tax jurisdictions used. This improves the accuracy of financial reporting.
Original PR description
When more than 2 country are used in the taxes, the colspan of the header is wrong. When more than 2 country are used in tax grids, the country isn't displayed anymore. Forward-Port-Of: odoo/enterprise#119348
This update fixes an issue where users without HR access were seeing a placeholder image instead of their avatar in the timesheet kanban view. The fix ensures all users can see their avatar, improving the user experience and visual consistency within the HR timesheet module.
Original PR description
Steps to reproduce: ------ - Install the hr_timesheet module - Create a user without HR access rights - Create a timesheet - Log in with the above user - Open the kanban view Issue: ------- Instead of showing the employee's avatar, a placeholder image is displayed. Reason: --- The user does not have access to the hr.employee model. Fix: -------- In this commit, if the user does not have access to hr.employee, we fetch the image from the hr.employee.public model. task: 4461272 Forward-Port-Of: odoo/odoo#210039