Daily updates from Odoo
Wednesday, April 29, 2026
147 changes
14 changes
Resolved issues and error corrections
This update ensures that when a company is quickly created through a partner record in the equity module, the system correctly identifies it as a company. Previously, this wasn't happening, leading to incorrect data. The update also includes a minor fix for a typo in view definitions.
Original PR description
The partner_id field on all equity models represents a company. Therefore, quick-creating a partner_id should create it with is_company set to True. However, that wasn't the case. This commit fixes this issue by making sure that partner_id when quick-created in equity models has is_company set to True. It also fixes a typo in the string attribute of valuation list and form views. task-6132343 Forward-Port-Of: odoo/enterprise#114375
This update fixes an issue where the system incorrectly determined if an Italian VAT-registered company was recognized. The previous logic only checked for a 11-character Codice Fiscale, failing to correctly identify companies with longer, country-prefixed codes. This change ensures accurate company status determination based on the CF, preventing incorrect partner classifications.
Original PR description
Since 5d3c73ffd0ad ("derive company status from Codice Fiscale format") is_company is True only when the CF (Codice Fiscale) is exactly 11 chars.
Two issues:
- No @api.depends on l10n_it_codice_fiscale, so editing the CF alone leaves is_company inchanged.
- A country-prefixed CF like "IT14475210960" is 13 chars and silently downgrades the partner to a natural person.
Steps to reproduce:
- On an Italian company partner, set:
VAT = IT14475210960
Codice Fiscale = MRTMTT91D08F205J
- Change the CF to IT11122244544, it will be saved but is_company will
remain False, which is wrong.
opw-6129645
Forward-Port-Of: odoo/odoo#261702This update resolves a bug where basic receipts were incorrectly generated in the Point of Sale chatter, even when the feature wasn't enabled. It now ensures basic receipts are only created when the option is specifically selected, preventing duplicate receipt images and streamlining the user experience.
Original PR description
Before this commit: =================== - Basic receipt was generated even when the option was not selected. - Both basic and full receipt images could be generated simultaneously. After this commit: ================== - Basic receipt is generated in chatter only when the option is enabled. - Prevents simultaneous generation of both basic and full receipt images. Task - 6126775 Forward-Port-Of: odoo/odoo#260555
This update addresses a visual flicker and occasional failure to apply lists when using the chatter composer. The fix prevents unnecessary processing triggered by a 'blur' event, ensuring lists are consistently applied smoothly. This improves the user experience when formatting text within the chatter.
Original PR description
Problem: When the chatter is open and text is selected, applying a list from the toolbar causes a flicker, and the list is sometimes not applied on the first attempt. Cause: Opening the list dropdown triggers a `blur` event on the `html_editor` field, which calls `getInlinedEditorContent` and duplicates the DOM to perform inlining. This unnecessary processing causes the visual flicker and may interrupt the list application. Solution: Prevent the field from blurring when selecting a list alignment option from the toolbar. Steps to reproduce: - Open a new record. - Open the composer. - Add text and select it. - Apply a list using the toolbar. - Observe that sometimes the list is not applied on the first try and the content briefly flickers. opw-6153261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261476
This update resolves an issue in the Bangladesh localization where an unnecessary expense account was being linked to inventory valuations. Removing this link ensures that inventory accounting aligns with standard Bangladesh practices, preventing unexpected stock variations and improving accuracy.
Original PR description
Issue: The Bangladesh chart template sets account_stock_expense_id on the inventory valuation account. This triggers Stock Variation entries following perpetual continental behavior, which is not expected for Bangladesh localization. Cause: l10n_bd template data explicitly populated `account_stock_expense_id` for account `l10n_bd_100502`. Solution: Remove `account_stock_expense_id` from the Bangladesh account template mapping. opw-5944874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261311
This update fixes an issue where users needed to manually pair Bluetooth devices with their IoT Boxes. The fix addresses a technical problem where the device was forcibly disconnecting Bluetooth connections and failing to register the necessary pairing agent. Now, supported Bluetooth devices automatically connect when they are within range of the IoT Box.
Original PR description
According to the IoT Box documentation written in 10/2019, supported Bluetooth devices should connect automatically whenever they are in range of the IoT Box: https://github.com/odoo/documentation/commit/16f2f26f8ae6d9040195c854da337e0dcbbff955#diff-b5974750d9a7f12db80e4922399a7cacd26228dec979ca0fbb504faac386efc8R27 This behavior had broken at some point, requiring manual pairing via bluetoothctl on the IoT Box to establish a connection. Root causes identified and fixed: - The interface was forcibly disconnecting all already-connected BLE devices at startup, kicking them mid-GATT handshake - No BlueZ pairing agent was registered, causing AuthenticationFailed during the pairing negotiation Automatic connection on proximity is now restored. opw-5473691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259885
A recent change to the Viva payment system in the POS was causing cancellations to fail. This update corrects a technical issue where the cancellation process didn't match the original payment setup, resulting in an error message. Now, cancellations from the POS will function correctly.
Original PR description
Steps to reproduce: 1. Start a Viva payment from the POS 2. Cancel the payment from the POS (not on the terminal) **Expected behaviour:** Payment cancels successfully **Actual behaviour:** Error message "Only cash register that created the transaction can abort it". The fix is to use the same cash register ID in both the payment and the cancellation transactions. The payment cash register ID was originally changed to ensure payments would work in the kiosk, but the cancellation cash register ID was never updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261725
This update corrects a bug in the payroll system's calculation of full-time equivalent (FTE) hours. Previously, if an employee worked 0 hours, the FTE calculation was incorrect. This change ensures accurate FTE reporting for all employees, regardless of their worked hours.
Original PR description
Before this commit, the full-time equivalent compute was not taking into account the fact that the total worked hours could be 0.
This update resolves a bug preventing users from correctly setting up Worldline and Axepta payment terminals through the quick setup process. The issue stemmed from an incorrect value being used, which is now corrected to ensure both providers function properly. The update also streamlines the logo images for better consistency.
Original PR description
In odoo/odoo#230817, the Ingenico protocol was removed and merged with worldline (since the terminals support the same protocol). However, one issue from this merge is that in the payment terminal…
In odoo/odoo#230817, the Ingenico protocol was removed and merged with worldline (since the terminals support the same protocol). However, one issue from this merge is that in the payment terminal provider cards, which allow quickly setting up a payment terminal by selecting the brand, the Worldline and Axepta options were both not working. The reason for this is that the `use_payment_terminal` field would be set to `axepta_bnpp`, which isn't a valid value and is only used for the name of the logo image. This commit changes the following: - The Worldline and Axepta BNPP cards now both correctly set `worldline` as the payment provider. - The name of the payment method is now set to either 'Worldine' or 'Axepta BNP Paribas' depending on which card is selected. - The logos for Worldline and BNP Paribas have been combined into one image, reflecting the fact that they are a single selection. The alternative would be to add new logic with a separate image path for these providers, which seemed like overkill for this edge case. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261709
A recent update caused newly added overtime lines on attendance records to disappear. This fix disables the ability to add new overtime lines, resolving the synchronization problem and preventing data loss. This ensures accurate work entry tracking.
Original PR description
Steps to reproduce: - On an attendance with overtime, click the "Add a line" button and add a new overtime line - Refresh the page - The newly added line has disappeared and navigating to work entries causes a traceback How it was fixed: Disabled the ability to add a new overtime line. Task ID: 5899657 Forward-Port-Of: odoo/odoo#261540 Forward-Port-Of: odoo/odoo#248431
This update resolves an issue where the 'Create a Payslip' button was unresponsive when no payslips existed in the system. The fix corrects a technical error related to how the button's functionality was triggered, ensuring it now functions as expected. This improves the user experience when initiating new payroll processes.
Original PR description
1.Install l10n_us_hr_payroll 2 Navigate to Payroll>Reporting>W2 Report. 3.Open/Create W2 form and try to add payslip by clicking "Add a line". 4."Create a payslip" button appears if their are no valid payslips. 5.Click it, it won't work! Root cause: - `onAdd` bind was missing in the controller - Renderer applied an additional `.bind(...)`, breaking the callback Fix: - Pass a dedicated `createNewPayslip` action from controller - Remove double binding in renderer - Forward callback directly to helper component task-[5928770](https://www.odoo.com/odoo/project/1251/tasks/5928770) Forward-Port-Of: odoo/enterprise#114101 Forward-Port-Of: odoo/enterprise#111735
This update corrects a technical issue where styling applied to list views was incorrectly affecting other views within the account reports module. The fix ensures that styling is applied only to the intended list views, improving the consistency and appearance of reports. This resolves a minor visual inconsistency.
Original PR description
The css selector used to add the small border at the start of the line. So it end-up being applied in other view as well. task-6141685 Forward-Port-Of: odoo/enterprise#114903
This update fixes an issue where the product description text area on iOS devices (specifically with Safari) would jump unexpectedly when typing. The root cause was a miscalculation of scroll height within the application's design. This change ensures a smoother and more reliable experience for users adding product descriptions in invoices.
Original PR description
Steps to reproduce ================== - Use an iPad device - Go to accounting - Sales > New - Add the product column in the invoices lines - Add a new line - Select a product - Add a description - press enter a bunch of times => the cursor will end up beneath the virtual keyboard - enter a letter => the textarea jumps above Cause of the issue ================== With Safari, setting a size on the widget root causes the scrollheight to be miscalculated. It doesn't take into account the last empty lines of the textarea. Solution ======== There is actually no need to set an height on the widget root node. opw-5927775 Forward-Port-Of: odoo/odoo#259855
Previously, changes to a customer's activity (like notes or tasks) weren't consistently reflected across all views within Odoo. This update corrects a technical error that prevented this synchronization, ensuring all users see the most up-to-date activity information. This improves collaboration and data accuracy.
Original PR description
Since [1], the activity state, which is supposed to be shared accross tab through a broadcast channel, isn't anymore. This PR fixes the responsible typo. [1]: #161286 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#259810 Forward-Port-Of: odoo/odoo#255785
22 changes
Resolved issues and error corrections
This update resolves an issue in the Bangladesh localization where an unnecessary expense account was being applied to inventory valuations. Removing this forced setting aligns the system with expected accounting practices for Bangladesh, ensuring accurate financial reporting. This change improves the reliability of inventory tracking within the Odoo system for users in Bangladesh.
Original PR description
Issue: The Bangladesh chart template sets account_stock_expense_id on the inventory valuation account. This triggers Stock Variation entries following perpetual continental behavior, which is not expected for Bangladesh localization. Cause: l10n_bd template data explicitly populated `account_stock_expense_id` for account `l10n_bd_100502`. Solution: Remove `account_stock_expense_id` from the Bangladesh account template mapping. opw-5944874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261311
This update ensures that when a company is quickly created through a partner record in the equity module, it correctly identifies itself as a company. Previously, this was not consistently set, leading to potential data inconsistencies. The update also includes a minor fix for a typo in view definitions.
Original PR description
The partner_id field on all equity models represents a company. Therefore, quick-creating a partner_id should create it with is_company set to True. However, that wasn't the case. This commit fixes this issue by making sure that partner_id when quick-created in equity models has is_company set to True. It also fixes a typo in the string attribute of valuation list and form views. task-6132343 Forward-Port-Of: odoo/enterprise#114375
This update corrects a technical issue where styling applied to list views was incorrectly affecting other views within the account reports module. The fix ensures that styling is applied only to the intended list views, improving the consistency and appearance of reports. This resolves a minor visual inconsistency.
Original PR description
The css selector used to add the small border at the start of the line. So it end-up being applied in other view as well. task-6141685 Forward-Port-Of: odoo/enterprise#114903
This update fixes a problem where users without HR permissions couldn't apply filters in the Time Off Overview. The fix ensures the system correctly handles filter applications, preventing errors and improving usability for all users. It addresses a technical issue related to user access rights.
Original PR description
Steps to reproduce: - Log using a user with no HR access rights (e.g. Marc Demo) - Go to Time Off > Overview - Remove all filters - Add a new custom filter on "Department is equal to ..." or "Job is equal to ..." Instead of the filter being applied, a traceback occurs. This originates from the fact that in `_get_gantt_data_groupby_employee`, the employee domain is mapped to address the field `current_version_id`. However, if a user has no HR rights, the search will be redirected to the employee public model, on which that field isn't defined. This commit adds a sudo on the search_fetch for the method to use the employee model and avoid facing the traceback No related task
This update fixes an issue where holiday reports weren't correctly filtering employees due to an outdated workaround. The change ensures the correct employee domain is used, resolving a potential discrepancy in reporting. This improves the accuracy of holiday reports for all users.
Original PR description
When getting a gnatt view with a domain that has only employee fields, the domain would be applied to hr.employee.public instead as an old workaround when the user has no full access to the…
When getting a gnatt view with a domain that has only employee fields, the domain would be applied to hr.employee.public instead as an old workaround when the user has no full access to the hr.employee fields.
This fix translates the domain to the employee public domain.
steps to reproduce on runbot:
- access the db with a non admin user (marc demo)
- go to Time Off / Overview
- remove the default filters
- search by Department
<details>
<summary>Traceback</summary>
```
RPC_ERROR
Odoo Server Error
Occured on 107464076-saas-19-2-all.runbot184.odoo.com on model hr.leave.report.calendar on 2026-04-15 14:17:09 GMT
Traceback (most recent call last):
File "/data/build/odoo/odoo/orm/domains.py", line 933, in __get_field
field = model._fields[field_name]
~~~~~~~~~~~~~^^^^^^^^^^^^
KeyError: 'current_version_id'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/data/build/odoo/odoo/http/router.py", line 441, in serve_db
return retrying(serve_func, env=request.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/retrying.py", line 52, in retrying
result = func()
^^^^^^
File "/data/build/odoo/odoo/http/router.py", line 593, in serve_ir_http
response = request.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/dispatcher.py", line 308, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 415, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/routing_map.py", line 207, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/web/controllers/dataset.py", line 32, in call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/service/model.py", line 55, in call_kw
result = method(recs, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/hr_holidays_gantt/report/hr_leave_report_calendar.py", line 47, in get_gantt_data
return self._get_gantt_data_groupby_employee(domain, employee_domain, groupby, read_specification, limit, offset, unavailability_fields, progress_bar_fields, start_date, stop_date, scale)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/hr_holidays_gantt/report/hr_leave_report_calendar.py", line 51, in _get_gantt_data_groupby_employee
employees = self.env['hr.employee'].search_read(employee_domain, ['id', 'name'], offset=offset, limit=limit)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/models.py", line 5094, in search_read
records = self.search_fetch(domain or [], fields, offset=offset, limit=limit, order=order)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/hr/models/hr_employee.py", line 1320, in search_fetch
public = self.env['hr.employee.public'].search_fetch(domain, field_names, offset, limit, order)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/models.py", line 1431, in search_fetch
query = self._search(domain, offset=offset, limit=limit, order=order or self._order)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/models.py", line 4699, in _search
query.add_where(domain._to_sql(query.table))
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/domains.py", line 688, in _to_sql
return SQL("(%s)", self.OPERATOR_SQL.join(
^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/tools/sql.py", line 182, in join
args = list(args)
^^^^^^^^^^
File "/data/build/odoo/odoo/orm/domains.py", line 689, in <genexpr>
child._to_sql(table) for child in self.children
^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/domains.py", line 1120, in _to_sql
field = self._field(model)
^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/domains.py", line 926, in _field
field, _ = self.__get_field(model)
^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/domains.py", line 935, in __get_field
self._raise("Invalid field %s.%s", model._name, field_name)
File "/data/build/odoo/odoo/orm/domains.py", line 920, in _raise
raise error(message % (*args, self.field_expr, self.operator, self.value))
ValueError: Invalid field hr.employee.public.current_version_id in condition ('current_version_id', 'any!', [('department_id', 'any', [('id', 'in', [5, 4])])])
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://107464076-saas-19-2-all.runbot184.odoo.com/web/assets/d13b214/web.assets_web.min.js:3259:165)
at XMLHttpRequest.<anonymous> (https://107464076-saas-19-2-all.runbot184.odoo.com/web/assets/d13b214/web.assets_web.min.js:3266:13)
```
</details>This update corrects a technical issue within the Odoo Enterprise system's onboarding tour for overtime rules. The previous tour incorrectly targeted an input field, leading to incorrect interactions. This fix ensures the tour accurately guides users through the correct elements within the overtime setup modal.
Original PR description
The tour previously matched the input field underneath the popup and interacted with the wrong element, the fix scope the selector to the modal. task-6172067
This update resolves a bug preventing users from correctly setting up Worldline and Axepta payment terminals through the quick setup process. The issue stemmed from an incorrect value being used, now corrected to ensure both providers function properly. The update also streamlines the logo images for better clarity.
Original PR description
In odoo/odoo#230817, the Ingenico protocol was removed and merged with worldline (since the terminals support the same protocol). However, one issue from this merge is that in the payment terminal…
In odoo/odoo#230817, the Ingenico protocol was removed and merged with worldline (since the terminals support the same protocol). However, one issue from this merge is that in the payment terminal provider cards, which allow quickly setting up a payment terminal by selecting the brand, the Worldline and Axepta options were both not working. The reason for this is that the `use_payment_terminal` field would be set to `axepta_bnpp`, which isn't a valid value and is only used for the name of the logo image. This commit changes the following: - The Worldline and Axepta BNPP cards now both correctly set `worldline` as the payment provider. - The name of the payment method is now set to either 'Worldine' or 'Axepta BNP Paribas' depending on which card is selected. - The logos for Worldline and BNP Paribas have been combined into one image, reflecting the fact that they are a single selection. The alternative would be to add new logic with a separate image path for these providers, which seemed like overkill for this edge case. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261709
This update addresses a visual glitch that occasionally occurred when users applied list formatting within the chatter interface. The issue stemmed from an unnecessary 'blur' event triggering extra processing, leading to a brief flicker and potential list application failures. This fix ensures a smoother and more reliable list formatting experience.
Original PR description
Problem: When the chatter is open and text is selected, applying a list from the toolbar causes a flicker, and the list is sometimes not applied on the first attempt. Cause: Opening the list dropdown triggers a `blur` event on the `html_editor` field, which calls `getInlinedEditorContent` and duplicates the DOM to perform inlining. This unnecessary processing causes the visual flicker and may interrupt the list application. Solution: Prevent the field from blurring when selecting a list alignment option from the toolbar. Steps to reproduce: - Open a new record. - Open the composer. - Add text and select it. - Apply a list using the toolbar. - Observe that sometimes the list is not applied on the first try and the content briefly flickers. opw-6153261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261476
This update corrects an issue where signatures were incorrectly duplicated on generated order PDFs after a signed order was modified. Now, signatures are only printed on documents created directly by the signature process, ensuring consistency and accuracy in order documentation. This change enhances the reliability of our sales records.
Original PR description
A signed order can be modified afterward while retaining the signature on the newly generated PDF. After this commit, we will only print the signature on the document generated by the signature itself and not on any generated PDF afterwards. opw-6159170 Forward-Port-Of: odoo/odoo#261288
A recent change to the Viva payment system in the POS was causing cancellations to fail. This update corrects a technical issue where the cancellation process didn't match the payment process, resulting in an error message. The fix ensures that Viva payments can now be successfully cancelled from the POS.
Original PR description
Steps to reproduce: 1. Start a Viva payment from the POS 2. Cancel the payment from the POS (not on the terminal) **Expected behaviour:** Payment cancels successfully **Actual behaviour:** Error message "Only cash register that created the transaction can abort it". The fix is to use the same cash register ID in both the payment and the cancellation transactions. The payment cash register ID was originally changed to ensure payments would work in the kiosk, but the cancellation cash register ID was never updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261725
This update prevents the chatbot from restarting incorrectly when a chat session is closed prematurely. Previously, attempting to restart the chatbot mid-session could cause errors. Now, the restart button is disabled on the feedback panel until the chatbot session is fully completed, ensuring a smoother user experience.
Original PR description
Before this commit, it was possible to restart the chatbot on the feedback panel when closing the chat window. This was actually failing when the chatbot was stopped before the last step was completed and left the livechat state in error. Now, the button is simply disabled on feedback when we did not reach the end of the chatbot to avoid any issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258394 Forward-Port-Of: odoo/odoo#257891
This update prevents portal users from seeing the 'View Timesheets' button on invoices when they don't have the necessary permissions to access those timesheets. Previously, the system incorrectly displayed the button based on the presence of timesheets linked to the order. This change ensures a more accurate and secure user experience.
Original PR description
sale: add sale order specific hook to extend page values ------ Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values sale_timesheet: hide 'View Timesheets'…
sale: add sale order specific hook to extend page values
------
Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values
sale_timesheet: hide 'View Timesheets' button for users without access
-------
Steps to Reproduce:
-----------------
- Create a product with the invoice policy set to Based on Timesheets
- Enable Project and Tasks on the order.
- Create and confirm a sale order using a portal user.
- Log timesheets on the related task.
- Create an invoice from the sale order.
- Log in as the portal user and open the invoice.
- Click the 'View Timesheets' button.
Issue:
-------------
The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets.
Root Cause:
------------
The timesheets are linked to the sale order, so the button appears based on the timesheet_count, but the portal user does not actually have permission to access those timesheets.
Fix:
-----------
We replaced the timesheet_count check with a check that verifies whether the user actually has access to any of the related timesheets.
task-4745519
Forward-Port-Of: odoo/odoo#261681
Forward-Port-Of: odoo/odoo#209552This update fixes a problem where portal users were incorrectly seeing a 'View Timesheets' button, even when they lacked the necessary permissions. The change utilizes a new helper method to accurately control button visibility based on user access rights, ensuring a more secure and consistent user experience.
Original PR description
**Issue:** The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets. Currently, we have added _sale_order_get_page_view_values in the sale module, which is overridden in sale_timesheet. We are using it here. task-4745519 Forward-Port-Of: odoo/enterprise#115193 Forward-Port-Of: odoo/enterprise#113481
This update corrects a minor visual issue where icons within thumbnails weren't consistently positioned. The change adjusts the base layout to allow for overrides, ensuring thumbnails display icons in the correct location. This improves the overall presentation and user experience.
Original PR description
We modify the base layout to allow a fix of the icon position in an override. Task-5152517 Forward-Port-Of: odoo/odoo#249055
This pull request addresses several small issues within the Documents module, primarily related to file handling and display. Specifically, it fixes problems with scrolling after file uploads, icon positioning, and badge layout under certain conditions. These changes improve the overall user experience and ensure consistent functionality.
Original PR description
[FIX] documents: scroll to uploaded record How to reproduce: - install documents - open the "All" folder and ensure there is enough folder to not see any file - open the detail panel - drag&drop file…
[FIX] documents: scroll to uploaded record How to reproduce: - install documents - open the "All" folder and ensure there is enough folder to not see any file - open the detail panel - drag&drop file in that folder The file is uploaded, but you have to scroll to it to see it. Moreover, despite the file being selected, it's not shown the detail panel. We solve the problem here by waiting the record to be rendered before scrolling to it and notify the detail panel. [FIX] documents: fix icon position in thumbnail How to reproduce: - install documents - open the chatter of a document - click on log a note, and upload a file The "trash" icon/button in the thumbnail is weirdly positioned (neither centered, neither on a border). We fix here the position the icon/button. [FIX] documents: fix "you" badge layout How to reproduce: - install documents - change the name of Mitchell Admin to a very long name - open the share panel owned by Mitchell Admin The "You" badge is not correctly displayed (the badge appears as "Y..." instead of "You" and the shape is not correct). We fix here the layout of the badge in such configuration. Task-5152517 Forward-Port-Of: odoo/enterprise#107686
This update fixes an issue where Odoo was creating purchase orders even when sufficient stock was available for manufacturing orders. The change ensures that stock is accurately considered before generating purchase requests, streamlining the manufacturing process and reducing unnecessary spending. This improves efficiency and avoids duplicate orders.
Original PR description
Steps to reproduce: - Create a product P1 with a BoM containing component C1 - Set C1 route to MTO + Buy: - add any vendor - Have 10 units of C1 in stock - Confirm a Manufacturing Order for 2 units…
Steps to reproduce:
- Create a product P1 with a BoM containing component C1
- Set C1 route to MTO + Buy:
- add any vendor
- Have 10 units of C1 in stock
- Confirm a Manufacturing Order for 2 units of P1
- The MO confirmation triggers the move for C1, which gets assigned from stock
- Increase the quantity_producing on the MO
- This updates product_uom_qty on the move and calls _run_procurement
Expected behavior:
- No Purchase Order should be created since stock covers the demand
Current behavior:
- A Purchase Order is created even though stock is sufficient
- In case of partial stock, the full procurement_qty is used instead of the uncovered delta
Fix:
- Track mts_else_mto moves separately before calling _action_assign()
- After _action_assign(), subtract the newly covered quantity (move.quantity - old_qty)
from the procurement_qty before running the stock rule
- Skip the procurement entirely if the adjusted qty <= 0
opw-6042283
Forward-Port-Of: odoo/odoo#258871This update ensures that missing payslip issues are only triggered when the payroll closing date has passed. This prevents unnecessary alerts and streamlines the payroll process by focusing on actual overdue payments. It maintains the existing logic for identifying missing payslips.
Original PR description
In this commit, missing payslip in a payrun issue will be raised only if the payroll closing date is due (old conditions remains). task-6008297
This update allows accountants to retain KSEF XML files associated with invoices. Previously, these files were automatically discarded after being used to fetch data. Now, the XML files are saved as attachments to the corresponding invoice, providing a backup for longer-term record-keeping requirements.
Original PR description
Description of the issue this commit addresses: When fetching the bills from ksef, the xml with the data about the move is received, parsed and then discarded but the XML can be required to be kept for longer than ksef keeps it so we are lacking a way for an accountant to download it and store it locally. --- Desired behavior after this commit is merged: When a move is fetched from ksef via an xml file, that file is put as an attachment on the move created with its data. --- task-6076505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259655
This update fixes an issue where the product description field on iOS devices (specifically with Safari) would jump unexpectedly when typing. The problem stemmed from incorrect calculations of the text area's height. The fix removes unnecessary sizing constraints, ensuring the description field resizes correctly and provides a better user experience for adding product details on iPads.
Original PR description
Steps to reproduce ================== - Use an iPad device - Go to accounting - Sales > New - Add the product column in the invoices lines - Add a new line - Select a product - Add a description - press enter a bunch of times => the cursor will end up beneath the virtual keyboard - enter a letter => the textarea jumps above Cause of the issue ================== With Safari, setting a size on the widget root causes the scrollheight to be miscalculated. It doesn't take into account the last empty lines of the textarea. Solution ======== There is actually no need to set an height on the widget root node. opw-5927775 Forward-Port-Of: odoo/odoo#259855
A recent issue prevented activity updates from being shared correctly across different tabs within Odoo. This fix corrects a typo that was causing this problem, ensuring activity states are now consistently synchronized for all users. This improves the reliability of task tracking and collaboration.
Original PR description
Since [1], the activity state, which is supposed to be shared accross tab through a broadcast channel, isn't anymore. This PR fixes the responsible typo. [1]: #161286 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#259810 Forward-Port-Of: odoo/odoo#255785
This update resolves a visual issue in Safari where the 'is typing' indicator icon was misaligned. The fix avoids complex styling techniques that triggered a bug related to Safari's rendering engine, ensuring the indicator displays correctly. This improves the user experience for Safari users.
Original PR description
Before this commit, "is typing" icon in Safari browser was misplaced with relative to Discuss Avatar image. This happens due to a bug in Safari that affects `foreignObject` with elements that use…
Before this commit, "is typing" icon in Safari browser was misplaced with relative to Discuss Avatar image. This happens due to a bug in Safari that affects `foreignObject` with elements that use some CSS rules, like `opacity`. A prior fix was done to apply on change of opacity with classnames [1], which fixed "offline" icon but is typing still has issues: - change of opacity doesn't use classname, this is coupled to animation frame in CSS - the "is typing" icon uses `filter` and `transform`, both of which are also a problem This commit fixes the issue by not using icon animation for Safari browsers. The rules were mostly used for the animation, and while it's feasible to support the visual in Safari, this would mean a lot of code gymnastic that is not worth supporting this nice-to-have visual. To give an idea of implementation: this would mean a `<g>` for each dot of the typing icon that requires deep integration of `Typing` and `DiscussAvatar` icons, and we should make sure that the styles are applied on the `<g>`. Also a `filter` was used to give better contrast of the typing dot and the green background, notably in dark theme. This is also removed by this commit specifically in Safari, as the technique uses `filter` which causes the bug in Safari. [1]: https://github.com/odoo/odoo/pull/260341 Task-6173311 Before / After <img width="630" height="296" alt="before" src="https://github.com/user-attachments/assets/e600a162-93be-4c11-b5bb-371c01eed773" /> <img width="630" height="298" alt="after" src="https://github.com/user-attachments/assets/36be873a-d24b-49b5-bf1e-e5e462491bde" />
This update fixes an issue where long Source Invoice names were overlapping with the Reference field in point-of-sale reports. A small margin has been added to the Source Invoice block to create more space and improve the report's readability. This ensures a cleaner and more professional presentation of invoice data.
Original PR description
Before this commit: - When the Source Invoice name is too long, it connect with the Reference field due to missing spacing. After this commit: - Added margin (`me-3`) to the Source Invoice block to ensure proper spacing and avoid overlap with the Reference field. task-6074560 | Before | After | |--------|--------| | <img width="801" height="474" alt="image" src="https://github.com/user-attachments/assets/cbef48f8-c37b-4263-8c6f-a6b0de3716b9" /> | <img width="780" height="462" alt="image" src="https://github.com/user-attachments/assets/fa01e0b5-d877-424f-a51f-8da0ce5a6bd5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256641
24 changes
Resolved issues and error corrections
This update ensures that when a company is quickly created through the equity module, the system correctly identifies it as a company. Previously, this wasn't happening, leading to incorrect data. The fix also includes a minor correction to view strings.
Original PR description
The partner_id field on all equity models represents a company. Therefore, quick-creating a partner_id should create it with is_company set to True. However, that wasn't the case. This commit fixes this issue by making sure that partner_id when quick-created in equity models has is_company set to True. It also fixes a typo in the string attribute of valuation list and form views. task-6132343 Forward-Port-Of: odoo/enterprise#114375
This update fixes an issue where unreconciling batch payments could unexpectedly revert vendor invoices to draft due to approval checks. The change allows for a necessary repost to complete the reconciliation process, even when third-party approval workflows are in place. This prevents users from needing to manually re-enter data.
Original PR description
When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module…
When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module (e.g. Studio Approvals) silently rejects action_post for the current user, the invoice stays in draft and the user has to redo the work manually. This internal repost is not a business action, the move was already approved when initially posted, so it can run as sudo to bypass approval checks. Steps to reproduce: 1. Add a Studio Approval rule on account.move.action_post with an approver other than the current user 2. As a user without that approval right, post a vendor bill and register a payment 3. Add the payment to a batch payment 4. Reconcile a bank statement line with the batch payment 5. With the user without approval rights, try to unreconcile the bank statement line (delete_reconciled_line) - Expected: the bill stays Posted. - Actual (before fix): the bill silently rolls back to Draft because action_post is rejected by the approval hook. opw-6121448 Forward-Port-Of: odoo/enterprise#115241
This update resolves an issue preventing kiosks from correctly communicating with new IoT box images. The fix ensures the correct message format is used, allowing the IoT box to process data properly. This improves the functionality of kiosks connected to the new IoT box infrastructure.
Original PR description
The new IoT box images expect the websocket messages to contain just `iot_identifier` and `device_identifier` instead of a list of `iot_identifiers` and `device_identifiers`. This method that the kiosk calls to send a message to the blackbox was not updated, causing the IoT box to ignore the message. This commit fixes the issue by adding the `iot_identifier` and `device_identifier` to the message. Forward-Port-Of: odoo/enterprise#115497
This update corrects a technical issue where styling applied to list views was incorrectly affecting other views within the account reports module. The fix ensures that styling is applied only to the intended list views, improving the visual consistency of the reporting interface. This resolves a minor cosmetic problem.
Original PR description
The css selector used to add the small border at the start of the line. So it end-up being applied in other view as well. task-6141685 Forward-Port-Of: odoo/enterprise#114903
This update resolves an issue where livechat channels with AI agents were not appearing correctly. The fix corrects a coding error that was preventing the system from accurately counting agents associated with each channel. This ensures all livechat channels, including those utilizing AI, are visible to users.
Original PR description
The number of agents linked to a livechat channel was always 0 because of a mistake in the code. This prevented livechat channels with AI agents from appearing to users. This commit fixes the problem. task-5409200 Forward-Port-Of: odoo/enterprise#111574
This update addresses a visual glitch in the composer where applying a list alignment option would sometimes cause a brief flicker and fail to apply correctly. The fix prevents a 'blur' event from triggering unnecessary DOM duplication, ensuring list alignment works reliably the first time.
Original PR description
Problem: When the chatter is open and text is selected, applying a list from the toolbar causes a flicker, and the list is sometimes not applied on the first attempt. Cause: Opening the list dropdown triggers a `blur` event on the `html_editor` field, which calls `getInlinedEditorContent` and duplicates the DOM to perform inlining. This unnecessary processing causes the visual flicker and may interrupt the list application. Solution: Prevent the field from blurring when selecting a list alignment option from the toolbar. Steps to reproduce: - Open a new record. - Open the composer. - Add text and select it. - Apply a list using the toolbar. - Observe that sometimes the list is not applied on the first try and the content briefly flickers. opw-6153261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261476
This update resolves an issue where invoices generated with the l10n_sa and l10n_sa_edi modules were displaying a duplicate tax number. The change ensures that company details now print the tax number only once, improving invoice accuracy and presentation. This was triggered by a previous update.
Original PR description
Before this change: - the additional_company_details would print a second tax number to invoice printout in l10n_sa After this change: - company details will print tax number only once Forward-Port-Of: odoo/odoo#261272
This update resolves an issue in the Bangladesh localization where an incorrect expense account was being automatically applied to inventory valuations. Removing this forced setting ensures that inventory accounting aligns with standard Bangladesh regulations and avoids unexpected stock variations.
Original PR description
Issue: The Bangladesh chart template sets account_stock_expense_id on the inventory valuation account. This triggers Stock Variation entries following perpetual continental behavior, which is not expected for Bangladesh localization. Cause: l10n_bd template data explicitly populated `account_stock_expense_id` for account `l10n_bd_100502`. Solution: Remove `account_stock_expense_id` from the Bangladesh account template mapping. opw-5944874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261311
This update corrects an issue where signatures were incorrectly duplicated on generated order PDFs after a signed order was modified. Moving forward, signatures will only be printed on documents created directly by the signature process, ensuring consistency and accuracy in order documentation. This enhances the reliability of our sales records.
Original PR description
A signed order can be modified afterward while retaining the signature on the newly generated PDF. After this commit, we will only print the signature on the document generated by the signature itself and not on any generated PDF afterwards. opw-6159170 Forward-Port-Of: odoo/odoo#261288
This update corrects a display issue where portal users could see a 'View Timesheets' button on invoices, even if they lacked the necessary permissions. The fix ensures the button only appears for users who actually have access to the related timesheets, improving data security and user experience.
Original PR description
sale: add sale order specific hook to extend page values ------ Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values sale_timesheet: hide 'View Timesheets'…
sale: add sale order specific hook to extend page values
------
Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values
sale_timesheet: hide 'View Timesheets' button for users without access
-------
Steps to Reproduce:
-----------------
- Create a product with the invoice policy set to Based on Timesheets
- Enable Project and Tasks on the order.
- Create and confirm a sale order using a portal user.
- Log timesheets on the related task.
- Create an invoice from the sale order.
- Log in as the portal user and open the invoice.
- Click the 'View Timesheets' button.
Issue:
-------------
The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets.
Root Cause:
------------
The timesheets are linked to the sale order, so the button appears based on the timesheet_count, but the portal user does not actually have permission to access those timesheets.
Fix:
-----------
We replaced the timesheet_count check with a check that verifies whether the user actually has access to any of the related timesheets.
task-4745519
Forward-Port-Of: odoo/odoo#261681
Forward-Port-Of: odoo/odoo#209552This update resolves a bug where portal users were incorrectly seeing the 'View Timesheets' button, even without the necessary permissions. The fix involved updating a helper method to ensure users only see the button when they have the appropriate access rights, improving the user experience and preventing confusion.
Original PR description
**Issue:** The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets. Currently, we have added _sale_order_get_page_view_values in the sale module, which is overridden in sale_timesheet. We are using it here. task-4745519 Forward-Port-Of: odoo/enterprise#115193 Forward-Port-Of: odoo/enterprise#113481
This update resolves an issue where reports for Withholding Taxes (WHT) were incorrectly mixed with VAT closing entries. Removing the specific return type for WHT ensures accurate reporting and prevents data confusion, leading to more reliable financial data. This improves the clarity and accuracy of financial reports.
Original PR description
WHT does not require a closing entry. The current return type is causing VAT closing entry to mix with WHT closing entry or vice versa. task-6157814
This update addresses a problem where payruns were incorrectly flagged as missing in the 19.1 release for the Belgian HR Payroll module. The fix removes a dependency on company-level closing dates, aligning the payrun logic with a previous request (GMF). This ensures accurate payrun generation and reporting.
Original PR description
In this commit, we removed the missing payrun issue from 19.1, since we are missing the closing_date in company-level and the missing payrun should depend on that value (GMF request). task-6008297
This update resolves an issue where the product description text area on iOS devices (specifically with Safari) would jump unexpectedly when typing. The fix removes a problematic sizing setting that was causing inaccurate scroll height calculations, ensuring the description field behaves correctly and allows users to enter text without the text area shifting.
Original PR description
Steps to reproduce ================== - Use an iPad device - Go to accounting - Sales > New - Add the product column in the invoices lines - Add a new line - Select a product - Add a description - press enter a bunch of times => the cursor will end up beneath the virtual keyboard - enter a letter => the textarea jumps above Cause of the issue ================== With Safari, setting a size on the widget root causes the scrollheight to be miscalculated. It doesn't take into account the last empty lines of the textarea. Solution ======== There is actually no need to set an height on the widget root node. opw-5927775 Forward-Port-Of: odoo/odoo#259855
This update corrects an issue where the Partner Ledger displayed incorrect initial balances when the date range filter wasn't used. The fix ensures that totals align with the sum of invoices, providing more accurate reporting for partner transactions. This improves the reliability of financial data.
Original PR description
To reproduce the issue: 1) Create an invoice of 100 € for partner A in 2025 2) Create another invoice of 200€ for the same partner in 2026 3) Open the Partner Ledger for 2026. Unfold A. It shows an initial balance of 100€ and a total of 300€. 4) In debug mode, open the Partner Ledger's form view and uncheck the date range option. 5) Open the Partner Ledger like in step 3) ====> An initial balance of 300€ shows, making the total of Partner A (still 300€) inconsistent with the sum of its sublines (600€) feedback-6042305 Forward-Port-Of: odoo/enterprise#115455
This update fixes a technical issue that prevented users from leaving live chat channels without triggering an error. The fix ensures the channel leaving process is executed only once, preventing access problems. This improves the stability and usability of the live chat feature for all users.
Original PR description
When a non-livechat user leaves a livechat channel after being invited, an access error occurs. This is due to `leaveChannelRpc` being called twice: once in `_onClose`and again in `leaveChannelProcess`. The first call removes the membership, while the second attempts to access the channel without proper rights, triggering the error. This commit fixes the issue by ensuring that `leaveChannelRpc` is only called once when leaving the channel. Task-[6072247](https://www.odoo.com/odoo/project/1519/tasks/6072247)
This update resolves an issue preventing the deletion of time off allocations when created after a payslip has been validated. Previously, the system incorrectly blocked deletion, requiring manual adjustments through HR. This change ensures time off can be deleted regardless of when it was created relative to payslip validation.
Original PR description
## Issue When creating a time off for a date that is already covered by a confirmed payslip, that time off cannot be deleted. ## Steps to reproduce 1. Install *Time Off in Payslips*…
## Issue
When creating a time off for a date that is already covered by a confirmed payslip, that time off
cannot be deleted.
## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
- Contract: Jan 1 to Indefinite
- Wage: $1000/month
3. In Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
4. In Time Off > Management > Time Off, create a new time off allocation for Employee E:
- Date: anywhere during March
- *Save* and *Validate*
5. Try to delete the allocation
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_**
## Cause
The condition under which this error is raised is defined in `_check_uncovered_by_validated_payslip`:
https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_payroll_holidays/models/hr_leave.py#L195-L203
It was originally added by https://github.com/odoo/enterprise/commit/1abb4a815ecb32557fc773cae54baf3e205d9b8c to prevent the deletion of holidays created **before** validating a payslip.
The condition does not take in account the moment when the leave was created. If a leave is created after the computation of the payslip, it did not impact that payslip, and thus can be deleted without risk.
opw-6089990
Forward-Port-Of: odoo/enterprise#114895This update fixes an error in how emission factors are converted within the Odoo Enterprise ESG module. The previous process incorrectly handled unit and currency conversions, leading to inaccurate calculations. This change ensures that emission calculations are now precise and reliable.
Original PR description
Issue: ---------------------------------------- The conversions using Emission factors are done in the wrong way. Steps to reproduce: ---------------------------------------- - Install `esg` module - Create an Emission Factor from ton to kg of 1000 - Create a new Emission using the new factor, set the unit as kg - Notice the conversion is wrong Cause: ---------------------------------------- The two uom are inverted when calling `_compute_quantity()`. Same occured for the currencies. opw-6152413 Forward-Port-Of: odoo/enterprise#115246
This update fixes a visual issue in the invoice report where long 'Source Invoice' names would overlap with the 'Reference' field. A small margin has been added to the 'Source Invoice' block to create more space and improve readability. This ensures a cleaner and more professional appearance of the report.
Original PR description
Before this commit: - When the Source Invoice name is too long, it connect with the Reference field due to missing spacing. After this commit: - Added margin (`me-3`) to the Source Invoice block to ensure proper spacing and avoid overlap with the Reference field. task-6074560 | Before | After | |--------|--------| | <img width="801" height="474" alt="image" src="https://github.com/user-attachments/assets/cbef48f8-c37b-4263-8c6f-a6b0de3716b9" /> | <img width="780" height="462" alt="image" src="https://github.com/user-attachments/assets/fa01e0b5-d877-424f-a51f-8da0ce5a6bd5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256641
This pull request addresses an issue with testing related to invoice rounding in the l10n_mx_edi module. It reverts a previous change that introduced errors in the test files, ensuring accurate calculations and reporting. This update maintains the integrity of financial data within the Mexican Electronic Invoicing system.
Original PR description
This reverts commit 50ad147e1f579a094141f6f126e02f75ecc62ab3. Forward-Port-Of: odoo/enterprise#115609
This update prevents users from starting polls while editing existing messages within channels or groups. Previously, the 'Start a Poll' action appeared misleadingly in the editor's menu. Now, the action is hidden when editing a message, ensuring it's only visible when composing a new message.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When editing a message in a channel or group and opening the 'More Actions' menu in the…
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When editing a message in a channel or group and opening the 'More Actions' menu in the composer, the 'Start a poll' action is displayed among the available options. Starting a poll while editing an existing message makes no sense, as polling is only meaningful when composing a new message. **Current behavior before PR:** ---------------------------------------------- - 'Start a poll' action appears in the composer 'More Actions' menu even when the user is editing an existing message - Clicking it while in edit mode opens the poll creation dialog, which is misleading and unintended behavior **Desired behavior after PR is merged:** ---------------------------------------------- - 'Start a poll' action is hidden from the 'More Actions' menu when the composer is in edit mode - The action continues to appear as expected when composing a new message in a channel or group conversation Task-6171541 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem where the size of the product search bar was incorrectly set, causing issues with a website tour. The fix ensures the search bar's size is only defined for the 'website_sale_renting' module, preventing disruptions to other website features.
Original PR description
__Before commit__ odoo/enterprise@1111381c set the size attribute of the product search bar. However, the view inherits from `website.website_search_box`, which means that all search boxes on the website will have the size attribute set if `website_sale_renting` is installed. The tour `dropdowns_and_header_hide_on_scroll` fails in saas-19.3 because odoo/odoo@9394e17a added a step that depends on the size of the main website search bar, which may vary because of this. __After commit__ Only set the size attribute to the product search bar as intended. runbot-242449
This update resolves minor issues within the point-of-sale test suite, specifically the checkTicketData() function. The changes ensure accurate test results by correctly handling empty data and preventing unexpected type conversions, ultimately increasing the reliability of our POS testing.
Original PR description
..., l10n_es_pos, l10n_jo_edi_pos, l10n_br_edi_pos
---
Fix two bugs in the checkTicketData() test helper:
- Replace falsy check `!statement` with `!statement.length` to
correctly handle empty NodeList results from querySelectorAll,
as an empty NodeList is still truthy.
- Replace loose equality `ruleFound == rule.negation` with strict
equality `ruleFound === (rule.negation || false)` to avoid
unintended type coercion when `rule.negation` is undefined.
---
Task: https://www.odoo.com/odoo/project/1737/tasks/6147566This update fixes a minor bug in the tests for our Point of Sale system. Specifically, it corrects how the tests handle empty data results and prevents unexpected behavior when comparing values. These changes ensure the tests run reliably and accurately, maintaining the stability of the POS functionality.
Original PR description
..., l10n_es_pos, l10n_jo_edi_pos, l10n_br_edi_pos
---
Fix two bugs in the checkTicketData() test helper:
- Replace falsy check `!statement` with `!statement.length` to
correctly handle empty NodeList results from querySelectorAll,
as an empty NodeList is still truthy.
- Replace loose equality `ruleFound == rule.negation` with strict
equality `ruleFound === (rule.negation || false)` to avoid
unintended type coercion when `rule.negation` is undefined.
---
Task: https://www.odoo.com/odoo/project/1737/tasks/61475664 changes
Resolved issues and error corrections
This update fixes an error in how emission factors are converted within the ESG module. Previously, unit and currency conversions were incorrectly applied, leading to inaccurate calculations. This change ensures accurate reporting of carbon emissions based on the selected unit of measure.
Original PR description
Issue: ---------------------------------------- The conversions using Emission factors are done in the wrong way. Steps to reproduce: ---------------------------------------- - Install `esg` module - Create an Emission Factor from ton to kg of 1000 - Create a new Emission using the new factor, set the unit as kg - Notice the conversion is wrong Cause: ---------------------------------------- The two uom are inverted when calling `_compute_quantity()`. Same occured for the currencies. opw-6152413 Forward-Port-Of: odoo/enterprise#115246
This update removes an unnecessary and invalid configuration setting from the website appointment builder's editing interface. The change was triggered by debug mode validation, which identified an outdated attribute. The underlying functionality is now handled more efficiently, ensuring a smoother editing experience for users.
Original PR description
Steps to reproduce: =================== 1. Enable debug mode (`?debug=assets`). 2. Open an appointment page in the website & edit mode. 3. Click the appointment type block. => Traceback "Invalid…
Steps to reproduce: =================== 1. Enable debug mode (`?debug=assets`). 2. Open an appointment page in the website & edit mode. 3. Click the appointment type block. => Traceback "Invalid props for component 'BuilderContext': unknown key 'reload'" Cause: ====== The `reload="'/'"` attribute on `<BuilderContext>` in appointment_type_option.xml was never a valid prop on the component: `basicContainerBuilderComponentProps` (the source of `BuilderContext`'s props) doesn't include `reload`. https://github.com/odoo/odoo/blob/f4700ba0f070003ac8a3828f9fd8583c27671e3f/addons/html_builder/static/src/core/utils.js#L887 In normal mode OWL silently ignores unknown attributes, but in debug mode prop validation runs and raises a Traceback Solution: ========= The reload behavior the actions actually need is already handled via `BuilderAction.isReload = true` in `appointment_type_option_plugin.js`, https://github.com/odoo/enterprise/blob/21ed8a6c1cad8d533d04659a3997c2d7e0c3965b/website_appointment/static/src/plugins/appointment_type_option_plugin.js#L35 so the attribute can be removed. opw-6152741
This update fixes an issue where the IRN (Invoice Reference Number) generated during e-invoicing wasn't correctly saved or displayed on the invoice itself. Now, the IRN number is accurately included in the generated Invoice PDF, ensuring complete invoice documentation for compliance. This improves the visibility and traceability of e-invoices.
Original PR description
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the settings. * Create a *customer invoice*. * Post the invoice. * Send the invoice through *E-Invoicing (EDI)*. * Open the generated *Invoice PDF* and the *form view*. **Observed behavior:** * The *IRN number* is correctly present in the *Invoice PDF*. * However, it is *not saved/displayed* in the invoice form view. **Cause:** * The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available. **Fix:** * Inherit *_l10n_in_edi_send_invoice*. * Add a condition after the invoice is sent and the JSON response is received. * When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case). opw-6097923 Forward-Port-Of: odoo/enterprise#114350
This update corrects an issue where the Partner Ledger displayed incorrect initial balances when the date range filter was not used. The fix ensures that the total balance aligns with the sum of all invoices within the ledger, providing more accurate financial reporting. This improves the reliability of partner financial data.
Original PR description
To reproduce the issue: 1) Create an invoice of 100 € for partner A in 2025 2) Create another invoice of 200€ for the same partner in 2026 3) Open the Partner Ledger for 2026. Unfold A. It shows an initial balance of 100€ and a total of 300€. 4) In debug mode, open the Partner Ledger's form view and uncheck the date range option. 5) Open the Partner Ledger like in step 3) ====> An initial balance of 300€ shows, making the total of Partner A (still 300€) inconsistent with the sum of its sublines (600€) feedback-6042305 Forward-Port-Of: odoo/enterprise#115455
6 changes
Resolved issues and error corrections
This update resolves an issue where power buttons were incorrectly displayed and overlapping other menu items within the HTML editor, particularly on smaller screens. The fix adjusts the editor's display based on its own width, ensuring buttons are hidden when they cause overlap, improving the user experience.
Original PR description
Problem: Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small. Solution: Instead of relying solely on the global…
Problem: Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small. Solution: Instead of relying solely on the global `ui.isSmall` (mobile detection), check the editor field's own width and hide power buttons whenever it falls below the overlap threshold. Before: <img width="576" height="301" alt="image" src="https://github.com/user-attachments/assets/dcebed55-5c80-4fe5-8d33-c320549cf347" /> After: <img width="542" height="336" alt="image" src="https://github.com/user-attachments/assets/34a233bb-9958-43ac-adb9-04702a2e403d" /> Steps to reproduce: - Change languange (French to have a long placeholder). - Settings > Customer Invoices > Default Terms & Conditions. - Check "Add a Note". - Resize the screen to smaller size. - Observe the power buttons overlap with the translate button. task-6117734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259094
This update corrects an issue where signatures were incorrectly duplicated on generated sales order PDFs after modification. Moving forward, signatures will only be printed on documents created directly by the signature process, ensuring consistency and accuracy in sales order documentation. This change enhances the reliability of our sales order generation.
Original PR description
A signed order can be modified afterward while retaining the signature on the newly generated PDF. After this commit, we will only print the signature on the document generated by the signature itself and not on any generated PDF afterwards. opw-6159170 Forward-Port-Of: odoo/odoo#261288
This update fixes an error in the Datev general ledger export that resulted in incorrect tax rates being reported. The issue stemmed from how multiple tax repartition lines were handled, leading to amounts being replaced instead of added. This ensures accurate tax reporting for Datev customers.
Original PR description
With l10n_de_reports: - Configure a foreign currency with an exchange rate. - Configure a tax with multiple repartition lines. - Create a vendor bill in this foreign currency with this tax. - In the general ledger export the datev csv. In the datev csv the rate is wrong. In the method _l10n_de_datev_get_csv, we build a tax_amount dict. However when one tax has multiple lines, the amount is replaced and not added. opw-6010097 Forward-Port-Of: odoo/enterprise#110453
This update corrects an issue where the Partner Ledger displayed incorrect initial balances when the date range filter wasn't used. The fix ensures that the total balance aligns with the sum of all invoices, providing more accurate financial reporting for partners. This improves the reliability of our accounting data.
Original PR description
To reproduce the issue: 1) Create an invoice of 100 € for partner A in 2025 2) Create another invoice of 200€ for the same partner in 2026 3) Open the Partner Ledger for 2026. Unfold A. It shows an initial balance of 100€ and a total of 300€. 4) In debug mode, open the Partner Ledger's form view and uncheck the date range option. 5) Open the Partner Ledger like in step 3) ====> An initial balance of 300€ shows, making the total of Partner A (still 300€) inconsistent with the sum of its sublines (600€) feedback-6042305 Forward-Port-Of: odoo/enterprise#115455
This update resolves an issue where unit prices were not being rounded correctly when generating Peppol invoices. This fix ensures accurate pricing information is included in invoices, improving compliance with Peppol standards and preventing potential discrepancies in financial reporting. The change reverts a previous commit that introduced this error.
Original PR description
This reverts commit d19223a148ab3476b83ed71346eb0712394b7de7. Forward-Port-Of: odoo/odoo#261941
A small update has replaced the previous video used in the website's editing interface with a new, available video. This ensures the website's video snippets continue to function correctly and avoid any display issues caused by the original video no longer being accessible. This is a routine maintenance fix.
Original PR description
Specification: - The previously embedded video used by the "s_video" snippet (id=G8b4UZIcTfg) is no longer publicly available. After this commit: - This commit replaces the default video with a new publicly available one (id=nbso3NVz3p8). task-6034987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261064 Forward-Port-Of: odoo/odoo#253874
1 change
Resolved issues and error corrections
This update corrects an issue where the Partner Ledger displayed incorrect initial balances when the date range filter was disabled. Previously, the total balance didn't match the sum of its individual transactions. This change ensures accurate reporting of partner balances, improving financial data reliability.
Original PR description
To reproduce the issue: 1) Create an invoice of 100 € for partner A in 2025 2) Create another invoice of 200€ for the same partner in 2026 3) Open the Partner Ledger for 2026. Unfold A. It shows an initial balance of 100€ and a total of 300€. 4) In debug mode, open the Partner Ledger's form view and uncheck the date range option. 5) Open the Partner Ledger like in step 3) ====> An initial balance of 300€ shows, making the total of Partner A (still 300€) inconsistent with the sum of its sublines (600€) feedback-6042305 Forward-Port-Of: odoo/enterprise#115455
14 changes
Resolved issues and error corrections
This update enhances the stability of WhatsApp tests by modernizing the testing framework. The team replaced an older, deprecated technology (Deferred) with a more current Promise-based approach, ensuring compatibility and reliability in future test runs. This change is part of a larger effort to maintain a robust and dependable Odoo Enterprise platform.
Original PR description
Replace Deferred with Promise.withResolvers in tests. [Part of task-5262203](https://www.odoo.com/odoo/1519/tasks/5262203) Community: https://github.com/odoo/odoo/pull/261739
This update corrects a reporting issue where payslips were incorrectly marked as 'paid' during the generation of payment reports. The change ensures that payslips are accurately reflected in reports, improving the reliability of payroll accounting data. This resolves a potential discrepancy in financial reporting.
Original PR description
…t generation Forward-Port-Of: odoo/enterprise#115273
This update corrects a potential error in the account reports module where custom modules could cause conflicts with standard 'state' fields. The fix ensures that column references are clearly defined, preventing ambiguous column errors during report generation and improving data accuracy.
Original PR description
Issue: ------- There are cases where clients might have the same named 'state' field/column for custom modules in the models 'res.partner' or 'account.fiscal.position' and therefore they might get conflicted with the standard one's when the below query executes, https://github.com/odoo/enterprise/pull/84391/changes#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29R1359 and can cause ``` File "/home/odoo/src/enterprise/account_reports/models/account_return.py", line 2204, in _check_suite_common_vat_report self.env.cr.execute(SQL( File "/home/odoo/src/odoo/odoo/sql_db.py", line 433, in execute self._obj.execute(query, params) psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 9: state = 'posted' ``` Solution: ------------ Use the corresponding alias while mentioning the column i.e; `move.state = 'posted'` OPW - 6044665 Forward-Port-Of: odoo/enterprise#114341
A minor technical issue was resolved where the wrong function was being used within the VoIP sales module. This fix ensures the system functions correctly and prevents potential errors in call processing. The change is considered low impact.
Original PR description
Shh! We used the wrong function. Forward-Port-Of: odoo/enterprise#114869
A recent update caused a crash when viewing customer previews after signing a Field Service worksheet. This fix corrects a misapplication of a previous patch that was adding unnecessary base64 encoding to signature data. By removing this encoding, the customer preview now functions correctly.
Original PR description
Steps to reproduce: - 1. Install 'planning_field_service_worksheet'. 2. Open a Field Service planning slot, pick a worksheet template that has a signature property, and sign it. 3. From the slot, open the customer preview (portal page). Issue: - The customer preview crashes with a traceback. Cause: - Commit https://github.com/odoo-dev/enterprise/commit/b6997ed6f9a8fc29233e1d324e91bbda7eae4df2 added .to_base64() on prop['value'] to follow the same pattern as: https://github.com/odoo-dev/odoo/commit/c62d1cec96498f424c42aee87b1428a4615d576c , which fixed real Binary/Image fields that returns BinaryValue objects. That patch was misapplied here. The signature value in this template does not come from a Binary field, it comes from a Properties field, so signature data is already stored as a base64 encoded str. Fix: - Drop the .to_base64() call and embed prop['value'] directly, since it is already a base64 string. task-6157798 Forward-Port-Of: odoo/enterprise#115231
This update ensures vehicle license plates are included in invoice exports only when the Enterprise module (`account_accountant_fleet`) is active. It also resolves a bug related to tax calculations, preventing incorrect line splitting. This improves data consistency across different Odoo versions and database types.
Original PR description
[FIX] account_accountant_fleet: vehicle sent in XML when an invoice line has a vehicle linked, the vehicle license plate will be in the export XML file only if the enterprise module `account_accountant_fleet` is installed. Any community db will then not have the ref included This commit moves the vehicle data in `account_fleet` to expose it to community dbs Also fix a bug when expense is installed: super was not called in a method about tax lines, causing side effects (splitting repartition lines when it shouldn't) runbot-242562 Forward-Port-Of: odoo/enterprise#114902
This update resolves a minor issue in the account reports module by correcting a sign error for the CTA value. The changes involve simplifying queries and functions within the module to improve efficiency and stability. This ensures accurate reporting data.
Original PR description
Followup PR of odoo/enterprise#103529 * Simplification of some queries * Simplification of functions * Sign correction for cta value Forward-Port-Of: odoo/enterprise#114338
This update simplifies the setup of financial accounts for Sri Lankan businesses by reducing the complexity of account codes. New lines for equity and liabilities have been added to the Balance Sheet report, providing a more complete financial picture. This change enhances flexibility and accuracy in reporting.
Original PR description
Reduces Balance Sheet account code formulas from 3-digit to 2-digit prefixes to make the COA setup more flexible. New equity and liability lines are also added to the Balance Sheet. Community PR: https://github.com/odoo/odoo/pull/260920 task-6141758 Forward-Port-Of: odoo/enterprise#115340 Forward-Port-Of: odoo/enterprise#114768
This update ensures that when a company is quickly created through the equity module, the system correctly identifies it as a company. Previously, this wasn't happening, leading to incorrect data. Additionally, a minor typo was corrected in the user interface for improved clarity.
Original PR description
The partner_id field on all equity models represents a company. Therefore, quick-creating a partner_id should create it with is_company set to True. However, that wasn't the case. This commit fixes this issue by making sure that partner_id when quick-created in equity models has is_company set to True. It also fixes a typo in the string attribute of valuation list and form views. task-6132343 Forward-Port-Of: odoo/enterprise#114375
This update resolves an issue where the SBR tax report wizard would crash if an SBR certificate wasn't configured. The change ensures the wizard gracefully handles missing certificates, guiding users to the correct settings and preventing errors. This improves report generation reliability for users in the Netherlands.
Original PR description
In the SBR tax report wizard, the code previously attempted to access the `pem_certificate` attribute on a potentially empty recordset if no certificate was configured (see [here](https://github.com/odoo-dev/enterprise/commit/0b50021bdae54779396d75d3cddbd9eb42571553)). This resulted in an AttributeError before the validation check could trigger the intended RedirectWarning. This commit fixes the logic by: * Checking for the existence of the `cert_sudo` recordset immediately after retrieval. * Raising the RedirectWarning if the certificate record is missing, guiding the user to the Accounting Settings. * Accessing the certificate and private key content only after confirming the record exists. no-task Forward-Port-Of: odoo/enterprise#115489
This update fixes a problem where payment reminder emails for subscriptions were missing the subscription's closing date. The fix ensures that all payment reminder emails, regardless of how they're sent (automatically or manually), accurately display the subscription's end date. This improves the clarity and accuracy of payment notifications.
Original PR description
### Issue before this commit: When sending a payment reminder email for a subscription using the email composer, the template was not correctly populated with the expected dynamic values. In…
### Issue before this commit: When sending a payment reminder email for a subscription using the email composer, the template was not correctly populated with the expected dynamic values. In particular, fields such as the subscription closing date and the subscription code were missing. ### Steps to reproduce the issue: 1. Install subscription and go to that app 2. Open one subscription 3. Send message > Load template: "Subscription: Payment Reminder" 4. Sentence is incomplete: missing end date of the subscription ### Cause of the issue: The issue was caused by the absence of a proper context injection when rendering the email template from the mail.compose.message wizard. The template relied on context variables like date_close, but these values were not being computed nor passed during manual email composition. Unlike automated flows, the composer did not provide the subscription-specific context required by the template. ### Reason to introduce the fix: The fix makes the payment reminder and closing templates self-sufficient by replacing context-based values with fields and helper methods directly available on the subscription record. A dedicated method is introduced to compute the subscription close date consistently, so the templates render the expected values both in automated flows and when manually loaded from the email composer. opw-6031613 Forward-Port-Of: odoo/enterprise#115164 Forward-Port-Of: odoo/enterprise#111801
This update simplifies the returns process by removing the 'reviewed' state. Now, returns are automatically considered ready for submission once all required checks are complete, improving efficiency. This change reduces manual steps and speeds up the return workflow.
Original PR description
task-5266305
This update ensures that Timesheet reports are only generated for invoices with service lines, not goods-only invoices. Previously, irrelevant reports were automatically created and attached, leading to wasted resources and potential confusion. This change improves efficiency and accuracy in invoice sending.
Original PR description
Before this PR: --- - When adding the Timesheets dynamic report to the "Invoice: Sending" email template, it was always included in the Send & Print wizard. - Even if the invoice contained only goods and no timesheet-based service lines, the Timesheets PDF was generated. - The wizard built attachment placeholders purely from the mail template configuration without validating invoice content. - As a result, irrelevant Timesheets PDFs were generated and attached to goods-only invoices. After this PR: --- - The Timesheets dynamic report is generated only when the invoice contains at least one timesheet-based service line. - For goods-only invoices, the Timesheets report does not appear in the Send & Print attachments widget. - The wizard now filters dynamic report placeholders based on actual invoice content. - Unnecessary Timesheets PDFs are no longer generated or sent. Related - https://github.com/odoo/odoo/pull/187381 task - 5361456
This update addresses an issue where Coda transaction files sometimes lacked complete data, leading to default 'No description' labels appearing on bank statements. The change ensures accurate payment references by handling potential missing data from the Coda file, preventing incorrect statement line descriptions.
Original PR description
It can happens that coda file with transaction have no communication or structure communication. This can cause problem since we will have an empty payment_ref for the statement line. This will add "No description" as a default value. task-6045138 Forward-Port-Of: odoo/enterprise#111300
8 changes
Resolved issues and error corrections
This update resolves an issue preventing kiosks from communicating correctly with the new IoT box images. The fix ensures the correct message format is used, allowing the IoT box to receive and process data properly. This improves compatibility and functionality for kiosk users.
Original PR description
The new IoT box images expect the websocket messages to contain just `iot_identifier` and `device_identifier` instead of a list of `iot_identifiers` and `device_identifiers`. This method that the kiosk calls to send a message to the blackbox was not updated, causing the IoT box to ignore the message. This commit fixes the issue by adding the `iot_identifier` and `device_identifier` to the message.
This update fixes an error in how emission factors are converted within the ESG module. The previous system incorrectly handled unit and currency conversions, leading to inaccurate calculations. This change ensures that emission calculations are now precise and reliable.
Original PR description
Issue: ---------------------------------------- The conversions using Emission factors are done in the wrong way. Steps to reproduce: ---------------------------------------- - Install `esg` module - Create an Emission Factor from ton to kg of 1000 - Create a new Emission using the new factor, set the unit as kg - Notice the conversion is wrong Cause: ---------------------------------------- The two uom are inverted when calling `_compute_quantity()`. Same occured for the currencies. opw-6152413 Forward-Port-Of: odoo/enterprise#115246
This update fixes an issue where the IRN number, generated during e-invoicing, wasn't being saved to the customer invoice. Now, the IRN number is correctly displayed in both the invoice PDF and the invoice form view after the EDI submission process, ensuring accurate record-keeping for GSTR reporting.
Original PR description
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the settings. * Create a *customer invoice*. * Post the invoice. * Send the invoice through *E-Invoicing (EDI)*. * Open the generated *Invoice PDF* and the *form view*. **Observed behavior:** * The *IRN number* is correctly present in the *Invoice PDF*. * However, it is *not saved/displayed* in the invoice form view. **Cause:** * The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available. **Fix:** * Inherit *_l10n_in_edi_send_invoice*. * Add a condition after the invoice is sent and the JSON response is received. * When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case). opw-6097923 Forward-Port-Of: odoo/enterprise#114350
This update resolves an issue preventing the generation of VAT Books in the Spanish version of Odoo Enterprise. A change in the button logic required updating the XPath expression to avoid errors. The VAT Books now open successfully after this fix.
Original PR description
After an update, the t-if of the button was changed, and it was necessary to adapt the xpath to avoid errors After the change, the VAT Books opened without problems task-6170173
This update resolves a minor visual issue where the bank reconciliation popover was incorrectly displayed on all lines, even those without relevant transactions. The fix ensures the popover only appears when appropriate, improving the user experience and preventing unnecessary visual clutter. This is a low-impact fix.
Original PR description
In this commit:https://github.com/odoo/enterprise/commit/5d88ae9fc1e1f43797fe7d9118a0582f949dc7be we changed the way the popover was working to make it display on hover but forgot to add the condition to display the popover. It means that it was display for every line even the one without exchange move or partial reconcile, so there was a small visual glitch no task id
This update corrects a bug in the appointment booking process for flexible scheduling. Previously, a 20-minute slot was incorrectly serialized, leading to a 404 error. The fix ensures accurate slot duration calculation, resolving the booking issue and improving the user experience.
Original PR description
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment for 20 min. Issue: - 404 Error occurs after selectiong the slot Cause: - In 19.0, commit https://github.com/odoo/enterprise/commit/9bae0e13e7bf5e0db25a60fc2683bc51eccb4447 started using slot.duration when building the booking URL for flexible slots. However, slot.duration is rounded to 2 decimals, so a 20-minute slot is serialized as 0.33 instead of its exact value. During validation, the end datetime is recomputed from this rounded duration, which no longer matches the original slot boundaries. This mismatch causes the slot to be considered invalid and the controller raises NotFound. Solution: - Compute the slot duration directly from slot_start_dt_tz and slot_end_dt_tz when building the URL, preserving the full precision. opw-5924312
This update fixes an issue where the Partner Ledger displayed incorrect initial balances when the date range filter wasn't used. The fix ensures that partner balances accurately reflect all transactions, resolving inconsistencies between totals and subline amounts. This improves the reliability of financial reporting.
Original PR description
To reproduce the issue: 1) Create an invoice of 100 € for partner A in 2025 2) Create another invoice of 200€ for the same partner in 2026 3) Open the Partner Ledger for 2026. Unfold A. It shows an initial balance of 100€ and a total of 300€. 4) In debug mode, open the Partner Ledger's form view and uncheck the date range option. 5) Open the Partner Ledger like in step 3) ====> An initial balance of 300€ shows, making the total of Partner A (still 300€) inconsistent with the sum of its sublines (600€) feedback-6042305 Forward-Port-Of: odoo/enterprise#115455
This update corrects a technical error that prevented users from editing appointment pages in the website builder. The issue stemmed from an unnecessary attribute being included in the BuilderContext component, which was flagged by debug mode. This change ensures a smoother editing experience for all users.
Original PR description
Steps to reproduce: =================== 1. Enable debug mode (`?debug=assets`). 2. Open an appointment page in the website & edit mode. 3. Click the appointment type block. => Traceback "Invalid…
Steps to reproduce: =================== 1. Enable debug mode (`?debug=assets`). 2. Open an appointment page in the website & edit mode. 3. Click the appointment type block. => Traceback "Invalid props for component 'BuilderContext': unknown key 'reload'" Cause: ====== The `reload="'/'"` attribute on `<BuilderContext>` in appointment_type_option.xml was never a valid prop on the component: `basicContainerBuilderComponentProps` (the source of `BuilderContext`'s props) doesn't include `reload`. https://github.com/odoo/odoo/blob/f4700ba0f070003ac8a3828f9fd8583c27671e3f/addons/html_builder/static/src/core/utils.js#L887 In normal mode OWL silently ignores unknown attributes, but in debug mode prop validation runs and raises a Traceback Solution: ========= The reload behavior the actions actually need is already handled via `BuilderAction.isReload = true` in `appointment_type_option_plugin.js`, https://github.com/odoo/enterprise/blob/21ed8a6c1cad8d533d04659a3997c2d7e0c3965b/website_appointment/static/src/plugins/appointment_type_option_plugin.js#L35 so the attribute can be removed. opw-6152741 Forward-Port-Of: odoo/enterprise#115242
5 changes
Resolved issues and error corrections
This update ensures that signatures are only applied to the original sales order document generated by the signature process, not to subsequent PDF copies. Previously, signatures were duplicated on all generated PDFs, leading to inconsistencies. This change streamlines the process and maintains accurate signature records.
Original PR description
A signed order can be modified afterward while retaining the signature on the newly generated PDF. After this commit, we will only print the signature on the document generated by the signature itself and not on any generated PDF afterwards. opw-6159170 Forward-Port-Of: odoo/odoo#261288
This update corrects a technical issue that could cause problems with voice message tests in Odoo. Specifically, the system was prematurely resolving promises related to voice playback, leading to potential errors. This fix ensures that the voice player is fully drawn before promises are resolved, improving test reliability and stability.
Original PR description
Before this commit, voice message tests don't wait until the voice player is drawn before resolving the corresponding promise. This may lead to race conditions. This commit fixes the issue by properly `await`ing the completion of the asynchronous code before resolving the promise. Related runbot error: https://runbot.odoo.com/odoo/error/163783 Forward-Port-Of: odoo/odoo#261795
A test within the MRP module was failing due to a dependency on a module only available in the Enterprise version of Odoo. This update removes the problematic dependency, ensuring the test now runs successfully across both Community and Enterprise environments. This resolves a consistent test failure and improves overall test coverage.
Original PR description
The test `test_multi_lot_component_consumption` relies on `move_raw_line_ids`, which is initialized by the `stock_barcode_mrp` module. This module is only available in enterprise, causing the test to fail in community setups. https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/mrp/tests/test_consume_component.py#L494 runbot-242612
This update resolves an issue in the LDAP authentication testing process where the test left behind data in the database. By switching to a simpler `HttpCase` test setup, the problem is fixed and paves the way for adding another test to address a related bug. This ensures the stability and reliability of our LDAP integration.
Original PR description
The unit test is tagged `-standard` and `database_breaking` because it was leaving left overs in the database. Using an `HttpCase` over a `BaseCase` solves that issue in addition to make the code way simpler. We want to resurrect this unit test class because we plan to add another unit test in that class for a bug fix. Forward-Port-Of: odoo/odoo#261743
This update fixes a bug where users without the necessary permissions were encountering errors when trying to access their profile information. The team added a field to the user data structure to allow access to country codes, resolving the permission issue and ensuring all users can view their profile details.
Original PR description
Issue: - When a user without access rights tries to view their profile, a permission error is raised. - Issue PR: https://github.com/odoo/odoo/pull/254162 Fix: - Added `employee_country_code` to SELF_READABLE_FIELDS in `res.users`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255260
2 changes
Resolved issues and error corrections
This update corrects a technical issue that caused problems with voice message tests. Specifically, the system was resolving promises prematurely, leading to potential errors. This fix ensures that asynchronous operations complete before promises are resolved, improving test stability and reliability.
Original PR description
Before this commit, voice message tests don't wait until the voice player is drawn before resolving the corresponding promise. This may lead to race conditions. This commit fixes the issue by properly `await`ing the completion of the asynchronous code before resolving the promise. Related runbot error: https://runbot.odoo.com/odoo/error/163783
This update fixes an issue where users lacking the necessary permissions encountered a permission error when trying to access their profile information. The fix involves adding the 'employee_country_code' field to a list of accessible fields, ensuring all users can view their profile details. This improves usability and prevents errors for a wider range of users.
Original PR description
Issue: - When a user without access rights tries to view their profile, a permission error is raised. - Issue PR: https://github.com/odoo/odoo/pull/254162 Fix: - Added `employee_country_code` to SELF_READABLE_FIELDS in `res.users`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr