Wednesday, May 27, 2026
47 changes · saas-19.1
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