Daily updates from Odoo
Navigate
Branch
Wednesday, April 29, 2026
260 changes
14 changes
Enhancements to existing features
This update implements changes required by a new Vietnamese tax regulation (Decree 175/2025) regarding VAT rates on specific goods and services. It allows businesses to generate and export Appendix 142 reports, which are necessary for declaring transactions with the reduced 8% VAT rate. Enterprises meeting specific criteria can now avoid submitting this report.
Original PR description
According to Decree 175/2025/NĐ-CP, an decrease of 2% will be applied to a certain goods and services which has 10% VAT rate (from 10% to 8%) and this will be effective until 12/2026 according to Decision 205/2025/QH15. This decision will be considered after that to decide if 8% VAT rate will be still applied. Appendix 142 report is meant to declare those operations and is only for Purchased and Sold goods with 8% VAT rate. For enterprises which satisfies these two following conditions don't have to submit Appendix 142: + Don't have both input and output invoices related to products & services with applied decreased tax rate (8%) + Only have input but not output invoices related to products & services with applied decreased tax rate (8%) We want to allow users to view and export form 01/GTGT and Appendix 142 with xml format from Odoo. task-5498205
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#261702A recent update broke the layout of the payment method form in the Safaricom POS module, making it difficult for users to configure payment terminals. This commit resolves the issue by simplifying the view structure, ensuring the form displays correctly and functions as intended. This improves the user experience for configuring Safaricom payment terminals.
Original PR description
The nested `group` elements in the `pos_payment_method_views.xml` view in `pos_safaricom` caused the layout of the form to break when the module is installed. More specifically, the entire right…
The nested `group` elements in the `pos_payment_method_views.xml` view in `pos_safaricom` caused the layout of the form to break when the module is installed. More specifically, the entire right column of the form loses all the field labels, making it very difficult to fill out the information to configure a payment terminal. This commit fixes the issue by removing the `group` elements from the view, instead just using the `field` elements directly as is done in other payment terminal modules. Before (Safaricom selected): <img width="678" height="504" alt="image" src="https://github.com/user-attachments/assets/9c41643f-1a98-4e44-9493-f0e6e8161a50" /> Before (Viva selected): <img width="674" height="371" alt="image" src="https://github.com/user-attachments/assets/409f5c7a-da13-4f90-8145-a1ed5d6bbf7f" /> After (Safaricom selected): <img width="674" height="531" alt="image" src="https://github.com/user-attachments/assets/a3118563-39a3-4c41-a807-296e531abe58" /> After (Viva selected): <img width="665" height="447" alt="image" src="https://github.com/user-attachments/assets/51140a28-1fca-4d94-a81e-d45e081024a2" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261746
This 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 resolves a bug that prevented expense card creation when the hr_expense_stripe module was installed without the mail_tracking module. The fix ensures that necessary tracking values are copied, allowing users to successfully process expense cards using Stripe. This improves the reliability of the expense reporting workflow.
Original PR description
In odoo/odoo#235719, the tracking values have been moved to a separate module. Step to reproduce: - Install hr_expense_stripe_demo without mail_tracking (or uninstall it) - Setup the stripe issuing account - Create an employee - Create a card and assign that employee - It will fail with a tracking since `tracking_value_ids` doesn't exist on the message
This update resolves a bug where pasting a list item directly into the HTML editor would cause the main content area of the application to disappear after saving. The fix ensures that newly pasted list items are correctly wrapped within a list container, preventing the browser from incorrectly removing surrounding elements.
Original PR description
Problem: Pasting a `<li>` element inside a header block caused `<main>` and `<footer>` to disappear after saving. The browser's HTML parser ejects everything following an orphaned `<li>` (one without a `<ul>`/`<ol>` parent) out of its ancestor tree. Cause: The root cause was `closestElement(selection.anchorNode, listElementSelector)` finding a `<ul>`/`<ol>` ancestor that was not a direct parent of the insertion point, resulting in a `<li>` being inserted without a wrapping list element. Steps to reproduce: - Copy a `<li>` element and paste it in the Text Element in the header. - Save - `<main>` content disappears from the page. opw-6113857 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260320
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
This update resolves an issue where the automated reporting cron job for vendor invoices wasn't correctly identifying the target company in multi-company setups. The fix ensures invoices are fetched from the correct company, preventing errors and improving the reliability of the reporting process. This avoids disruptions to invoice reporting.
Original PR description
In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553 Forward-Port-Of: odoo/enterprise#115350 Forward-Port-Of: odoo/enterprise#113254
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 resolves a performance issue that caused slowdowns and crashes when working with many2many fields containing a large number of records. The fix replaces a slow search method with a faster one, ensuring smoother operation and preventing UI freezes for users handling extensive datasets.
Original PR description
### Issue before this commit: When handling many2many fields with a large number of records (e.g., 20k+), the client-side performance degraded significantly. In extreme cases, the browser became…
### Issue before this commit: When handling many2many fields with a large number of records (e.g., 20k+), the client-side performance degraded significantly. In extreme cases, the browser became unresponsive or crashed when triggering onchange or compute logic. ### Steps to Reproduce: Create a computed many2many field. Add it to a form view (can be invisible). Populate the related model with a large dataset (20k+ records). Trigger an onchange that recomputes the field. ### Cause of the Issue: In _applyCommands (LINK case), the system checks for existing record IDs using Array.includes(), which has O(n) time complexity. When handling thousands of records, repeated ID lookups using includes() result in O(n²) complexity. ### With This Commit: Replaced Array.includes() with a Set (Set.has()), reducing lookup time to O(1). The set is updated incrementally as new IDs are added, improving overall complexity to O(n) and preventing UI freezes for large datasets. opw-6122024 Forward-Port-Of: odoo/odoo#261319 Forward-Port-Of: odoo/odoo#260993
The Profit and Loss report for French associations was displaying incorrect financial figures due to an error in the report formulas. This update fixes the inverted signs in the report, ensuring accurate calculations and correct totals for association financial reports. This resolves a key issue impacting financial reporting accuracy.
Original PR description
### Issue: The Profit and Loss report for associations shows incorrect values with inverted signs, leading to wrong totals in the final computation ### Cause: In 19.1, a new fiscal localization package for associations as been added In the report `account_financial_report_l10n_fr_cdr_asso`, all formulas in the `Operating income (I)` section are incorrectly inverted The equivalent section in `account_financial_report_l10n_fr_cdr_column_2024` is correct, where accounts are properly inverted in the formulas ### Steps to reproduce: - Install `l10n_fr_reports` - Create and switch to a French company - In Accounting Settings, select the fiscal localization: `France - Associations accounting plan` - Create and confirm an invoice (any amount) - Open `Profit and Loss` and select `Profit and loss account for associations (FR)` Before the fix, the Operating Income (I) is negative opw-6117967 Forward-Port-Of: odoo/enterprise#114414
26 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 fixes an issue where the system incorrectly determined if an Italian VAT-registered company was recognized based on the length of its Codice Fiscale (tax ID). Specifically, the system was only recognizing CFs exactly 11 characters long. This change ensures that CFs, including country-prefixed ones, are correctly interpreted, preventing partners from being incorrectly classified as individuals.
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 an issue where export files for Hong Kong payroll reports were not formatted correctly for the IRD platform. The fix includes adding a required file header encoding and ensuring the correct BOM is included, allowing reports to be properly processed by the IRD.
Original PR description
Following recent tests, we noticed that the encoding used when exporting our XML files doesn't follow the required format. We noticed two issues during testing: - The IRD platform expects the file to have BOM included. - The encoding in the header must be capitalized. We solve this in this commit by prepending the BOM bytes to the xml bytes; and making sure to capitalize the URF-8 in the header. task-6150470 --- Note: There will be a lot to do during forward ports, as these have changed quite a bit. (XML support for the other file types, and a proper testing file, at least) Forward-Port-Of: odoo/enterprise#115227
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 resolves a bug where pasting an individual list item (`<li>`) into the header area would cause the main content of the page to disappear after saving. The fix ensures that newly pasted list items are correctly wrapped within a list container, preventing the browser from incorrectly removing surrounding elements.
Original PR description
Problem: Pasting a `<li>` element inside a header block caused `<main>` and `<footer>` to disappear after saving. The browser's HTML parser ejects everything following an orphaned `<li>` (one without a `<ul>`/`<ol>` parent) out of its ancestor tree. Cause: The root cause was `closestElement(selection.anchorNode, listElementSelector)` finding a `<ul>`/`<ol>` ancestor that was not a direct parent of the insertion point, resulting in a `<li>` being inserted without a wrapping list element. Steps to reproduce: - Copy a `<li>` element and paste it in the Text Element in the header. - Save - `<main>` content disappears from the page. opw-6113857 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260320
A recent update broke the layout of the payment method form in the Safaricom POS module, making it difficult for users to configure payment terminals. This commit resolves the issue by simplifying the view structure, ensuring the form displays correctly and functions as intended. This improves the user experience for configuring Safaricom payment terminals.
Original PR description
The nested `group` elements in the `pos_payment_method_views.xml` view in `pos_safaricom` caused the layout of the form to break when the module is installed. More specifically, the entire right…
The nested `group` elements in the `pos_payment_method_views.xml` view in `pos_safaricom` caused the layout of the form to break when the module is installed. More specifically, the entire right column of the form loses all the field labels, making it very difficult to fill out the information to configure a payment terminal. This commit fixes the issue by removing the `group` elements from the view, instead just using the `field` elements directly as is done in other payment terminal modules. Before (Safaricom selected): <img width="678" height="504" alt="image" src="https://github.com/user-attachments/assets/9c41643f-1a98-4e44-9493-f0e6e8161a50" /> Before (Viva selected): <img width="674" height="371" alt="image" src="https://github.com/user-attachments/assets/409f5c7a-da13-4f90-8145-a1ed5d6bbf7f" /> After (Safaricom selected): <img width="674" height="531" alt="image" src="https://github.com/user-attachments/assets/a3118563-39a3-4c41-a807-296e531abe58" /> After (Viva selected): <img width="665" height="447" alt="image" src="https://github.com/user-attachments/assets/51140a28-1fca-4d94-a81e-d45e081024a2" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261746
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
This update resolves an issue where the automated invoice fetching cron job in multi-company Odoo environments was failing due to incorrect company settings. The fix ensures invoices are retrieved from the correct company associated with each move, preventing errors and improving data accuracy for reporting.
Original PR description
In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553 Forward-Port-Of: odoo/enterprise#115350 Forward-Port-Of: odoo/enterprise#113254
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 fixes an issue where tax return rounding wasn't correctly applied when companies had multiple branches. The previous system aggregated rounding data, leading to inaccurate closing entries. The fix ensures that rounding is calculated and applied correctly for each individual company and branch, improving tax reporting accuracy.
Original PR description
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax…
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax report. When having a company with branches, the rounding is applying in each closing move (one per company/branch) but the value is coming from the aggregated report lines, this leads to wrong computation of the closing entries. Cause: In `_generate_tax_closing_entries` we loop over each company, therefore `_compute_tax_closing_entry` is called one time for each company, but it uses the report options containing all companies Fix: Use options with only the current company in `_compute_tax_closing_entry` Steps: - Install FR localisation - Select FR company and create two branches - Create, for last month: - 1 bill for parent company (100 with tax 20% G) - 1 invoice per branch (200 and 300 with tax 20% G) - Create a tax return with opining date at the beginning of the current month - Submit the last return and go to the created closing entries -> See that closing entries are wrong opw-5976359 Forward-Port-Of: odoo/enterprise#115116 Forward-Port-Of: odoo/enterprise#110652
This update fixes an error in the Profit & Loss report for French associations, where values were incorrectly inverted, leading to inaccurate financial totals. The fix ensures the report now displays correct financial data for association accounting, resolving a key issue impacting reporting accuracy.
Original PR description
### Issue: The Profit and Loss report for associations shows incorrect values with inverted signs, leading to wrong totals in the final computation ### Cause: In 19.1, a new fiscal localization package for associations as been added In the report `account_financial_report_l10n_fr_cdr_asso`, all formulas in the `Operating income (I)` section are incorrectly inverted The equivalent section in `account_financial_report_l10n_fr_cdr_column_2024` is correct, where accounts are properly inverted in the formulas ### Steps to reproduce: - Install `l10n_fr_reports` - Create and switch to a French company - In Accounting Settings, select the fiscal localization: `France - Associations accounting plan` - Create and confirm an invoice (any amount) - Open `Profit and Loss` and select `Profit and loss account for associations (FR)` Before the fix, the Operating Income (I) is negative opw-6117967 Forward-Port-Of: odoo/enterprise#114414
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 fixes an issue where byproducts added directly to manufacturing orders weren't correctly linked to stock movements, preventing accurate tracking of production. The change ensures byproducts added through the MO are properly associated with stock moves, resolving a discrepancy in origin location data.
Original PR description
When we add a byproduct followed by SN directly in the MO it will not have the its location as production. Steps to reproduce: ------------------- * Create product tracked by Serial number * Create a…
When we add a byproduct followed by SN directly in the MO it will not have the its location as production. Steps to reproduce: ------------------- * Create product tracked by Serial number * Create a Manufacturing order * Add the Product tracked by serial number on the MO as byproduct * Confirm the MO * Go to shop floor * Add the by-product quantity and create a new serial number. * Close production and go back to the MO in manufacturing * Open stock moves -> the by-product does not have "production" for origin Observation: ------------- When we add the byproduct directly in the MO, they will be added to move_byproduct_ids in the MO but not in byproduct_ids on the stock.move because byproduct_ids it's a [link](https://github.com/odoo/odoo/blob/d14bf6289da21065860ff959185c47b947a7418c/addons/mrp/models/stock_move.py#L50-L52) between the stock.move and the BOM. When adding the byproduct in shopfloor, it will create the quant: https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163-L171 Additionaly when creating the quant it will decide the source location depending if the product its a byproduct: https://github.com/odoo/enterprise/blob/1d10ee238a50e7bdb552efdeafc068c5127cd49a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L189-L192 The issue arise because it check if the product it's a byproduct by checking byproduct_ids and since our product was added directly on the MO and not from the BOM it will not appear in byproduct_ids https://github.com/odoo/enterprise/blob/dc5bb0fe8e15063f977970841bdaf8aff1a61e41/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L108-L110 #### Additional notes: The default value for [byproduct_id](https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/mrp/models/mrp_production.py#L1263) when creating the stock move is false opw-5974582 Forward-Port-Of: odoo/enterprise#110122
This update resolves an issue where commission calculations were failing for subscription plans due to an empty currency rate table. The fix adds a fallback rate, ensuring commissions are correctly calculated even when currency rates haven't been manually set. This ensures accurate commission payments for recurring subscription orders.
Original PR description
Steps to reproduce: 1- Installed sale_commission_subscription and accounting 2- Go to [Sales -> Commissions -> Commission Plans] 3- Create a new commission plan of type MRR, specify a salesperson and approve 4- Go to Subscriptions app and create a new order with a recurring monthly plan and specify the same salesperson 5- Create an invoice for the order and confirm it 6- Go back to the commission plan and click on the Commissions smart button Issue: Commissions show up as 0 Expected behavior: Should have the corresponding commission based on the rate specified Why this happens: The `res_currency_rate` table is empty by default and only gets populated if you are in a multi-currency environment and sync the rates in the settings or by manually making a currency rate entry. Since the commission calculation depends on this table, it results in 0 rows when joining the sub-query. opw-6108580 Forward-Port-Of: odoo/enterprise#114354
This update fixes an issue where the ewallet discount was incorrectly included in delivery pricing calculations. The change adjusts the pricing logic to accurately exclude ewallet amounts from delivery costs, ensuring consistent and accurate shipping charges for customers. This improves the user experience and prevents unexpected delivery fees.
Original PR description
Issue: --- Ewallet line is included in delivery pricing. Steps to reproduce: 1- Create a delivery method `based on rules`. 2- In pricing set rules: - price <= 99 => delivery price = 30 - price > 99…
Issue: --- Ewallet line is included in delivery pricing. Steps to reproduce: 1- Create a delivery method `based on rules`. 2- In pricing set rules: - price <= 99 => delivery price = 30 - price > 99 => delivery price = 50 3- Create a eWallet with balance = 200. 4- Create a SO add a line with product. Set the SOL unit amount to 100. 5- Click on `add a shipping`. Add the created delivery method. 6- As you see, the delivery amount is correctly calculated. 7- Now apply the eWallet using `reward` button. 8. Update the shipping cost. The shipping cost is 30, which is not expected. Cause: --- In calculation of shipping amount the ewallet is not taken into account. Even though technically it's considered a discount, ewallet is not functionally the same as discount. However, in `_get_price_available` we cannot have information about `ewallet` lines as it doesn't depend on `sale_loyalty`. Fix: --- We use `_compute_amount_total_without_delivery` which is overridden in `sale_loyalty_delivery` to exclude ewallet and gift cards. opw-6124209 Forward-Port-Of: odoo/odoo#260134
19 changes
Resolved issues and error corrections
This update corrects a technical issue preventing proper export of Hong Kong payroll XML files to the IRD platform. The fix ensures the correct file encoding and format (including a required BOM) are used, resolving a compatibility problem. This ensures accurate data transmission for tax reporting.
Original PR description
Following recent tests, we noticed that the encoding used when exporting our XML files doesn't follow the required format. We noticed two issues during testing: - The IRD platform expects the file to have BOM included. - The encoding in the header must be capitalized. We solve this in this commit by prepending the BOM bytes to the xml bytes; and making sure to capitalize the URF-8 in the header. task-6150470 --- Note: There will be a lot to do during forward ports, as these have changed quite a bit. (XML support for the other file types, and a proper testing file, at least) Forward-Port-Of: odoo/enterprise#115227
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 resolves a bug where pasting a list item directly into the HTML editor would cause the main content area of the application to disappear after saving. The fix ensures that newly pasted list items are correctly wrapped within a list container, preventing the browser from incorrectly removing surrounding elements.
Original PR description
Problem: Pasting a `<li>` element inside a header block caused `<main>` and `<footer>` to disappear after saving. The browser's HTML parser ejects everything following an orphaned `<li>` (one without a `<ul>`/`<ol>` parent) out of its ancestor tree. Cause: The root cause was `closestElement(selection.anchorNode, listElementSelector)` finding a `<ul>`/`<ol>` ancestor that was not a direct parent of the insertion point, resulting in a `<li>` being inserted without a wrapping list element. Steps to reproduce: - Copy a `<li>` element and paste it in the Text Element in the header. - Save - `<main>` content disappears from the page. opw-6113857 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260320
This update resolves a layout problem in the Safaricom POS payment method configuration form. The previous design caused the right column to disappear, making it difficult for users to set up payment terminals. The fix simplifies the view structure, ensuring the form displays correctly and functions as intended.
Original PR description
The nested `group` elements in the `pos_payment_method_views.xml` view in `pos_safaricom` caused the layout of the form to break when the module is installed. More specifically, the entire right…
The nested `group` elements in the `pos_payment_method_views.xml` view in `pos_safaricom` caused the layout of the form to break when the module is installed. More specifically, the entire right column of the form loses all the field labels, making it very difficult to fill out the information to configure a payment terminal. This commit fixes the issue by removing the `group` elements from the view, instead just using the `field` elements directly as is done in other payment terminal modules. Before (Safaricom selected): <img width="678" height="504" alt="image" src="https://github.com/user-attachments/assets/9c41643f-1a98-4e44-9493-f0e6e8161a50" /> Before (Viva selected): <img width="674" height="371" alt="image" src="https://github.com/user-attachments/assets/409f5c7a-da13-4f90-8145-a1ed5d6bbf7f" /> After (Safaricom selected): <img width="674" height="531" alt="image" src="https://github.com/user-attachments/assets/a3118563-39a3-4c41-a807-296e531abe58" /> After (Viva selected): <img width="665" height="447" alt="image" src="https://github.com/user-attachments/assets/51140a28-1fca-4d94-a81e-d45e081024a2" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261746
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 resolves an issue where the automated report generation process (cron) incorrectly fetched vendor invoices when running with a default company different from the intended target companies. The fix ensures invoices are retrieved from the correct company, preventing errors and improving the reliability of the reporting process.
Original PR description
In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553 Forward-Port-Of: odoo/enterprise#115350 Forward-Port-Of: odoo/enterprise#113254
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 fixes an issue where tax return rounding wasn't correctly applied when a company had multiple branches. The previous system aggregated rounding values, leading to inaccurate closing entries. The fix ensures that rounding is calculated and applied correctly for each company and branch, improving tax reporting accuracy.
Original PR description
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax…
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax report. When having a company with branches, the rounding is applying in each closing move (one per company/branch) but the value is coming from the aggregated report lines, this leads to wrong computation of the closing entries. Cause: In `_generate_tax_closing_entries` we loop over each company, therefore `_compute_tax_closing_entry` is called one time for each company, but it uses the report options containing all companies Fix: Use options with only the current company in `_compute_tax_closing_entry` Steps: - Install FR localisation - Select FR company and create two branches - Create, for last month: - 1 bill for parent company (100 with tax 20% G) - 1 invoice per branch (200 and 300 with tax 20% G) - Create a tax return with opining date at the beginning of the current month - Submit the last return and go to the created closing entries -> See that closing entries are wrong opw-5976359 Forward-Port-Of: odoo/enterprise#115116 Forward-Port-Of: odoo/enterprise#110652
This update resolves an issue where generating timesheets after archiving an employee would trigger an error. The fix prevents timesheets from considering time-off requests for previously archived staff, ensuring accurate timesheet generation. This improves data integrity and prevents disruptions to payroll processes.
Original PR description
[FIX] project_timesheet_holidays: Exclude archived employees from time-off # Description of the issue/feature this PR addresses: ## Steps to Reproduce: 1. Create a time off for Employee A (it should…
[FIX] project_timesheet_holidays: Exclude archived employees from time-off # Description of the issue/feature this PR addresses: ## Steps to Reproduce: 1. Create a time off for Employee A (it should affect the timesheets). 2. Create a new public holiday (global time off) that overlaps with Employee A’s time off. 3. Archive Employee A. 4. Delete the public holiday created in step 2. 5. An error related to timesheet generation appears. ## Expected Behavior: - The public holiday / global time off should be deleted without any error. # Desired behavior after PR is merged: ## Fix (Implemented): When regenerating timesheets due to changes in holidays or time off, leaves related to archived employees should not be taken into account. A check was added inside the `_generate_timesheets` function in `project_timesheet_holidays/models/hr_holidays.py` to exclude leaves belonging to archived employees. ## Alternative Fix (Not Implemented): Instead of filtering out leaves linked to archived employees, we could delete those leaves when an employee is archived. However, this approach is not ideal, as archived employees may be reactivated later and would still need their previously requested time off to be preserved. ## Version: This bug appears in both version 17.0 and 19.0. I assumed that it also appears in 18.0 but didn't directly test ## Task: [5474038](https://www.odoo.com/odoo/project/4105/tasks/5474038) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261412 Forward-Port-Of: odoo/odoo#244203
This update resolves an issue where the 'Remove Format' function would get stuck in an infinite loop when applied to text with icons and background colors in the To-do app. The fix ensures that icons are correctly identified and processed during format removal, preventing the loop and restoring normal functionality.
Original PR description
Steps to reproduce: =================== 1. Open the To-do app and pick any task. 2. In the description add text and an icon with a bg color. `(you can add this: <i class="fa rounded rounded-circle…
Steps to reproduce: =================== 1. Open the To-do app and pick any task. 2. In the description add text and an icon with a bg color. `(you can add this: <i class="fa rounded rounded-circle fa-user bg-o-color-1 fa-4x" contenteditable="false"></i>)` 3. Select all and click "Remove format". Result: -> Traceback due to an infinite loop. Cause: ====== Remove format calls `removeAllColor()`, which loops forever at: https://github.com/odoo/odoo/blob/626bde21a25366d0bb29662bae2057c247a1638e/addons/html_editor/static/src/main/font/color_plugin.js#L194-L194 Why: _applyColor doesn't remove the icon's background class, so hasAnySelectedNodeColor keeps returning true and the removal loop never terminates. This happens because `font` is already the `<i>` element with the `fa` class, using `querySelectorAll` on it won't include the element itself, so the icon is never checked or updated. https://github.com/odoo/odoo/blob/6cdc6f55886ea48e90f9023a6c6142bf072745b9/addons/html_editor/static/src/main/font/color_plugin.js#L290 Solution: ========= Check if the font itself has the fa class before doing the `querySelectorAll`, and include it in the nodes to check for color. Test Impact: ============ Before this fix, a `<span>` containing an icon was wrapped in a `<font>` when applying color, treating the icon as a normal span (without size) instead of applying the color directly. https://github.com/odoo/odoo/blob/8792c2d38eb0aadac8d778d83fd76f270404ecd5/addons/html_editor/static/src/main/font/color_plugin.js#L397 opw-5928627 Forward-Port-Of: odoo/odoo#261405 Forward-Port-Of: odoo/odoo#248449
This update resolves a technical issue preventing blackbox orders on self-order kiosks from generating correct receipts. The change re-introduced a necessary field, '_server_version', to the configuration, ensuring the kiosk can properly validate and create receipts. This ensures consistent receipt generation for a critical point of sale function.
Original PR description
In odoo/odoo#258744, the `pos_self_order` module was optimised to only send the fields required for the kiosk to function. This also meant the `_server_version` field was no longer sent in the `pos.config`. Because of this, there is now a traceback when validating a blackbox order in the self order kiosk, as it relies on the `_server_version` field to make the receipt. This commit fixes the issue by adding the `_server_version` to the `pos.config` as an override in the `pos_blackbox_be` module.
2 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 fixes a bug 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
5 changes
Resolved issues and error corrections
This update strengthens the security of our Xendit payments by ensuring that each payment is linked to the correct transaction using an access token. Previously, payments could be processed without this verification, creating a potential risk. Now, only authorized payments tied to a specific transaction will be processed, enhancing overall security.
Original PR description
**Description of the issue/feature this PR addresses:** The `/payment/xendit/payment` endpoint did not enforce validation of an access token tied to the transaction when processing direct payment requests. **Current behavior before PR:** The endpoint accepted public requests using only the transaction reference, allowing payment execution without verifying that the request was linked to the intended transaction. **Desired behavior after PR is merged:** The endpoint now requires a valid access_token associated with the transaction (reference) before processing. This ensures that payment execution is restricted to the correct transaction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261616 Forward-Port-Of: odoo/odoo#260258
This update fixes an issue where the product amount in the sales preview was incorrectly showing tax excluding prices. The change ensures that the preview and PDF reports accurately display the total price, including taxes, when 'Tax Included' is selected in company settings. This improves the accuracy of sales quotes and reports.
Original PR description
**Steps to produce:** - Install `sale_management` without demo data. - In settings > Under Taxes > Set `Tax Prices` as `Tax Included`. - Create a product with a sales price of 10. - Create a…
**Steps to produce:** - Install `sale_management` without demo data. - In settings > Under Taxes > Set `Tax Prices` as `Tax Included`. - Create a product with a sales price of 10. - Create a quotation with this product. - Confirm the line amount shows 10 (tax included). - Click on preview. **Observation:** - In the preview, the product line amount is shown as tax excluded. **Root cause:** - At [1], when in the company setting `tax included` is selected, the system displays `price_total` instead of `price_subtotal`. - This logic is not applied in the portal preview and PDF report. **Solution:** - Apply the same logic in portal preview and PDF reports: display `price_total` when taxes are included, otherwise `price_subtotal`. [1]https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/sale/views/sale_order_views.xml#L656-L663 Before: --- <img width="1031" height="384" alt="image" src="https://github.com/user-attachments/assets/743abbec-9225-4f77-894b-193052ee8e42" /> After: --- <img width="1052" height="391" alt="image" src="https://github.com/user-attachments/assets/61d2b331-e197-4ca0-a71d-e307d9bf80fe" /> opw-6089473 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258551
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
1 change
Resolved issues and error corrections
This update fixes a bug 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
24 changes
New functionality added to Odoo
This update adds quick access buttons to payslips, making it easier for users to view and edit employee time entries and attendance records. Previously, accessing these records was more complex, especially when the payslip wasn't part of a payrun. The change also removes an unnecessary field setting.
Original PR description
Currently, if the payslip is not in a payrun, it is harder to reach a screen to edit time entries. This PR adds/adjusts stat buttons on the payslip form to facilitate access to time off and attendances of payslip's employee. Also removing the admin group form the `attendance_based` field as it is not needed. task-6110624
Enhancements to existing features
This update enhances the Sales Order Gantt chart by displaying the commercial partner's name alongside the order number. Previously, users could only see the order number, making it difficult to quickly identify the customer associated with each Sales Order group. This change improves clarity and efficiency when reviewing sales planning.
Original PR description
Before this PR --- - When grouping Planning Gantt by Sales Order, only the order number was displayed, making it hard to identify which customer an order belongs to After this PR --- - Sales Order groups display the commercial partner name alongside the order number (e.g. "S00027 - Acme Corporation") for better identification task - 5140117
This update implements changes required by a new Vietnamese tax regulation (Decree 175/2025) regarding VAT rates on specific goods and services. It allows businesses to generate and export Appendix 142 reports, which are necessary for declaring transactions with the reduced 8% VAT rate. Certain businesses are exempt from submitting this report based on specific invoice criteria.
Original PR description
According to Decree 175/2025/NĐ-CP, an decrease of 2% will be applied to a certain goods and services which has 10% VAT rate (from 10% to 8%) and this will be effective until 12/2026 according to Decision 205/2025/QH15. This decision will be considered after that to decide if 8% VAT rate will be still applied. Appendix 142 report is meant to declare those operations and is only for Purchased and Sold goods with 8% VAT rate. For enterprises which satisfies these two following conditions don't have to submit Appendix 142: + Don't have both input and output invoices related to products & services with applied decreased tax rate (8%) + Only have input but not output invoices related to products & services with applied decreased tax rate (8%) We want to allow users to view and export form 01/GTGT and Appendix 142 with xml format from Odoo. task-5498205 Forward-Port-Of: odoo/enterprise#112572
This update removes unnecessary data from the internal data structures used in account reporting. This optimization improves the performance and efficiency of generating reports, particularly for large datasets. The change focuses on internal improvements within the account_reports module.
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 fixes an issue where the BIK (Business Income Key) calculation for company cars wasn't accurately reflecting changes throughout the month. The system now correctly updates the BIK monthly based on the employee's car usage, ensuring accurate payroll calculations and compliance. This impacts the 'l10n_be_hr_payroll_fleet' module.
Original PR description
**Description of the issue/feature this PR addresses:** When there is a change of car during a month, the employee will have 2 versions but all will be merged on the same payslips but currently only the BIK of one version is taken into account (or no BIK if the employee has no company car anymore) **Current behavior before PR:** . car_atn value equal the yearly_atn / 12 . ATN.CAR rule returns the car_atn value of the first version **Desired behavior after PR is merged:** . Update the car_atn value to be computed monthly, based on the number of calendar days in the current month . Update ATN.CAR payslip rule, it get the value of the car's atn on the current payslip month then prorated based on the versions periods within the payslip period . Modify the corresponding tests . Add corresponding tests task-6108696 Forward-Port-Of: odoo/enterprise#115022 Forward-Port-Of: odoo/enterprise#113484
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 fixes a critical issue where IoT events were missed due to a failure in the longpolling fallback mechanism. Now, if longpolling fails, the system automatically switches to using the more reliable WebSocket connection, preventing disruptions like failed Worldline payment confirmations. This ensures consistent event delivery.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/260931 Before this commit, if `onMessage` in `iot_http_service` was called directly, it would fail to fallback to websocket if the longpolling request failed, causing events to be missed. One symptom of this is Worldline payments failing to confirm when using websocket. After this commit, the `_longpolling` method will now throw an error in this case, causing the fallback mechanism to attempt websocket instead. Forward-Port-Of: odoo/enterprise#115277 Forward-Port-Of: odoo/enterprise#114779
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 resolves an issue where the vendor invoice fetching cron job in multi-company Odoo environments was failing due to incorrect company settings. The fix ensures invoices are retrieved from the correct company associated with each move, preventing errors and improving data accuracy.
Original PR description
In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553 Forward-Port-Of: odoo/enterprise#115350 Forward-Port-Of: odoo/enterprise#113254
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
The Profit & Loss report for French associations was displaying incorrect financial figures due to an error in the report formulas. This update fixes the issue by correcting the formulas in the report, ensuring accurate calculations of income and expenses for association accounting. This ensures financial reporting aligns with French accounting standards for associations.
Original PR description
### Issue: The Profit and Loss report for associations shows incorrect values with inverted signs, leading to wrong totals in the final computation ### Cause: In 19.1, a new fiscal localization package for associations as been added In the report `account_financial_report_l10n_fr_cdr_asso`, all formulas in the `Operating income (I)` section are incorrectly inverted The equivalent section in `account_financial_report_l10n_fr_cdr_column_2024` is correct, where accounts are properly inverted in the formulas ### Steps to reproduce: - Install `l10n_fr_reports` - Create and switch to a French company - In Accounting Settings, select the fiscal localization: `France - Associations accounting plan` - Create and confirm an invoice (any amount) - Open `Profit and Loss` and select `Profit and loss account for associations (FR)` Before the fix, the Operating Income (I) is negative opw-6117967 Forward-Port-Of: odoo/enterprise#114414
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 fixes several issues within the AI chat interface, primarily improving readability and preventing formatting errors. Specifically, the font size of headings was adjusted to better suit the chat channel size, and a bug causing random asterisks within AI responses was resolved. This ensures a cleaner and more accurate user experience.
Original PR description
- The font-size of h1/h2 headers is large given the small size of chat channels which makes it harder to read the rest of the text. So, the font-size of h1/h2 headers is reduced in ai chat channels. - This commit removes the double border at the bottom of tables and updates the table borders by using table-bordered bootstrap class instead of border. - This commit also fixes an error where markdown2 2.4.11 doesn't detect the boundaries of bold markup properly causing asterisks to appear randomly inside AI responses. For example, "The **dog**, the **cat** and the **rat**" becomes "The <strong>dog<em>*, the *</em>cat<em>* and the *</em>rat</strong>" where it should only use <strong>dog/cat/rat</strong> task-6109286 Forward-Port-Of: odoo/enterprise#114687 Forward-Port-Of: odoo/enterprise#114592
This update ensures that the AI chat window opens in full-screen mode when initiated from the system tray or command palette. Previously, the chat opened in the background, which was inconvenient. This change improves the user experience for interacting with the AI assistant.
Original PR description
Prior to this commit, when opening the chat with an agent from the systray button, the chat window was opened in the background. This commit fixes the issue by adding a call to `channel.open` which opens the chat when in full-screen mode. This commit also fixes an issue where the chat window wasn't properly opened when done from the command palette. task-5172978 Forward-Port-Of: odoo/enterprise#115165 Forward-Port-Of: odoo/enterprise#114598
This update fixes a bug where commission calculations were failing for recurring subscription orders. The issue stemmed from an empty currency rate table, which prevented the system from correctly applying commission rates. The fix adds a fallback rate, ensuring commissions are calculated accurately for all subscription orders, regardless of currency settings.
Original PR description
Steps to reproduce: 1- Installed sale_commission_subscription and accounting 2- Go to [Sales -> Commissions -> Commission Plans] 3- Create a new commission plan of type MRR, specify a salesperson and approve 4- Go to Subscriptions app and create a new order with a recurring monthly plan and specify the same salesperson 5- Create an invoice for the order and confirm it 6- Go back to the commission plan and click on the Commissions smart button Issue: Commissions show up as 0 Expected behavior: Should have the corresponding commission based on the rate specified Why this happens: The `res_currency_rate` table is empty by default and only gets populated if you are in a multi-currency environment and sync the rates in the settings or by manually making a currency rate entry. Since the commission calculation depends on this table, it results in 0 rows when joining the sub-query. opw-6108580 Forward-Port-Of: odoo/enterprise#114354
This update corrects a bug that was causing overtime work entries to incorrectly generate on previous days. The fix adjusts how work entries are calculated, considering employee timezones to ensure accurate date comparisons and prevent incorrect overtime assignments. This ensures payroll calculations are reliable.
Original PR description
How to reproduce: - Select an employee with an overtime ruleset and work entries based on attendances - Create attendance with an approved overtime - Go to "Work Entries" in Payroll, and regenerate…
How to reproduce: - Select an employee with an overtime ruleset and work entries based on attendances - Create attendance with an approved overtime - Go to "Work Entries" in Payroll, and regenerate the work entries for the following day of the attendance - A new overtime work entry is generated on the first day. Reason: Because of how regenerating work entries is done, the computed date for searching overtime lines took into account the previous day (i.e. regenerating a work entry for a tuesday in an UTC+1 timezone made it so the starting date was on monday at 23:00:00), and since the _read_group only looked at the date part of the time start without taking into account the hour, it included the overtime of the previous day. How it was fixed: The domain now takes into account the timezone of the employee to generate the domain for the _read_group to ensure the correct day is selected Task ID: 5899657 Forward-Port-Of: odoo/enterprise#115289 Forward-Port-Of: odoo/enterprise#107266
3 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
4 changes
Resolved issues and error corrections
This update resolves a bug preventing website appointment syncs from appearing in Outlook calendars. Previously, a timing issue with the synchronization cron prevented events created through website appointments from being properly synced. The change ensures all calendar events, including those from website appointments, are consistently synchronized with Outlook.
Original PR description
Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of…
Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of microsoft_last_sync_date, when _sync_data is not called when a calendar.event is created, such as through website.appointment. microsoft_last_sync_date was set to datetime.now() at the beginning of _sync_microsoft_calendar, which would skip a large period of time between the last sync and now, if the only syncs were triggered through cron, and not _sync_data (by opening the calendar app). To reproduce, Default "Outlook: synchronization" is ran every 12 hours. 1) Calendar event is synced through "Outlook: synchronization" cron at 00:00, setting microsoft_last_sync_date to 00:00 2) A website.appointment is created for a resource with Outlook calendar sync enabled any time between 00:01 - 11:54. 3) "Outlook: synchronization" runs again at 12:00, which sets microsoft_last_sync_date to 12:00, and filters out calendar.events based on their write_dates in _extend_microsoft_domain that need syncing outside of 11:55 to 12:00. This change removes setting of microsoft_last_sync_date at the beginning of _sync_microsoft_calendar, where we need to use the old value before setting it at the end of _sync_microsoft_calendar. opw-5212908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 simplifies the process for Dutch companies to manage their digipoort certificates within the accounting settings. Previously, users had to navigate to a separate menu to create a certificate before setting it in the main accounting configuration. Now, users can directly create and edit digipoort certificates within the existing settings, improving the user experience.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566
This update corrects a situation where invoices rejected by the tax system (SdI) were incorrectly marked as 'sent,' preventing users from resubmitting them. The change automatically clears this 'sent' flag when an invoice is rejected, allowing invoices to be re-submitted after the issue is resolved. This improves the invoicing process and reduces manual intervention.
Original PR description
When an invoice is rejected by the SdI or by a PA partner, the move remained flagged as sent, preventing the user from resending it after fixing the underlying issue. Override write() on account.move to clear is_move_sent whenever l10n_it_edi_state transitions to 'rejected' or 'rejected_by_pa_partner', so the invoice can be re-submitted. task-4490454 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
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