Wednesday, May 27, 2026
34 changes · saas-19.2
Enhancements to existing features
This update simplifies the handling of Swedish blackboxes, ensuring compatibility with both the new Skattedosan and older CleanCash models. By supporting both protocols at different baud rates, the system now seamlessly integrates with all Swedish blackbox devices, improving data collection reliability.
Original PR description
In odoo/odoo#260587, support was added for the modern Skattedosan brand Swedish blackboxes, using their own unique protocol. However, it turns out they also support the previous CleanCash protocol, just at a higher baud rate of 57600. This commit simplifies the SE blackbox driver by only supporting one protocol, but attempting to use it at both 9600 and 57600 baud. This results in both blackbox types being compatible. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows the IoT box to broadcast its IP address via Bluetooth for 5 minutes after startup. This feature provides support and clients with a quick way to identify and troubleshoot network connectivity issues with the IoT box. It ensures easier diagnostics for technical support teams.
Original PR description
This PR allows the iot box to advertise its ip address over Bluetooth for 5 minutes after boot. The format is `IoT Box [S/N] - [ip]` If no network is available it would advertise "No network connection" instead of the ip This can help clients and support to troubleshoot IoT Box issues. Forward-Port-Of: odoo/odoo#265738
Resolved issues and error corrections
This update replaces instances of 'VAT' with 'Tax ID' across key Odoo modules. This change ensures greater clarity and understanding for users worldwide, particularly in regions where 'VAT' is not commonly used, leading to more accurate reporting and data management.
Original PR description
Similar changes were made before but were incomplete [1]. In the US and many other countries the term VAT is not understood. Use the universally understood Tax ID instead. [1] https://github.com/odoo/odoo/pull/239362 task-6231891
This update replaces the term 'VAT' with 'Tax ID' across Odoo Enterprise, ensuring clarity and accuracy for users worldwide. This change addresses a previous incomplete effort to align with international tax reporting standards, particularly in the US where 'VAT' is not commonly understood. It improves the user experience and data integrity for international clients.
Original PR description
Similar changes were made before but were incomplete [1]. In the US and many other countries the term VAT is not understood. Use the universally understood Tax ID instead. [1] https://github.com/odoo/odoo/pull/239362 task-6231891
This update resolves a problem preventing the correct loading of icon assets (like .woff2 files). The fix ensures consistent handling of asset versions, preventing errors and improving the display of icons on the website. This improves the user experience by ensuring all icons are correctly rendered.
Original PR description
Currently, an exception is raised while loading icon content assets such as `.woff` or `.woff2`, due to a mismatch between the requested asset version and the latest available version. Steps to…
Currently, an exception is raised while loading icon content assets such as `.woff` or `.woff2`, due to a mismatch between the requested asset version and the latest available version. Steps to produce: - Install website - Open page `/web/assets/1/6a783c3/web.odoo_ui_icons.min.woff2` Error: `UnboundLocalError: cannot access local variable 'assets' where it is not associated with a value` This issue occurs because the code at [1] compares `binary.extension` with `asset_type`, causing the condition to fail because `binary.extension` contains values such as `woff` or `woff2`, while `asset_type` is set to `'binary'`. The root cause is that `asset_type` with value `'binary'` is being passed as a parameter to the `bundle.get_link` method (see [2]). The `asset_type` value comes from the `_parse_bundle_name` method (see [3]), where it is set to `'binary'` whenever the file extension belongs to `BINARY_EXTENSIONS`, such as `woff` or `woff2` (see [4]). This commit fixes the inconsistency between `bundle.get_version()` and `bundle.get_link()` when `binary` is `True`. Currently, `bundle.get_version()` used `extension if binary else asset_type`, while `bundle.get_link()` always received `asset_type`. This could lead to an incorrect redirect when handling binary assets. The fix normalizes the value by updating `asset_type` beforehand and reusing it consistently in both `bundle.get_version()` and `bundle.get_link()`. This also improves readability by removing the inline conditional expression. [1]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/addons/base/models/assetsbundle.py#L166 [2]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/addons/web/controllers/binary.py#L146 [3]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/addons/base/models/ir_asset.py#L93-L94 [4]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/tools/constants.py#L6-L7 Sentry-7441025709 Forward-Port-Of: odoo/odoo#263506
This update resolves an issue where creating a new bank account with a blank or empty proxy value (CPF/CNPJ or Random Key) would cause an error. The fix ensures that the system correctly handles these cases, preventing the creation process from failing and improving data integrity. This ensures users can consistently create bank accounts within the BR module.
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 fixes an issue where the Table of Contents in the HTML editor wouldn't update after editing headings. Specifically, deleting a heading caused the ToC to stop refreshing. The fix ensures the ToC always updates correctly, regardless of edits made to the content.
Original PR description
Steps to Reproduce : - Go to To-Do → Create New and add a Table of Content block - Type text → in new line create /h1 → it appears in ToC - Place cursor before /h1 and press Backspace → it merges with paragraph Description of the issue: Table of Content block does not update accordingly Cause: After the heading is merged with the previous paragraph, `delayedUpdateTableOfContents` is triggered, but at that time no heading is available in the editable area. As a result, instead of updating the Table of Contents, it returns without making any changes. Solution: If Table of content already contains heading, then update regardless of whether editable contains heading elements or not. task-6150579 Forward-Port-Of: odoo/odoo#264161 Forward-Port-Of: odoo/odoo#261675
This update fixes an issue where the template name wasn't correctly displayed after selecting a template using the 'Search More' feature in the employee form. The fix ensures that the correct template label is shown, improving the user experience when loading templates. This prevents confusion and ensures accurate template selection.
Original PR description
Version: - saas-19.1 Steps to reproduce: - Open an employee form. - Click "Load a Template". - Use "Search More" and select a template. Issue: - The selected template label is displayed as "Unnamed" after selecting a template from the search view. Cause: - When selecting a record through "Search More", the returned value only contains the record `id` and does not include `display_name`. As a result, the many2one field cannot render the correct label and falls back to "Unnamed". Fix: - Perform an ORM read to fetch the missing `display_name` using the selected record id, then update `selectedTemplate` with the complete value so the correct template name is displayed. Task-6186635 Forward-Port-Of: odoo/odoo#264556
A rare error causing tracebacks when hovering shape options in website snippets was fixed. The issue stemmed from missing slashes in image source URLs, which prevented a key function from correctly processing the images. This update restores the necessary slashes, ensuring stable operation and preventing these tracebacks.
Original PR description
**Description of the problem** A traceback is generated when hovering shape options in the snippets `s_cta_mobile` and `s_cta_mockups`. **How to reproduce** Drop `s_cta_mockups` -> click one of the two images -> open the shape selector -> hover a shape -> Traceback **Why the problem happens** The "source" attribute of `img` elements in the affected snippets is missing a trailing slash. After PR [1], the regular expression in `loadImageInfo` (html_editor/static/src/utils/image_processing.js) does not match anymore the source, thus the variable that should contain the source string remains empty and a traceback is generated. **Fix** All missing trailing slashes are restored. [1]: https://github.com/odoo/odoo/pull/151858 task-6103616
This update fixes a performance issue that slowed down rendering in Odoo's large reports, particularly when navigating tables like Accounting Balances Sheets. By simplifying the CSS rules, the system now recalculates styles faster, leading to a smoother user experience.
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 ensures that account reconciliation displays accurately after a reconciliation record is removed. Previously, leftover data caused the system to incorrectly show reconciled accounts, even when the reconciliation was no longer active. This fix cleans up the data and corrects the display in the user interface.
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 that button text colors within the HTML builder align with the overall button styles, creating a more visually consistent and professional design. Previously, the text colors were noticeably different, leading to a less polished user experience. This change improves the builder's usability and aesthetic appeal.
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 technical error that prevented Odoo from correctly handling email server settings. Previously, missing or invalid configurations would cause errors, now records without email settings are handled smoothly, ensuring reliable email functionality.
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 corrects a restriction in the Recruitment app where Interviewer users could view talent pools but lacked the ability to manage applicants or create new pools. The fix addresses a security rule preventing access to applicants within pools, aligning with the intended role limitations.
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. Previously, this was restricted due to accounting preferences, but now it's a more practical approach for branch operations. This simplifies payment setup for businesses with multiple locations.
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 update fixes a potential issue during Odoo deployments by logging missing module dependencies as warnings. This provides clearer alerts for administrators, making it easier to identify and resolve deployment problems. Ultimately, this improves the reliability and manageability of Odoo installations.
Original PR description
Log the issue as a warning, and add the missing module dependencies. This should ease managing such deployment issue. Forward-Port-Of: odoo/odoo#266030
This update resolves a startup error in Odoo caused by a missing dependency. The system was unable to find the 'clean' module within the lxml library, which is required for core functionality. This fix ensures Odoo can start correctly.
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 resolves a potential issue during Odoo upgrades related to temporary configuration records. By directly applying group settings, the update eliminates the need for a complex workaround and ensures a smoother, more reliable upgrade process. This improves the overall stability of the Enterprise version.
Original PR description
Replace the `res.config.settings transient record + execute()` hack with a direct group implication on `group_field_service_allow_material` to avoid orphan transient records during upgrade. see: https://github.com/odoo/upgrade/pull/10310#issuecomment-4518235969
This update corrects a recent issue where the 'Send Report' action was inadvertently removed from the planning slot views. The fix restores this functionality, ensuring users can easily generate reports directly from the planning interface. This ensures consistent functionality across key workflows.
Original PR description
Issue: ---------------------------------------- Some actions that were in Field Service task form view app aren't anymore in planning slot form view. Steps to reproduce: ---------------------------------------- - Go to the list view of planning view and select some slots - In the cog the action "Send Report" is there - Go in the slot's form view - In the cog, the action is not there Cause: ---------------------------------------- During the merge of Field Srevice in Planning. The action was removed from the form view. Solution: ---------------------------------------- Like in [saas-19.1](https://github.com/odoo/enterprise/blob/62b11599d08afa93cb9391f0b5aee3c610a754c8/industry_fsm_report/views/project_task_views.xml#L135-L146) we add "Send report" to the cog menu in list view. opw-6227745
This update to the odoo spreadsheet component addresses several technical issues related to data export and pivot table functionality. Specifically, it improves how formulas handle errors and correctly manages ranges, enhancing the reliability of spreadsheet reports. This update also includes new features and improvements to the Claude skill.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/96730cde0f [REL] 19.2.14 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/96730cde0f [REL] 19.2.14 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/28ee06827e [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/678ec266bb [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/1c0c884d4c [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/ae67cd345d [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/6b043bb023 [IMP] claude: add review skill [Task: 6223095](https://www.odoo.com/odoo/2328/tasks/6223095) https://github.com/odoo/o-spreadsheet/commit/67d2c05b68 [IMP] claude: add testing skill [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/1c38e43a90 [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>
A recent issue causing the 'project_task_history_tour' to intermittently fail has been resolved. This fix ensures the tour consistently runs, improving the reliability of the project task history feature for users. This prevents potential disruptions and maintains a smooth user experience.
Original PR description
Since #237531 the tour `project_task_history_tour` seems to sometimes fail. runbot-238566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue where users could repeatedly click the 'release table' button while an order was being processed, leading to unintended actions. The change now blocks the UI during table unbooking and ensures a proper redirect, improving the user experience and preventing data inconsistencies.
Original PR description
When unbooking a table, the UI was not blocked, allowing the user to potentially spam the button or perform other actions while the order was being deleted. It also lacked a proper redirection. task-id: 5859460 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246741
This update optimizes how Odoo renders large pages, like account reports, by streamlining the styling process. The change avoids a slow styling technique that triggered unnecessary recalculations, leading to faster page loading and smoother performance during common actions. This results in a better user experience for all users.
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 update fixes a technical issue within the Odoo Enterprise software that impacted the generation of GSTR2B reports for non-GST supplies in Vietnam. The change ensures accurate reporting by correcting a misidentified section key, improving data accuracy for tax compliance.
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 corrects a bug where invoice PDFs generated before sending didn't display the correct 'Proforma' header. The fix ensures that invoices are initially generated as 'Proforma' until sent to the customer, then switch to the standard invoice header. This prevents confusion for customers receiving invoices.
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 payroll warnings weren't easily adjustable. The change allows for more flexible and accurate updates to payroll warning data, ensuring compliance and better reporting for Swiss businesses using the Enterprise module. This improves the reliability of payroll calculations.
Original PR description
Forward-Port-Of: odoo/enterprise#107792
This update fixes a reporting issue where weekly subscription revenue wasn't accurately reflected in the project dashboard. The change ensures that revenue from weekly subscriptions is now correctly calculated and displayed, improving the accuracy of financial reporting for projects with this subscription type.
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#118254 Forward-Port-Of: odoo/enterprise#118163
This update fixes an issue where the product catalog snippet would reset to the first items after scrolling on mobile devices. This was caused by automatic rerendering triggered by viewport size changes. The fix reintroduces a mechanism to only update the snippet when the screen size changes, ensuring a smoother and more reliable display of the product catalog.
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
A technical issue preventing a test from properly updating was resolved. This fix ensures that the l10n_be_coda module's test suite functions correctly, maintaining the stability and reliability of the Belgian accounting features within Odoo Enterprise. This change was part of a larger effort to improve test coverage.
Original PR description
Test was commented instead of updated in this commit https://github.com/odoo/enterprise/commit/f1fafe0060c221e4a268c897af30455cc3d029ef task-none Forward-Port-Of: odoo/enterprise#118344 Forward-Port-Of: odoo/enterprise#117924
This update resolves minor issues within the core POS test suite. Specifically, it corrects how tests handle empty data results and prevents unexpected type conversions, ensuring the reliability of our POS testing process. This contributes to overall product stability and reduces the risk of future issues.
Original PR description
..., l10n_es_pos, l10n_jo_edi_pos, l10n_br_edi_pos
---
Fix two bugs in the checkTicketData() test helper:
- Replace falsy check `!statement` with `!statement.length` to
correctly handle empty NodeList results from querySelectorAll,
as an empty NodeList is still truthy.
- Replace loose equality `ruleFound == rule.negation` with strict
equality `ruleFound === (rule.negation || false)` to avoid
unintended type coercion when `rule.negation` is undefined.
---
Task: https://www.odoo.com/odoo/project/1737/tasks/6147566
Forward-Port-Of: odoo/odoo#260431This update fixes minor bugs in the core tests for our Point of Sale system. Specifically, it corrects how the system handles empty data results and prevents unexpected behavior when comparing values. These changes ensure the tests run reliably and contribute to the overall stability of the POS functionality.
Original PR description
..., l10n_es_pos, l10n_jo_edi_pos, l10n_br_edi_pos
---
Fix two bugs in the checkTicketData() test helper:
- Replace falsy check `!statement` with `!statement.length` to
correctly handle empty NodeList results from querySelectorAll,
as an empty NodeList is still truthy.
- Replace loose equality `ruleFound == rule.negation` with strict
equality `ruleFound === (rule.negation || false)` to avoid
unintended type coercion when `rule.negation` is undefined.
---
Task: https://www.odoo.com/odoo/project/1737/tasks/6147566
Forward-Port-Of: odoo/enterprise#114581This update resolves a test failure related to GS1 barcode scanning in the Point of Sale module. The fix ensures that barcodes are correctly interpreted by adding a leading zero to the test data, aligning it with the expected GTIN-14 format. This prevents issues with product addition to orders during scanning.
Original PR description
The test_GS1_pos_barcodes_scan was failing because the "GS1 Variant Product" barcode was defined as a 13-digit string, while the tour scans it using the GS1 AI 01 (GTIN), which expects a 14-digit GTIN-14. By adding a leading zero to the barcode in the test setup, we align it with the GTIN-14 format parsed by the POS barcode parser during the scan, ensuring the product is correctly added to the order. runbot-error: 242323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258089
This update resolves an issue where setting Intrastat information on product templates without associated products would trigger an error. The fix ensures that the system correctly handles product templates without variants, preventing unexpected errors and improving data integrity. This ensures consistent reporting for Intrastat data.
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 resolves an issue where product variant prices didn't automatically update when the cost price changed. Previously, users had to manually switch price lists to trigger the update. The fix adds a direct update mechanism to ensure on-sale prices reflect cost changes immediately, improving pricing accuracy and reducing manual intervention.
Original PR description
When we create a product variant and have a pricelist which is based on the cost price, and change the cost price, the on_sale_price doesn't update. You have the change the price list to other and…
When we create a product variant and have a pricelist which is based on the cost price, and change the cost price, the on_sale_price doesn't update. You have the change the price list to other and back to the one you want for it to trigger change because the _onchange_compute_pricing only gets triggered if there's change on pricelist (pricer_sale_pricelist_id), and sales price (lst_price). Steps to Reproduce: 1.Create a pricelist and add a line with "formula" price type, and based on "cost", 2.Create a product variant, and add the pricelist just created. 3.Change the "Cost". The "On Sale Price" doesn't update. 4.You have to change the price list to some other and back to the one you want for the "On Sale Price" to update. To fix the issue, we add the field Cost (standard_price) on api.onchange, so when we change the cost it'll update the "On Sale Price" right away. opw-5947995 Forward-Port-Of: odoo/enterprise#117806 Forward-Port-Of: odoo/enterprise#111892