Daily updates from Odoo
Wednesday, May 27, 2026
48 changes · saas-19.1
Enhancements to existing features
This update enhances the logging and performance monitoring of our IoT device communication system. By adding detailed logs around key actions, we'll gain better visibility into how devices are interacting with the Odoo platform. This improves troubleshooting and helps ensure reliable performance for IoT integrations.
Original PR description
This PR adds logging and performance check for the longpolling controller Related PR for >= saas-18.3: https://github.com/odoo/odoo/pull/241467 Forward-Port-Of: odoo/odoo#242637 Forward-Port-Of: odoo/odoo#241469
Resolved issues and error corrections
This update resolves an error that occurred when creating bank accounts using the 'l10n_br' module. Specifically, a falsy value entered for the proxy type (CPF/CNPJ or Random Key) caused a validation error. This fix ensures the module functions correctly when creating bank accounts, preventing data entry issues.
Original PR description
Creating a bank account with a falsy proxy value generates a traceback. Steps to reproduce the error: - Install ``l10n_br`` module with demo data - Switch to BR Company - Go to Contacts >…
Creating a bank account with a falsy proxy value generates a traceback. Steps to reproduce the error: - Install ``l10n_br`` module with demo data - Switch to BR Company - Go to Contacts > Configuration > Bank Accounts > Create a new bank account > Add any value as Account Number > Account Holder: BR Company > Proxy Type: CPF/CNPJ(BR) or Random Key (BR) > Save Traceback: ```py InvalidFormat: The number has an invalid format. ``` ```py TypeError: 'bool' object is not iterable ``` https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L38-L45 For ``CPF/CNPJ`` validation, calling ``check_vat_br`` with a falsy proxy value raises a traceback. https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L56-L61 For ``Random Key`` validation, ``re.fullmatch`` expects a string value, but receives ``False``, leading to a traceback. sentry-7488238698 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266243 Forward-Port-Of: odoo/odoo#264995
This update corrects a bug in the stock account configuration process. Previously, new stock accounts were created with missing data, leading to incomplete records. This fix ensures updates only apply to existing accounts, guaranteeing accurate and fully populated stock account information.
Original PR description
In the post-init stock configuration we update the chart accounts to add stock-related fields using `_load_data`. The values provided by `_get_stock_account_account` only contain partial data meant…
In the post-init stock configuration we update the chart accounts to add stock-related fields using `_load_data`. The values provided by `_get_stock_account_account` only contain partial data meant to enrich accounts created by the chart template.
The update should only be performed on accounts that already exist. Otherwise, the load creates new account records with most fields left null (e.g. account_type), which is not the intention here.
This fix filters the updates to existing accounts only, so the step only enriches accounts created by the chart template and avoids creating incomplete account records.
steps to reproduce:
- Install account app in a odoo 19 db
- Delete account 'stock valuation'
- Install `stock_account` module
```py
File "/home/odoo/src/odoo/19.0/addons/stock_account/__init__.py", line 13, in _post_init_hook
_configure_stock_account_company_data(env)
File "/home/odoo/src/odoo/19.0/addons/stock_account/__init__.py", line 79, in _configure_stock_account_company_data
ChartTemplate._load_data({
File "/tmp/tmplqo7rmpu/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
return super()._load_data(data, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 697, in _load_data
created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5194, in _load_records
records = self._load_records_create([data['values'] for data in to_create])
# [...]
File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 433, in execute
self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "account_type" of relation "account_account" violates not-null constraint
DETAIL: Failing row contains (2315, null, 1, 1, null, null, null, t, f, f, 2026-02-17 05:53:58.84587, 2026-02-17 05:53:58.84587, no, f, null, null, null
```
opw-5913248
upg-3879881
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#249211This update resolves an error that occurred when users reviewed eMPF contribution reports. Specifically, the system was attempting to access employee information without it being properly set, leading to a system error. The fix ensures a user-friendly error message is displayed, prompting the user to correctly populate the employee details before reviewing the report.
Original PR description
Currently, an error occurs when the user checks the report line errors. **Steps to Reproduce:** - Install the `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. -…
Currently, an error occurs when the user checks the report line errors. **Steps to Reproduce:** - Install the `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` > `Reporting` > `Hong Kong` > `eMPF Contributions`. - Create a record by setting the `Scheme` and adding a `contribution line`. - Ensure that the employee and payslip fields are empty in the contribution line. - Click on `Validate`, then click on the `error icon` on the report line. `ValueError: Expected singleton: hr.version()` This error occurs when the user manually adds a line and checks the errors on it.. The system attempts to open the employee record from the version [1], but the version is not set [2] on the line because there is no employee. And it raise the error [3]. This commit ensures that when checking errors, if the version is not set on the line, a UserError is raised, prompting the user to set the employee on the line. It also corrects a typo in the status message. [1]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L219 [2]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L142-L156 [3]: https://github.com/odoo/odoo/blob/98855c6b70df24500babe6027109aa9e17431ec1/addons/hr/models/hr_version.py#L609-L611 Forward-Port-Of: odoo/enterprise#116607
This update fixes a bug that prevented accurate IT tax closing validation, particularly when dealing with quarterly VAT reporting in Italy. The changes ensure correct handling of year-end gaps and utilize debit/credit columns in reports, preventing errors and improving the reliability of tax calculations.
Original PR description
Description of the issue this commit addresses: The IT tax closing validation compared month numbers only, which broke across year boundaries and could reject valid quarterly progressions. It also assumed a balance column existed in monthly VAT report lines, but this report uses debit/credit columns, which could trigger a traceback. --- Desired behavior after this commit is merged: This commit computes the period gap with year-aware month deltas and aligns the allowed gap with periodicity (monthly or quarterly). It also checks VP lines using balance when present, or debit/credit as fallback, preventing crashes and ensuring consistent tax closing validation. --- opw-6131080 Forward-Port-Of: odoo/enterprise#117428
This update fixes a performance issue in the Stock Barcode module, specifically related to how the user interface is rendered. By simplifying the CSS rules, the system now recalculates styles faster, leading to quicker response times when navigating large reports or interacting with the application.
Original PR description
Avoid using `:has` selector with using a class on body to replace the has behavior. This change made a gain of in the `(re)calculate style` step when we hover a node on large table like a `report selector` on `Accounting`. The recalculation time during actions like window resize, heavy scrolling, or table sorting. Replacing it with using the specific class reduces those global checks and improves rendering performance. Forward-Port-Of: odoo/enterprise#118362
This update resolves an issue preventing the attendance system from correctly filtering employees based on their country code. The fix grants necessary access rights to read the country code, ensuring accurate attendance reporting and payroll calculations. This improves the reliability of the HR attendance module.
Original PR description
/hr_attendance:TestAttendanceManager.test_attendance_manager_rights uses write function defined in l10n_sa_hr_payroll_attendance which in some cases requires to read the country_code of an employee to filter. Access rights on employees blocked it from reading country_code. Added sudo on employee for reading and filtering on country_code. task-6226413
This update resolves an issue where account reconciliation lines remained incorrectly marked as reconciled after being deleted. The fix ensures that matching numbers are properly cleared from related account move lines, preventing misleading UI displays and maintaining data integrity. This improves the accuracy of financial reporting.
Original PR description
### Description `account.full.reconcile` has no `unlink()` override, so when the record is removed PostgreSQL nulls `full_reconcile_id` on the linked `account.move.line` rows via the default…
### Description
`account.full.reconcile` has no `unlink()` override, so when the record is removed PostgreSQL nulls `full_reconcile_id` on the linked `account.move.line` rows via the default `ondelete='set null'` FK rule, but `matching_number` is a plain `fields.Char` that nobody recomputes. The line ends up with a decimal `matching_number` (the id of the deleted full) while `full_reconcile_id` is `False`, no partials point to it and `amount_residual` is the full open amount. The line is rendered as reconciled in the UI even though the reconciliation is gone.
This PR mirrors `account.full.reconcile.create()`'s contract on the unlink path: invoke `_update_matching_number(amls)` after the records are removed, so every previously-linked line is cleaned. The integrity check `_constrains_matching_number` is also extended with `full_reconcile_id` in its `@api.constrains` tuple, so future ORM writes that desync the field surface the inconsistency immediately.
### Steps to reproduce
A single-call reproducer on a vanilla `19.0-all` runbot, no third-party modules:
```python
company = env.ref('base.main_company') # USD company
partner = env['res.partner'].create({'name': 'demo'})
# Foreign currency rates with a sharp move so the payment generates an FX diff
env['res.currency.rate'].create([
{'currency_id': env.ref('base.EUR').id, 'name': '2026-01-15', 'rate': 0.90, 'company_id': company.id},
{'currency_id': env.ref('base.EUR').id, 'name': '2026-03-15', 'rate': 1.20, 'company_id': company.id},
])
inv = env['account.move'].create({
'move_type': 'out_invoice', 'partner_id': partner.id,
'currency_id': env.ref('base.EUR').id,
'invoice_date': '2026-01-15', 'date': '2026-01-15',
'journal_id': env['account.journal'].search([('type','=','sale')], limit=1).id,
'invoice_line_ids': [(0,0,{'name':'x','quantity':1,'price_unit':1000.0})],
})
inv.action_post()
env['account.payment.register'].with_context(
active_model='account.move', active_ids=inv.ids
).create({'payment_date': '2026-03-15'}).action_create_payments()
recv = inv.line_ids.filtered(lambda l: l.display_type == 'payment_term')
full = recv.full_reconcile_id
assert full and recv.matching_number == str(full.id)
full.unlink() # the bug detonator
recv.invalidate_recordset()
assert recv.matching_number is False # FAILS without this PR
assert not recv.full_reconcile_id
```
Before the PR `recv.matching_number` keeps the decimal id of the deleted `account.full.reconcile`. After the PR it is cleared together with `full_reconcile_id`.
### Diagnostic query
```python
env['account.move.line'].search([
('matching_number', '!=', False),
('matching_number', 'not like', 'P%'),
('matching_number', 'not like', 'I%'),
('full_reconcile_id', '=', False),
])
```
Returns lines in the orphan state on any database.
### Impact
Observed on a real production database: 142 `account.move.line` records in this orphan state accumulated over ~13 days of normal accounting activity, on receivable, payable and bank accounts. All those lines display as reconciled in the UI while the underlying reconciliation is gone. Empty `account.full.reconcile` rows are also left behind.
### Tests
`addons/account/tests/test_account_move_reconcile.py::TestAccountMoveReconcile::test_full_reconcile_unlink_clears_matching_number`
### Linked
* Bug report: closes #264790
The change is a single-file 13-line `unlink()` override plus a one-character extension to an existing `@api.constrains` tuple. No data migration is needed for new databases; existing orphans on databases that hit the bug before the fix lands can be cleaned with a one-off:
```python
env['account.move.line'].search([
('matching_number', '!=', False),
('matching_number', 'not like', 'P%'),
('matching_number', 'not like', 'I%'),
('full_reconcile_id', '=', False),
]).write({'matching_number': False})
env['account.full.reconcile'].search([
('reconciled_line_ids', '=', False),
('partial_reconcile_ids', '=', False),
]).unlink()
```
Forward-Port-Of: odoo/odoo#264805This update ensures a more visually appealing and accessible HTML Builder by standardizing accent colors across buttons and text elements. Previously, the text colors lacked sufficient contrast, now they align with the button styles for better readability and a more polished design.
Original PR description
In the html builder, we use strong, neon colors especially for the `btn-success` and `btn-danger`. However, the tint for `text-succes` / `text-danger` was duller, with a bad contrast against the background. This commit simply uses the same color, within builder buttons, for the text classes accent colors as for the btn classes. Forward-Port-Of: odoo/odoo#262277
This update fixes a problem where preparation displays (PDIS) weren't correctly updated when transferring, merging, or modifying orders in the POS system. Previously, new PDIS were created instead of reusing existing ones, leading to inconsistencies between the POS and kitchen screens. Now, PDIS are synchronized across all table actions, ensuring accurate kitchen order information.
Original PR description
Task: [#5005179](https://www.odoo.com/odoo/1737/tasks/5005179) --- When executing table actions such as transfer, merge, link, or unlink, the related Preparation Displays (PDIS) were not being updated. This caused inconsistencies between the POS orders and the kitchen screens. Also, when merging or linking orders and cancelling some lines, a new `pdis_order` was created instead of reusing the existing one. This fix ensures that PDIS are correctly synchronized and notified on any table actions. Forward-Port-Of: odoo/odoo#236613 Forward-Port-Of: odoo/odoo#233630
This update fixes a bug where Preparation Displays (PDIS) weren't correctly updated during table actions like transferring or merging orders. Previously, new PDIS were created instead of reusing existing ones, leading to inconsistencies. Now, PDIS are synchronized across all table actions, ensuring accurate information on both the POS and kitchen screens.
Original PR description
Task: [#5005179](https://www.odoo.com/odoo/1737/tasks/5005179) --- When executing table actions such as transfer, merge, link, or unlink, the related Preparation Displays (PDIS) were not being updated. This caused inconsistencies between the POS orders and the kitchen screens. Also, when merging or linking orders and cancelling some lines, a new `pdis_order` was created instead of reusing the existing one. This fix ensures that PDIS are correctly synchronized and notified on any table actions. Forward-Port-Of: odoo/enterprise#99975 Forward-Port-Of: odoo/enterprise#98374
This update resolves a problem where kiosk transactions would unexpectedly disconnect, leading to lost sales. The update also improves the user experience by providing clearer error messages when issues occur during transactions. This ensures smoother operation for self-order kiosks.
Original PR description
This PR fixes the scneario when the terminal transaction times out during kiosk request. It also adapts the error messages shown to the user whenever an error occurs community: https://github.com/odoo/odoo/pull/249101 task-5946033 Forward-Port-Of: odoo/enterprise#107709
This change corrects a technical issue preventing Odoo from starting correctly. The problem stemmed from an outdated import statement within the Odoo core code, specifically related to the lxml library. This fix ensures Odoo can launch and function as expected.
Original PR description
still ``lxml.html.clean`` import is needed because ``lxml.html`` init file don't have clean file. So, it will be not loaded For reference :-…
still ``lxml.html.clean`` import is needed because ``lxml.html`` init file don't have clean file. So, it
will be not loaded
For reference :- https://github.com/lxml/lxml/blob/lxml-4.9/src/lxml/html/__init__.py
```
Traceback (most recent call last):
File "/tmp/tmpj23nirpw/odoo/19.0/./odoo-bin", line 3, in <module>
import odoo.cli
File "/tmp/tmpj23nirpw/odoo/19.0/odoo/cli/__init__.py", line 2, in <module>
from .command import Command, main # noqa: F401
File "/tmp/tmpj23nirpw/odoo/19.0/odoo/cli/command.py", line 8, in <module>
import odoo.init # import first for core setup
File "/tmp/tmpj23nirpw/odoo/19.0/odoo/init.py", line 28, in <module>
from .tools.gc import gc_set_timing
File "/tmp/tmpj23nirpw/odoo/19.0/odoo/tools/__init__.py", line 11, in <module>
from .i18n import format_list, py_to_js_locale
File "/tmp/tmpj23nirpw/odoo/19.0/odoo/tools/i18n.py", line 8, in <module>
from odoo.tools.misc import babel_locale_parse, get_lang
File "/tmp/tmpj23nirpw/odoo/19.0/odoo/tools/misc.py", line 40, in <module>
from lxml import etree, objectify
File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
File "/tmp/tmpj23nirpw/odoo/19.0/odoo/_monkeypatches/__init__.py", line 45, in exec_module
patch_module(module.__name__)
File "/tmp/tmpj23nirpw/odoo/19.0/odoo/_monkeypatches/__init__.py", line 67, in patch_module
module.patch_module()
File "/tmp/tmpj23nirpw/odoo/19.0/odoo/_monkeypatches/lxml.py", line 14, in patch_module
lxml.html.clean._find_image_dataurls = re.compile(r'data:image/(.+?);base64,').findall
AttributeError: module 'lxml.html' has no attribute 'clean'
```
https://upgradeci.odoo.com/upgradeci/run/301804
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#266591This update corrects a bug where refund actions were incorrectly triggering the cancellation of original invoices. The fix ensures that the automatic CFDI cancellation process only applies to legitimate invoice replacements, preventing unintended consequences for credit notes and other refund-related transactions. This improves the accuracy of financial reporting and reduces potential disruptions to business processes.
Original PR description
Issue: Implementation of automatic CFDI cancel flow of an invoice substituted by a new one accidentally resulted in sending credit notes created from an invoice also triggering cancellation of the original. Solution: adding a check to only apply to invoice replacements and not refunds. ticket-6245456 Forward-Port-Of: odoo/enterprise#118327
This pull request updates the core spreadsheet component within Odoo. It addresses several technical issues related to data handling, formulas, and pivot tables, ensuring improved accuracy and stability of the spreadsheet functionality. The update includes new features and improvements related to Claude skill integration.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/99ebe9376b [REL] 19.1.21 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/99ebe9376b [REL] 19.1.21 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/fde8ddb28f [FIX] formulas: add IFERROR second argument when exporting data [Task: 5993405](https://www.odoo.com/odoo/2328/tasks/5993405) https://github.com/odoo/o-spreadsheet/commit/7228270f55 [FIX] range: correctly handle unbounded ranges on row/col changes [Task: 6167358](https://www.odoo.com/odoo/2328/tasks/6167358) https://github.com/odoo/o-spreadsheet/commit/d21e9b0114 [FIX] pivot: unused pivot detection with composed formula [Task: 6105894](https://www.odoo.com/odoo/2328/tasks/6105894) https://github.com/odoo/o-spreadsheet/commit/5cf698ee4c [FIX] pivot: unused pivot detection with calculated measure [Task: 6105894](https://www.odoo.com/odoo/2328/tasks/6105894) https://github.com/odoo/o-spreadsheet/commit/f7f8485a4c [IMP] claude: add review skill [Task: 6223095](https://www.odoo.com/odoo/2328/tasks/6223095) https://github.com/odoo/o-spreadsheet/commit/d51b26de87 [IMP] claude: add testing skill [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/28c8803429 [IMP] claude: add CLAUDE.md file [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes a problem where backorders created during point-of-sale (POS) transactions weren't properly linked to the original order. Now, all backorder pickings are correctly associated with the POS order, improving inventory accuracy and reporting in the Point of Sale module. This ensures consistent tracking of sales and reduces potential discrepancies.
Original PR description
The delivery transfer for a product tracked by serial number is not linked to the POS order when there is no available stock. When validating a POS delivery in real time, stock can split the transfer…
The delivery transfer for a product tracked by serial number is not linked to the POS order when there is no available stock. When validating a POS delivery in real time, stock can split the transfer into a completed picking and a backorder (e.g. one line fully delivered with lots, another serial-tracked line with no stock and no serial number). Steps to reproduce: ------------------- * Setup two products: one tracked by qunatity with some quantity on-hand an other tracked by SN but no quantity on-hand * Open Pos * Sell in one order, both products without providing SN * Validate payment * Open Inventory: two deliveries sould exist under Inventory Overview of PoS Orders > Observation: The first picking shows the POS order as Source Document but the backorder has no source document and is not linked to the POS order. Why the fix: ------------ Pos Origin (Source Document, POS order, session) was only written on the pickings returned by `_create_picking_from_pos_order_lines`, which did not include pickings created during `_action_done()`. Extend the write to the initial pickings and their backorders so every transfer stays tied to the originating `pos.order`. opw-6090606 Forward-Port-Of: odoo/odoo#266111 Forward-Port-Of: odoo/odoo#259370
This update corrects a technical issue where records without SMTP authentication settings were causing errors and preventing proper data display. The fix ensures that all records have a valid SMTP authentication information, preventing errors and improving data reliability. This resolves a potential instability in the system.
Original PR description
Description of the issue/feature this PR addresses: The compute method for `smtp_authentication_info` did not properly handle cases where no `smtp_authentication` value was set. Current behavior before PR: * When `smtp_authentication` was empty or had an unsupported value, `smtp_authentication_info` was never assigned. * This caused the compute method to fail with: `ValueError: Compute method failed to assign ir.mail_server(...).smtp_authentication_info` * As a result, reading or displaying the record could raise an exception. Desired behavior after PR is merged: * The fallback branch explicitly resets `smtp_authentication_info`. * `smtp_authentication_info` is always assigned during computation. * Records without an authentication method no longer raise compute errors and are handled correctly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266411
This update ensures Knowledge articles always load correctly when printing, regardless of how the print action is initiated. Previously, inconsistent loading caused blank prints. To address this, the print assets are now consistently loaded, and CSS rules have been refined to prevent unintended styling impacts on other Odoo modules.
Original PR description
Previously, the file containing the Knowledge print assets was lazy-loaded when the user triggered a print action through the UI. However, printing can also be initiated through other mechanisms…
Previously, the file containing the Knowledge print assets was lazy-loaded when the user triggered a print action through the UI. However, printing can also be initiated through other mechanisms (keyboard shortcuts, contextual menu, etc.), which prevented us from consistently detecting when to load the assets. In those cases, the assets were not loaded and the article appeared blank (see: odoo/enterprise#70243). To ensure the assets are always loaded regardless of how printing is triggered, we moved them to the common print bundle and adopted the standard asset-loading approach. This change also simplifies the codebase by removing JavaScript workarounds previously used to load the assets dynamically. However, some CSS rules in the Knowledge print stylesheet target global elements such as the web client container. Since the stylesheet is now included in a global asset bundle and always loaded, these rules apply to all modules and may cause rendering issues when printing views outside of Knowledge. To prevent such side effects, the CSS rules in `knowledge_print.scss` will be updated to use more specific selectors. The rules will be scoped so they only apply when the container includes the Knowledge view (using the `:has`). This PR also refactors the stylesheet by removing outdated rules that no longer match any elements. Several of these rules predate the major UI refactoring introduced in Odoo 16. Task-5999878 Forward-Port-Of: odoo/enterprise#109379
This update corrects a restriction in the Recruitment app where Interviewer users could view talent pools but lacked the ability to manage applicants within them. The fix ensures Interviewers only see applications they are directly assigned to, aligning with the intended workflow and preventing unnecessary access. This resolves a usability issue.
Original PR description
## Issue In the Recruitment app, users with the *Interviewer* role have access to the Talent Pool action menu, can see the different talent pools, but don't have any read/write access to the…
## Issue
In the Recruitment app, users with the *Interviewer* role have access to the Talent Pool action menu, can see the different talent pools, but don't have any read/write access to the applicants within the pools, and cannot create new pools either.
## Steps to reproduce
1. Install *Recruitment* (`hr_recruitment`) with demo data
2. Set Marc Demo's *Recruitment* role to *Interviewer*
3. As Marc Demo, navigate to Recruitment > Applications > By Talent Pools
4. **We can see the existing pools, but they all appear empty ("0 Talents"), and we cannot add talents to a pool, nor create new pools.**
## Cause
Interviewer do not see any applicants in the talent pools because of the following rule:
https://github.com/odoo/odoo/blob/e751fa1e010dbda63903d598048ef415709b4af4/addons/hr_recruitment/security/hr_recruitment_security.xml#L48-L60
In fact, applicants in talent pools do not have a job_id set:
```sql
190=# SELECT a.partner_name, a.job_id FROM hr_applicant a
190-# JOIN hr_applicant_hr_talent_pool_rel tpr
190-# ON (tpr.hr_applicant_id=a.id);
partner_name | job_id
---------------+--------
Cameron Ellis |
Ethan Carter |
Noah Bennett |
Test Talent |
(4 rows)
```
This leads to no applicants being shown to the interviewers in the talent pools.
## Justification
Interviewers by default only have access to applications who they are interviewer for, it is not intended for them to see entire pools of potential candidates. Letting interviewers access the talent pools view is counter-intuitive, as they have nothing they can do from there.
opw-6187187
Forward-Port-Of: odoo/odoo#265812This update enables payment providers to be duplicated when a branch company is created, aligning with how journals are currently handled in branches. This change simplifies setup and ensures consistency across our business operations.
Original PR description
This PR will allow payment providers to be duplicated into branch companies when a branch company is created. Previously this was prevented because in accounting it's preferred not to use journals in branches. However, there it is still possible to setup a journal in branches. So it makes sense to allow it also in payment providers. opw-6013978 Forward-Port-Of: odoo/odoo#265831
This change optimizes the process of exporting large datasets in Odoo reports. Previously, the system used a method that consumed excessive memory, leading to potential errors with large exports. The update batches export calls, reducing memory usage and improving export speeds.
Original PR description
When exporting a number N of records as XLSX or CSV file, we call the export_data() method for the N records at the same time. This method prefetches the selected fields for all the records which can lead to memory limit errors when N is too large. We propose to batch this call and invalidate the recordsets between batches. Benchmarks ----------- Execution time: | No records | Before PR | After PR | |------------|-----------|----------| | 70 260 | 3.82 s | 3.94 s | | 228 116 | 18.71 s | 19.36 s | | 394 381 | 31.02 s | 32.67 s | Memory usage: | No records | Before PR | After PR | |------------|-----------|----------| | 70 260 | 316.0 MB | 273.5 MB | | 228 116 | 796.9 MB | 620.8 MB | | 394 381 | 1.3 GB | 947.7 MB | opw-5881026 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266078 Forward-Port-Of: odoo/odoo#257333
This update fixes a revenue calculation issue in the project dashboard. Previously, weekly subscription revenue wasn't being accurately reflected. This change ensures that all subscription types – including weekly – are correctly accounted for when generating revenue reports and invoices.
Original PR description
…plan Before this commit, the #113918 corrects the project dashboard revenue when a yearly subscription is linked to that project. The problem is the fix does not take into account the weekly subscription. This commit handles the subscriptions with plan unit set to week and linked to the project to correclty set the right revenue in to invoice column. opw-5916688 Forward-Port-Of: odoo/enterprise#118163
This update fixes an issue where the Point of Sale tour experience wouldn't reliably work with infinite scrolling. By searching for the customer before a click, the tour now functions correctly, ensuring a smoother and more consistent user experience. This resolves a minor usability problem.
Original PR description
Make clickPartner search for the partner first to handle infinite scroll. Fixes: - test_preset_customer_selection - test_not_create_loyalty_card_expired_program - test_not_create_loyalty_card_max_usage_programm task-id: 5897380 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247050 Forward-Port-Of: odoo/odoo#246784
This update fixes an issue where invoices imported from UBL files were incorrectly calculating prices due to a missing discount application. The change ensures that discounts from AllowanceCharges are accurately added to the PriceAmount, resulting in correct invoice pricing. This resolves a problem where invoices displayed the wrong total amount.
Original PR description
**PROBLEM** When importing a ubl bis3 file, with only the amount in the AllowanceCharge on PriceAmount it doesn't add the discount to PriceAmount to get the undiscounted price. Which means we create an invoice with the wrong price. This PR fixes that. opw-6102962 Forward-Port-Of: odoo/odoo#258964
Avoid using the attribute substring selector (`*=`), which forces a broad match and can be slower than class selectors. Target the correct node directly using the `o-we-hint` class instead. On very large pages (thousands of DOM elements like account_report) `*=` can increase style recalculation time during actions like window resize, heavy scrolling, or table sorting. Replacing it with using the specific class reduces those global checks and improves rendering performance. --- I confirm
Original PR description
Avoid using the attribute substring selector (`*=`), which forces a broad match and can be slower than class selectors. Target the correct node directly using the `o-we-hint` class instead. On very large pages (thousands of DOM elements like account_report) `*=` can increase style recalculation time during actions like window resize, heavy scrolling, or table sorting. Replacing it with using the specific class reduces those global checks and improves rendering performance. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266381
This fix resolves an issue where confirming a sales order would only create one lead, even when multiple event registrations were involved. The update now correctly creates multiple leads when multiple event registrations are associated with a single order, ensuring accurate lead tracking for event sales. This improves the reliability of lead generation from sales orders.
Original PR description
# How to reproduce - Install the Events, Porject & CRM apps - Create two event A & B with tickets that can be purchased - Go to Events > Configuration > Lead Generation - Create a Lead Generation…
# How to reproduce - Install the Events, Porject & CRM apps - Create two event A & B with tickets that can be purchased - Go to Events > Configuration > Lead Generation - Create a Lead Generation Rule with : - Create : Per Order - When : Attendees are created - Event : None - Create a new quotation with two lines : - Product : Even Registration for event A 1st, then B - Confirm the SO # The problem A traceback will appear # Cause of the issue When confirming the SO, we create `event.registrations`s that will check for lead generation rules and create or update `crm.lead`s accordingly : https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_registration.py#L35 We will then group the registrations by leads & grouping model : https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_lead_rule.py#L166 For all groups, if the lead does not exist, we create one : https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_lead_rule.py#L184-L187 `_get_lead_values()` works fine with multiple `event.registrations`s, but crashes when those registrations does not have all the same event, which is our case : https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_registration.py#L170 # Proposed solution Since we have multiple events and leads are associated to a single event : https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/crm_lead.py#L11 We group the registrations by event and create multiple leads accordingly opw-6167518 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265017
This update fixes a minor technical issue in the GSTR2B report generation. The report now correctly identifies non-GST supplies, ensuring accurate reporting for tax purposes in India. This change improves the reliability of the report data.
Original PR description
Before this commit, the domain of the non-GST supplies report line in GSTR2B used the GSTR section `purchase_nongst`, while the actual section key is `purchase_non_gst_supplies`. This commit fixes the domain by using the correct GSTR section key. task-6239820 Forward-Port-Of: odoo/enterprise#118313
This update resolves a memory issue that could cause invoice imports to fail with large product catalogs. The fix uses a more efficient batch processing method to reduce unnecessary calculations and memory usage, resulting in improved stability and performance.
Original PR description
Before this commit, for DBs with a very large number of products it was possible for the thread to run out of memory when importing an invoice or a bill. The reason is that the name on…
Before this commit, for DBs with a very large number of products it was possible for the thread to run out of memory when importing an invoice or a bill. The reason is that the name on product.product is non stored and computed. This leads to tons of recomputes, which in turn leads to reads and stores in cache of the underlying `product.product`, which down the line uses up all of the available memory for the thread. The proposed method uses batches instead of a `search_fetch` as the latter would not solve the recompute problem and hence the underlying memory problem. Another alternative approach could be going straight for the `product.template.name`, but that approach might introduce a loss of precision or functionality when searching for products at invoice import. Here is the memory graph from memray before the fix: <img width="1106" height="450" alt="opw-6168737-memray-pre-fix" src="https://github.com/user-attachments/assets/f971dc4d-aa09-41e3-a8c5-e5ca53f9786d" /> And here is the same graph after the fix: <img width="1106" height="450" alt="opw-6168737-memray-post-fix" src="https://github.com/user-attachments/assets/0a784cdc-9b40-498b-bbcb-89114eec1ec9" /> We can see a much lower peak memory usage after the fix. We an also observe that the memory complexity shifts from `O(n)` to `O(1)`, with `n` being the number of `product.product` records stored in the DB. For both presented graphs, the same, unaltered database was tested. The database contains 389 467 `product.product` records. opw-6168737 Forward-Port-Of: odoo/odoo#265639 Forward-Port-Of: odoo/odoo#262591
This update ensures that payments received from providers are always fully reconciled, either as a complete payment or not at all. Previously, partial reconciliations were allowed, which created inconsistencies in our accounting records. This change improves the accuracy and reliability of our financial reporting.
Original PR description
When we receive a payment from a provider, we allow partial reconciliations to be done on this move, but we shouldn't. Payments coming from providers are always either fully paid, or not paid at all. task-5893189 Forward-Port-Of: odoo/odoo#254597
This update fixes a visual issue where Selection fields in dark mode sign templates appeared unreadable due to white-on-white text. The fix ensures that dropdown options and selected values are clearly visible across dark mode, enhancing usability for all users. It achieves this by consistently applying a light color scheme within the sign template's PDF rendering.
Original PR description
**Problem:** When the user has dark mode enabled and a sign template contains a Selection field, both the displayed value and the dropdown option list are unreadable: the selected value renders…
**Problem:** When the user has dark mode enabled and a sign template contains a Selection field, both the displayed value and the dropdown option list are unreadable: the selected value renders white-on-white in the field, and clicking the dropdown shows an empty-looking popup (white options on white system menu). **Steps to reproduce:** 1. Enable dark mode in user preferences 2. Open Sign > Templates > duplicate any template 3. Add a Selection field with a few options (e.g. Low / Medium / High) 4. Save and Sign Now 5. Reach the Selection field and click it 6. Observe: the dropdown options are invisible (white on white) and, after picking one, the selected value in the field is also invisible **Cause of the issue:** The Selection sign item is rendered with a native `<select>` element inside the PDF.js iframe (`sign_items.xml`, `t-if="type == 'selection'"` branch). The iframe's stylesheet (`sign/static/src/css/iframe.css`) declares the `select` rule with `background: transparent` but no explicit `color`, and never styles `<option>` at all. When the OS or the user activates dark mode, the iframe document resolves to a `color-scheme: light dark` root, so the browser's UA stylesheet paints form controls with the dark palette (white text). The popup background stays white (`<option>` has no explicit background), so options render white-on-white. The same UA-white propagates to the displayed value of the `<select>` inside the pink-tinted sign item, which is also nearly white. **Fix:** Pinning the `<select>` text color and the `<option>` color/background to fixed light-mode values restores predictable contrast inside the iframe regardless of the surrounding color scheme. We deliberately do not rely on `color-scheme: dark` here — that would only swap which side of the contrast issue we land on (browsers don't reliably honor it for `<option>` background painting), and the sign item background (the pink dashed default style) is itself light, so dark option text on a white popup is the readable target in all themes. opw-6197638
This update corrects a bug where invoice PDFs were incorrectly displaying a 'Proforma' header instead of the standard invoice header. The fix ensures that invoices are initially generated with the correct 'Proforma' header until they are sent to the customer, resolving a potential confusion for users and improving invoice accuracy.
Original PR description
***Steps to reproduce*:** - Create and confirm an invoice. - Open the invoice preview and use the Print option to generate the PDF. - Send the invoice to the customer. ***Observed behavior*:** - In…
***Steps to reproduce*:** - Create and confirm an invoice. - Open the invoice preview and use the Print option to generate the PDF. - Send the invoice to the customer. ***Observed behavior*:** - In the preview, the header is displayed as *Proforma*. - Before sending the invoice, the downloaded PDF from the Print option does not contain the *Proforma* header. - After sending the invoice, the preview correctly no longer shows the *Proforma* header, but the Print PDF output also continues without the expected behavior. ***Cause*:** - The *Proforma* header should be displayed when a confirmed invoice has not yet been sent to the customer. - Once the invoice is sent, the document should display the normal invoice header instead. - The PDF generation flow from `action_print_pdf` did not correctly pass the proforma context based on whether the invoice had already been sent. ***Fix*:** - Update the functional logic in `action_print_pdf` to use: `with_context(proforma_invoice=not self.invoice_pdf_report_id)` - This ensures that invoices not yet sent to the customer are generated as *Proforma* invoices. - Once the invoice has been sent, the PDF is generated with the normal invoice header instead. opw-6169132 Forward-Port-Of: odoo/odoo#265825
This update resolves an issue where invoices with excessively long item descriptions were being rejected by the Kenyan Revenue Authority (KRA) eTIMS system. The fix ensures invoice descriptions are trimmed to the 200-character limit required by eTIMS, preventing submission errors and guaranteeing accurate tax reporting. This improves compliance and avoids potential delays.
Original PR description
The eTIMs specification limit the `itemNm` to 200 characters, so truncate the invoice line description to that limit to ensure that the invoice can be correctly submitted eTIMS server. Otherwise it will be rejected with: ``` Error sending to the KRA: - Request parameter error[<ItemList><itemNm>: length must be between 0 and 200] ``` Task-Id: 5220129 Forward-Port-Of: odoo/enterprise#118152
This fix ensures that account moves generated during inventory valuation use the correct company – the main branch company – instead of the parent company. This resolves an access error when navigating to the inventory valuation view, ensuring accurate financial reporting. The change updates how the company ID is determined during account move creation.
Original PR description
**Steps to reproduce:** - create a new company A - in the branch tab, create a new branch A for this company - create a warehouse for the company A and a warehouse for the branch A - from the company…
**Steps to reproduce:** - create a new company A - in the branch tab, create a new branch A for this company - create a warehouse for the company A and a warehouse for the branch A - from the company A, in settings for the 'fiscal localization' set Package : Generic Chart of account, if not already set (to have account journals). From the branch A: - create a storable product with standard perpetual category - set a cost of 10 - confirm a PO for 10 and validate delivery - navigate to 'inventory valuation' Make sure the branch A is the main company, but both branch A and company A are selected: - click on generate entry - click on the 'Other Info' tab **Current behavior:** The company of the account move is the parent company (Company A) **Expected behavior:** It should be the branch A. (As it is the case if only branch A is selected when clicking on "Generate entry") IAs a consequence, f you click on 'Inventory Valuation' on the top left to go back to the view, you will have an access error. **Cause of the issue:** When computing the company_id on the account move, move.journal_id.company_id will be the parent company because the journal_id of the branch is the one of the parent company (by default). So we will call _accessible_branches() on the parent company. https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/addons/account/models/account_move.py#L878-L881 Inside __accessible_branches(), 'accessible' will be based on self.env.companies https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/addons/base/models/res_company.py#L430-L439 (which is based on 'allowed_company_ids' in the context. https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/orm/environments.py#L266) So the return value of __accessible_branches() will be a list with 2 ids, the one of the parent company and the one of the branch. And we will use the first element of this list, which will be the parent company_id, in _compute_company_id to set the company of the account move. **fix:** When fetching the data for the inventory valuation view, only the data from the main company selected matters, https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/report/stock_valuation_report.py#L13 Therefore, when creating the account move the company of the move should be the main company. We already did something very similar in this PR https://github.com/odoo/odoo/pull/262776 where we modified the context in action_close_stock_valuation() before calling _action_close_stock_valuation() https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/stock_account/models/res_company.py#L56 opw-6144294 Forward-Port-Of: odoo/odoo#263828
This update fixes an issue where CFDI (Mexican electronic invoice) documents were being generated with incorrect length limits for key data fields like 'Folio' and 'Serie'. Swapping these values ensures the documents comply with Mexican regulations and prevents errors. This change does not impact existing valid invoices.
Original PR description
Issue: length limits for attributes `Folio` and `Serie` of the `<cfdi:Comprobante>` elements were swapped, which could result in generation of invalid documents. Solution: swapping the values. This should not affect anything for existing valid documents. task-6046738 Forward-Port-Of: odoo/enterprise#118105 Forward-Port-Of: odoo/enterprise#116955
This update enhances the way Odoo checks apps submitted to the Odoo Apps Store. Specifically, it now validates that key information like price and currency is included in the app's manifest, ensuring greater accuracy and reliability for developers. This improves the overall quality and trustworthiness of apps available on the Odoo Apps Store.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257047 Forward-Port-Of: odoo/odoo#255857
This update fixes an issue where the product gallery on mobile devices would reset to the first items after scrolling or changing screen size. The fix reintroduces a mechanism to only trigger gallery updates when the screen size changes, preventing unnecessary refreshes and ensuring a smoother user experience. This improves the visual consistency of the product catalog across different devices.
Original PR description
Scenario: - drop product catalog snippet and save - go to the second page of product - on some mobile scroll, or just change window size Result: we are reset to the first items of the gallery. Cause: in some mobile (eg. iOS safari) scrolling up or down make the address bar appear, that makes the viewport size change. Since 18.4 refactor of website, we rerender dynamic widget at any size change, so scrolling rerender the snippet. Fix: reintroduce saas-18.2 listenSizeChange that only trigger throttled change of media breakpoint and was removed from dynamic_snippet.js in 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2. opw-6137005 Forward-Port-Of: odoo/odoo#260623
This update resolves an issue where the withholding tax base amount on invoices could exceed the total invoice amount due to rounding discrepancies. The fix limits the withholding base amount to prevent over-calculation, ensuring accurate invoice totals and compliance. This improves financial reporting accuracy.
Original PR description
**PROBLEM** In some case, because of rounding issues, the withholding base amount can be bigger than the total amount of the invoice, which should not be the case. **STEP TO REPRODUCE** 1. Install…
**PROBLEM** In some case, because of rounding issues, the withholding base amount can be bigger than the total amount of the invoice, which should not be the case. **STEP TO REPRODUCE** 1. Install l10n_pe_edi 2. Create an invoice with those 2 lines: qty: 300, unit_price: 0.481936, tax: VAT 18% + 3% IGV Withholding qty: 300, unit_price: 0.747376, tax: VAT 18% + 3% IGV Withholding 3. Confirm the invoice, and send the xml (if this fail, you may have to change the name of the invoice, using odoo inspector or other means). 4. Open the xml, and notice the base amount for the allowance on the document level is 435.18 which is bigger than the invoice payable amount. **CAUSE** We exclude the withholding taxes to compute the invoice taxInclusiveAmount. When computing this amount, we round the line base and the tax total of the VAT 18% tax leading to the result of 435.17. When creating the allowance node for the Withholding taxes, the base used for the withholding taxes is the sum of the line base, and the tax total of previous tax NOT rounded. There is no easy way to change the withholding tax computation, so we just limit the base to not be bigger than the invoice total when there is rounding issues. opw-6010388 Forward-Port-Of: odoo/enterprise#113689
This update resolves a potential issue that caused Out of Memory errors during the installation of the `sale_subscription` module on databases with many sales orders. The fix ensures that newly added fields are correctly initialized to 'null' during installation, preventing performance bottlenecks and improving the installation process.
Original PR description
### Description: Installing `sale_subscription` on databases with a large number of `sale.order` and `sale.order.line` can cause Out of Memory (OOM) errors. The issue comes from two stored compute fields, `last_invoiced_date` and `plan_id`. Since these depend on newly added fields, they should default to `null` during installation. ### Reference: opw-6201267 Forward-Port-Of: odoo/enterprise#118203 Forward-Port-Of: odoo/enterprise#118008
This update fixes an issue where adding serial numbers to a stock move with a zero quantity could lead to incorrect quantity counts. The change ensures that only the intended serial numbers are added, preventing discrepancies between the number of serial numbers and the move's quantity. This improves data accuracy in our inventory management.
Original PR description
**Problem**: When we set the quantity of a move to zero, then add serial numbers manually, if the serial numbers are not the first ones in the list of available serial numbers, The first few…
**Problem**: When we set the quantity of a move to zero, then add serial numbers manually, if the serial numbers are not the first ones in the list of available serial numbers, The first few available serial numbers will be added to the move, which causes a mismatch of quantity and the number of serial numbers. **Before this commit:** If we have three serial number SN-001, SN-002, SN-003 created in order, and we set the quantity of the move to zero, then add SN-002 and SN-003 manually, SN-001 will be added automatically while saving. **After this commit:** Only SN-002 and SN-003 will be added to the move, which matches the quantity. **Steps to reproduce:** 1. Create a product with tracking by unique serial number, and create 3 lots SN-001, SN-002, SN-003 for this product. 2. Create a picking and add a move for this product, set the demand to 3 and quantity to 0. 3. Set the quantity to 2, and add SN-002 and SN-003 to the move, then save the picking. 4. SN-001 will be added to the move automatically, but the quantity stays at 2. opw-6121208 Forward-Port-Of: odoo/odoo#266259 Forward-Port-Of: odoo/odoo#263080
This update resolves an issue where payments weren't automatically linked to invoices when an invoice was created before the payment fully processed. This ensures accurate reconciliation of payments and invoices, preventing potential accounting discrepancies. The fix guarantees that all payments are correctly associated with their corresponding invoices.
Original PR description
Steps to reproduce: - Ensure Automatic Invoice setting is on - Create sales order for product with ordered quantites invoicing policy - Generate a Payment Link - Pay with the ACH Direct Debit method via a provider (e.g. Stripe) - While the payment is processing, confirm the sales order, create an invoice, confirm the invoice Current Behavior: When the payment is finished processing, the payment is not automatically linked to the corresponding invoice Expected Behavior: When the payment is finished processing, the payment should be linked to the invoice despite it being created by a user Explanation: The payment transaction's link to invoice_id is severed in PaymentTransaction._invoice_sale_orders if an invoice is created before the payment is cleared. This will eventually lead to the account.payment created automatically later on not being reconciled with the invoice. opw-6087656 Forward-Port-Of: odoo/odoo#264800
This update resolves a bug where resetting payroll work entries caused them to disappear due to mismatched time zone calculations. The fix ensures work entries are correctly localized using the user's time zone, preventing data loss and improving payroll accuracy. This impacts the way employees' work hours are recorded and processed.
Original PR description
Setup: Set the work entry source to attendance for an employee with active contract and change his timezone so that it differs from the working schedule one. Reset previous/next day delete Work Entry (payroll) - Step to reproduce: after an attendance was created, go to "Work Entries" in payroll, select the previous/next day and hit "Reset Selected Work Entries". The Work Entry will disappear. - Cause: reset window computed with calendar tz and work entry computed with user tz - Solution: localize work entries using calendar or user tz - Test: testing positive ans negative tz in hr_work_entry_attendance (enterprise) Task: 6072325 Forward-Port-Of: odoo/odoo#257309
This update resolves a bug where the 'Reset Selected Work Entries' function in the payroll module was unexpectedly deleting work entries due to incorrect time zone handling. The fix ensures accurate work entry management by using the correct calendar time zone, preventing data loss and improving payroll accuracy.
Original PR description
Setup: Set the work entry source to attendance for an employee with active contract and change his timezone so that it differs from the working schedule one. Reset previous/next day delete Work Entry (payroll) - Step to reproduce: after an attendance was created, go to "Work Entries" in payroll, select the previous/next day and hit "Reset Selected Work Entries". The Work Entry will disappear. - Cause: domain to nullify using wrong tz - Solution: adjust domain to use calendar tz - Test: testing positive ans negative tz in hr_work_entry_attendance (enterprise) Task: 6072325 Forward-Port-Of: odoo/enterprise#114148
This update resolves a printing problem reported by a client who was unable to print without LNA. The fix addresses a missing check that was causing the issue, ensuring consistent printing functionality. This improves the reliability of the POS system for all users.
Original PR description
Based on the ticket below the client is experiencing an issue when printing without LNA. This PR fixes the missing key check opw-https://www.odoo.com/odoo/project/49/tasks/6232008 Forward-Port-Of: odoo/enterprise#118005
This update fixes a bug where the 'Outgoing Mail Server' option was incorrectly displayed in user preferences when the default external email server was set to 'False'. The change ensures the system correctly interprets this setting as a boolean, preventing the option from appearing unnecessarily. This improves user experience and avoids potential confusion.
Original PR description
**Steps to reproduce:**
- Go to Settings > System parameters
- Set the `base_setup.default_external_email_server` to `False`
- Go to any User > Preferences tab
- `Outgoing Mail Server` option is visible
- The choice dropdown is available if the Gmail/Outlook settings are set
**Issue:**
`has_external_mail_server` is a Boolean field computed from the `base_setup.default_external_email_server` system parameter.
After [1] it is parsed as a string with `get_str`, which means that the conversion from string to boolean will return `True` when the value is set and not null.
```py
bool('False') -> True
```
(It also seems that on saas this value is set by default)
**Fix:**
Properly parse it as a boolean using `get_bool`.
[1] https://github.com/odoo/odoo/commit/3482ba72c8cd461d5c6609f4953decc1d5a55dd8
opw-6229696This update corrects a bug where the Email Alias helper wasn't visible in Helpdesk teams when the default external email server was disabled. The issue stemmed from a misinterpretation of the system parameter, which was incorrectly treated as a boolean value. This fix ensures the system accurately reflects the server status, resolving the visibility problem.
Original PR description
**Steps to reproduce:**
- Go to Settings > System parameters
- Set the `base_setup.default_external_email_server` to `False`
- Install Helpdesk app
- Go to any Helpdesk Team
- Email alias helper is not visible
**Issue:**
`has_external_mail_server` is a Boolean field computed from the `base_setup.default_external_email_server` system parameter.
After [1] it is parsed as a string with `get_str`, which means that the conversion from string to boolean will return `True` when the value is set and not null.
```py
bool('False') -> True
```
(It also seems that on saas this value is set by default)
**Fix:**
Properly parse it as a boolean using `get_bool`.
[1] https://github.com/odoo/enterprise/commit/c710031215c76a9e7ddb694d2a2787c8cca40dcd
opw-6229696This update resolves an issue where setting Intrastat fields on product templates without associated products would trigger an error. The fix ensures that Intrastat data is correctly handled, preventing disruptions when creating new product templates. This improves data accuracy and stability.
Original PR description
Problem: The Intrastat fields on product.template are computed without being stored. They are stored in product.product and the same values are used when computing the values on product.template. When trying to set the Intrastat fields on a product template without any product, an RPC error is raised without specifying the reason. Steps to reproduce: 1. Create a new product (product.template) 2. Add an attribute to the product with Variant Creation set to Dynamic, this will set no product variants (product.product) for the product template. 3. Try to set the Intrastat Commodity Code on the product template 4. Save the product template 5. Notice the RPC error raised without any explanation opw-6179705 Forward-Port-Of: odoo/enterprise#117856
This update corrects a recent change that unintentionally removed a styling class from all dynamic website snippets. The previous fix, intended to prevent layout issues with small containers, was too broad. This commit restores the correct styling for all dynamic snippets, ensuring consistent website appearance.
Original PR description
Before [1], the `s_dynamic_snippet_row` class was added to all dynamic snippets using the `website.s_dynamic_snippet.grid` template and defining `columnClasses` values. In [1], a fix was introduced to prevent adding this class on mono-record snippets, as it was breaking the layout when used inside small containers (`o_container_small`). However, the condition introduced by that fix is too broad and currently removes the class from all dynamic snippets. This commit fixes the condition so that `s_dynamic_snippet_row` is only excluded from mono-record snippets, restoring the intended layout for other dynamic snippets. [1]: https://github.com/odoo/odoo/commit/fe2279f760adc6a53ba2242961f3873a5d3215dd Forward-Port-Of: odoo/odoo#264407
This update resolves a problem in a test environment where a key feature (the Tax Returns button) was hidden. The fix ensures the button is always visible during testing, regardless of other system configurations, preventing test failures. This improves the reliability of our testing process.
Original PR description
The tour clicks a Tax Returns button rendered on the tax-return journal's kanban card on the accounting dashboard. That button only appears when show_on_dashboard is True on the journal, which is flipped by an inverse defined in the accountant module. Since account_reports does not depend on accountant, running this test on a database without accountant installed (e.g. account_reports only) leaves the journal hidden and the tour times out on the first step. To fix this we force the journal to be shown in this test rather than relying on accountant. runbot-error-242120