Daily updates from Odoo
Wednesday, April 29, 2026
46 changes · saas-19.2
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
This update ensures that missing payslip issues are only triggered when the payroll closing date has passed. This prevents unnecessary alerts and streamlines the payroll process by focusing on actual overdue payments. It maintains the existing logic for identifying missing payslips.
Original PR description
In this commit, missing payslip in a payrun issue will be raised only if the payroll closing date is due (old conditions remains). task-6008297
This update ensures that payslip simulations accurately reflect current salary rules. Previously, simulations were based on the contract start date, which could lead to incorrect net pay calculations over time. This fix corrects the calculation method to use the current date, guaranteeing accurate pay simulations.
Original PR description
When the salary configurator is used, it generate a simulation payslip to know get a net value based on the gross. It should be done at the current date, because if it is at contract_start day, maybe years ago, it'll use wrong salary rules values to compute it
This update allows accountants to retain KSEF XML files associated with invoices. Previously, these files were automatically discarded after being used to fetch data. Now, the XML files are saved as attachments to the corresponding invoice, providing a backup for longer-term record-keeping requirements.
Original PR description
Description of the issue this commit addresses: When fetching the bills from ksef, the xml with the data about the move is received, parsed and then discarded but the XML can be required to be kept for longer than ksef keeps it so we are lacking a way for an accountant to download it and store it locally. --- Desired behavior after this commit is merged: When a move is fetched from ksef via an xml file, that file is put as an attachment on the move created with its data. --- task-6076505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259655
This update resolves an issue where users could unintentionally bypass tax group checks during chart template changes in the l10n_ar module. The update now requires developers to explicitly handle the removal of tax groups, ensuring data integrity and stability. This change restores previous behavior and prevents unexpected errors.
Original PR description
Commit 947e4dc9de3a replaced MODULE_UNINSTALL_FLAG with an explicit 'force_delete' context flag, and as the commit message warns, callees that relied on the previous flag must now detect 'force_delete' on their own. There is no automatic bypass anymore. **STEP TO REPRODUCE** 1.- Install l10n_ar 2-. Select one argentinian regime (fiscal package) & save 3-. Try to change package **FIX** Detect 'force_delete' in check_uninstall_required and return early, restoring 19.0 behavior. Manual deletions of the tax group are still blocked. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261561
This update fixes an issue where the product description field on iOS devices (specifically with Safari) would jump unexpectedly when typing. The problem stemmed from incorrect calculations of the text area's height. The fix removes unnecessary sizing constraints, ensuring the description field resizes correctly and provides a better user experience for adding product details on iPads.
Original PR description
Steps to reproduce ================== - Use an iPad device - Go to accounting - Sales > New - Add the product column in the invoices lines - Add a new line - Select a product - Add a description - press enter a bunch of times => the cursor will end up beneath the virtual keyboard - enter a letter => the textarea jumps above Cause of the issue ================== With Safari, setting a size on the widget root causes the scrollheight to be miscalculated. It doesn't take into account the last empty lines of the textarea. Solution ======== There is actually no need to set an height on the widget root node. opw-5927775 Forward-Port-Of: odoo/odoo#259855
A recent issue prevented activity updates from being shared correctly across different tabs within Odoo. This fix corrects a typo that was causing this problem, ensuring activity states are now consistently synchronized for all users. This improves the reliability of task tracking and collaboration.
Original PR description
Since [1], the activity state, which is supposed to be shared accross tab through a broadcast channel, isn't anymore. This PR fixes the responsible typo. [1]: #161286 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259810 Forward-Port-Of: odoo/odoo#255785
This update resolves a visual issue in Safari where the 'is typing' indicator icon was misaligned. The fix avoids complex styling techniques that triggered a bug related to Safari's rendering engine, ensuring the indicator displays correctly. This improves the user experience for Safari users.
Original PR description
Before this commit, "is typing" icon in Safari browser was misplaced with relative to Discuss Avatar image. This happens due to a bug in Safari that affects `foreignObject` with elements that use…
Before this commit, "is typing" icon in Safari browser was misplaced with relative to Discuss Avatar image. This happens due to a bug in Safari that affects `foreignObject` with elements that use some CSS rules, like `opacity`. A prior fix was done to apply on change of opacity with classnames [1], which fixed "offline" icon but is typing still has issues: - change of opacity doesn't use classname, this is coupled to animation frame in CSS - the "is typing" icon uses `filter` and `transform`, both of which are also a problem This commit fixes the issue by not using icon animation for Safari browsers. The rules were mostly used for the animation, and while it's feasible to support the visual in Safari, this would mean a lot of code gymnastic that is not worth supporting this nice-to-have visual. To give an idea of implementation: this would mean a `<g>` for each dot of the typing icon that requires deep integration of `Typing` and `DiscussAvatar` icons, and we should make sure that the styles are applied on the `<g>`. Also a `filter` was used to give better contrast of the typing dot and the green background, notably in dark theme. This is also removed by this commit specifically in Safari, as the technique uses `filter` which causes the bug in Safari. [1]: https://github.com/odoo/odoo/pull/260341 Task-6173311 Before / After <img width="630" height="296" alt="before" src="https://github.com/user-attachments/assets/e600a162-93be-4c11-b5bb-371c01eed773" /> <img width="630" height="298" alt="after" src="https://github.com/user-attachments/assets/36be873a-d24b-49b5-bf1e-e5e462491bde" />
This update fixes an issue where long Source Invoice names were overlapping with the Reference field in point-of-sale reports. A small margin has been added to the Source Invoice block to create more space and improve the report's readability. This ensures a cleaner and more professional presentation of invoice data.
Original PR description
Before this commit: - When the Source Invoice name is too long, it connect with the Reference field due to missing spacing. After this commit: - Added margin (`me-3`) to the Source Invoice block to ensure proper spacing and avoid overlap with the Reference field. task-6074560 | Before | After | |--------|--------| | <img width="801" height="474" alt="image" src="https://github.com/user-attachments/assets/cbef48f8-c37b-4263-8c6f-a6b0de3716b9" /> | <img width="780" height="462" alt="image" src="https://github.com/user-attachments/assets/fa01e0b5-d877-424f-a51f-8da0ce5a6bd5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256641
This update fixes an issue where the system incorrectly flagged payruns as 'missed' reports due to delayed STP submission dates. The change ensures that payruns are accurately identified for Single Touch Payroll reporting, regardless of when the payment is processed, preventing potential ATO reporting errors.
Original PR description
When a payslip is created after the submission of a previous payrun, it should trigger an update event to ensure the missed payslip is reported to the ATO with the totals, including all the slips already paid. It currently uses the submit date of STP to check if it's a missed report. However, sometimes the submit/payment date might be set in the future for a delayed payment of the payrun. In this case, the new payrun should not be considered as a missed payrun as it is still the correct order. This fix uses past payslip dates to check if a payrun is a missed report or not, instead of using the submit/payment date of STP. task-6134865 Forward-Port-Of: odoo/enterprise#114280
This update resolves an issue where unit prices were not being rounded correctly when generating invoices for Peppol transactions. This fix ensures accurate pricing calculations for these important international trade processes, improving data integrity and compliance. The change reverts a previous commit that introduced the problem.
Original PR description
This reverts commit d19223a148ab3476b83ed71346eb0712394b7de7. opw-6169870 Forward-Port-Of: odoo/odoo#261941
This pull request addresses a problem with testing related to invoice rounding in the l10n_mx_edi module. It reverts a previous change that was causing test failures. The fix ensures accurate invoice calculations and reporting for Mexican tax purposes.
Original PR description
This reverts commit 50ad147e1f579a094141f6f126e02f75ecc62ab3. Forward-Port-Of: odoo/enterprise#115610
This update resolves a bug where the cumulated balance calculation in the general ledger was incorrect when using journal groups. The fix ensures that the balance is properly computed when all journals are selected through the journal filter, addressing a discrepancy caused by previous filter logic.
Original PR description
Usually the journal filters doesn't allow the selection of all journals when no journal group is present. However, when a journal group is added, the journal filters allow the selection of all the journal groups to be valid. So, we end up with a filter Journals, with all journals selected but the cumulated balance is not computed. To fix this, if all the journals are selected in the Journals filter, we dont add the journal_ids filter. Step to reproduce: - On any journal, create a journal group - Go to the general ledger - In the Journals filter select "Local Gapp" and the created journal group - Click the journal items button on the line of any account - The cumulated balance will be at 0 even when all the journals are selected.
This update corrects a bug in the holiday calculation process. Previously, the system incorrectly used contract start dates instead of version dates when determining holiday eligibility, leading to unnecessary recalculations. This change ensures holiday calculations are accurate and efficient, especially when dealing with multiple contract versions.
Original PR description
Currently if we have 2 versions on the same contract dates, we check leaves from the contract_start_date, instead of the version date. Meaning if we only have versions on 1 contract date, we will recalculate ALL the leaves all the time. This should not be the case.
This update resolves an issue where pressing 'Enter' within the emoji suggestion picker in the discuss HTML composer would unexpectedly send a message. The fix prevents the 'Enter' key from triggering the message sending action, improving the user experience and preventing unintended message submissions.
Original PR description
In discuss html composer, when emoji suggestion list is open, pressing enter sends the message. This commit fixes this issue by preventing the default action of the enter key when the emoji suggestion list is open. task-6173045 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug in how the ESG module calculates emissions factors. The previous conversion logic was flawed, leading to inaccurate results when using different units. This fix ensures accurate calculations for carbon emissions reporting.
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#115575 Forward-Port-Of: odoo/enterprise#115246
This update fixes an issue where leave balance reports were incorrectly calculating employee leave accruals and allocations, particularly when leaves spanned multiple years or time zones. The fix ensures accurate reporting of taken and remaining leave balances by addressing timezone discrepancies and overlapping allocation periods.
Original PR description
__ISSUE__: - FIFO balance miscalculation for non-overlapping allocations. cumulative_allocated_days was partitioned globally by (employee, leave_type), but taken_per_allocation scoped leaves to each…
__ISSUE__:
- FIFO balance miscalculation for non-overlapping allocations. cumulative_allocated_days was partitioned globally by (employee, leave_type), but taken_per_allocation scoped leaves to each allocation's date range. This caused the FIFO formula to silently absorb leaves from one period into another's allocation capacity.
ex:
Alloc A (20 days) 2025, taken leaves 15 days
Alloc B (20 days) 2026, taken leaves 5 days
report: 2025: (15 taken), (5 left)
2026: (7 taken), (20 left)
- Left" rows shifted by one year in non-UTC timezones. Allocation date_from/date_to (Date fields) were cast to timestamp as midnight UTC. In negative-UTC /positive-UTC timezones midnight UTC of Dec 31 renders as the prev/next day.
__FIX__:
- detect overlap groups using a running MAX(date_to) and partition the cumulative sums within each overlap group. This way non-overlapping allocations are treated as independent, while overlapping or open-ended allocations still share FIFO within their group.
- offset allocation dates by 12 hours so no timezone can shift them across a day boundary.
- opw-5169606
- opw-5352114
Forward-Port-Of: odoo/odoo#257873This update resolves an issue where generating timesheets would produce errors when a public holiday overlapped with time off requested by an archived employee. The fix prevents timesheet generation from considering time off for employees who are no longer active, ensuring accurate reporting. This improves the reliability of our time tracking system.
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 corrects a technical issue where quotation templates linked to tasks were incorrectly assigning task IDs to non-product lines (like notes). This prevented proper task completion and could lead to errors. The change ensures that task IDs are only applied to product lines within a quotation template, improving system stability.
Original PR description
When a sales order is created from a task, if a template is used, the first line is given a task ID from the context's default_task_id. If this first line were to be a non-product line (section/note), this would still be given a task_id. This is unneeded and can cause issues such as a float precision error when trying to mark the task as done. This change checks to see if the line has a display_type, in which case it will set the task_id to false. Steps to reproduce: 1. Create a new Quotation Template with a single section line 2. Create a new project 3. Open the project settings 4. Enable 'Billable' and 'Extra Quotations' 5. Create a new task 6. Select 'New Quotation' 7. Select the quotation template with just a section 8. Enter customer (to allow saving) 9. There will be a single order line, a section, with a task_id opw-6122235 Forward-Port-Of: odoo/odoo#261298
This update resolves an error preventing users from accessing the Spain VAT Books report within the Enterprise application. The issue stemmed from an outdated reference in a report template. This fix ensures the report functionality is restored for Spanish companies, improving reporting accuracy and usability.
Original PR description
**Steps to reproduce:** - Install the `l10n_es_reports` and `accountant` modules. - Switch to an ES Company. - Navigate to Accounting > Reporting > Spain > `VAT Books`. **Error:** `Element '<xpath…
**Steps to reproduce:** - Install the `l10n_es_reports` and `accountant` modules. - Switch to an ES Company. - Navigate to Accounting > Reporting > Spain > `VAT Books`. **Error:** `Element '<xpath expr="//button[@t-if='this.props.line.chatter and !this.ui.isSmall']" position="replace"/>' cannot be located in element tree` **Root Cause:** After commit [1], the condition `this.ui.isSmall` was removed from the template `account_reports.AccountReportLineNameCustomizable` at [2]. However, the inherited template `l10n_es_reports.VatBooksLineName` was not updated accordingly and still references the old condition, which leads to the error. **Fix:** This commit prevents errors and ensures that users can open the `VAT Books` report by applying a fix similar to [2]. [1]: https://github.com/odoo-dev/enterprise/commit/fd0afa474600586e8703ec377f962c8d7d94307a [2]: https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/account_reports/static/src/components/account_report/line_name/line_name.xml#L81 opw-6169697 opw-6170173 Forward-Port-Of: odoo/enterprise#115412
This update optimizes the PDF generation process for Saudi Arabia (l10n_sa_edi_pos), which was previously a major bottleneck in checkout times. Because ZATCA only requires the XML and QR code, we've deferred PDF generation to a later stage, significantly speeding up the checkout experience for cashiers. This change improves overall performance and responsiveness.
Original PR description
For SA companies, wkhtmltopdf PDF generation was accounting for ~47% of the sync_from_ui response time (~3.1s out of ~6.5s total), blocking the cashier at every order. The PDF is not needed during checkout: ZATCA requires only the signed XML and returns the QR code. The PDF can be generated on demand when the invoice is first viewed or downloaded. opw-6019994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260757 Forward-Port-Of: odoo/odoo#253641