Daily updates from Odoo
Navigate
Branch
Friday, January 30, 2026
200 changes
23 changes
Resolved issues and error corrections
This update resolves an issue where the scrollbar wasn't visible in the time off Kanban view, preventing users from easily seeing their vacation time requests. The fix adds a scrollbar to the view, ensuring users can now access and manage their time off requests effectively.
Original PR description
Before: the scrollbar of the kanban view in timeoff was not showing coz of which users were not able to see their timeoffs easily After: Fixed the scrollbar of the kanban view so that the user can be able to see their timeoffs which they were not able to do that easily Fix: Added the `overflow-x` as auto so that the scrollbar is visible. Task:5502863 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245443
This update corrects a bug where archived journals were still appearing as selectable payment methods when creating company expenses. The fix ensures that only active journals are offered, improving the user experience and preventing incorrect payment selections. This was caused by a previous code change that didn't properly filter inactive journals.
Original PR description
Steps to Reproduce: 1. Go to Accounting > Configuration > Journals 2. Archive a Journal with outgoing payment method 3. Go to Expenses > Create an Expense paid by company 4. Note that payment methods…
Steps to Reproduce:
1. Go to Accounting > Configuration > Journals
2. Archive a Journal with outgoing payment method
3. Go to Expenses > Create an Expense paid by company
4. Note that payment methods from archived journal are still visible and can be selected.
Issue:
- Archived journals with outbound payment methods were still selectable when creating company-paid expenses.
- Due to this [commit](https://github.com/odoo/odoo/commit/5c9a6704dd54bbbde1703850619ddcc1a3552547) The journals can be archived without system prevention as the action_archived method has been removed.
Solution:
- This occurred because selectable_payment_method_line_ids did not filter out inactive journals when falling back to a generic search. -Aligning the search domain with
[company_expense_allowed_payment_method_line_ids]
(https://github.com/odoo/odoo/blob/19.0/addons/hr_expense/models/res_company.py#L20) by excluding payment method lines linked to inactive journals.
Before Fix:
```py
In [1]: expense = self.env['hr.expense'].browse(1639)
In [2]: expense.selectable_payment_method_line_ids
Out[2]: account.payment.method.line(2, 4, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [3]: archived_journal_ids = []
In [4]: payment_method_lines = self.env['account.payment.method.line'].search([
...: *self.env['account.journal']._check_company_domain(expense.company_id),
...: ('payment_type', '=', 'outbound'),
...: ])
In [5]: payment_method_lines
Out[5]: account.payment.method.line(2, 4, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [6]: for payment_method_line in payment_method_lines:
...: if not payment_method_line.journal_id.active:
...: archived_journal_ids.append(payment_method_line.journal_id.id)
...:
In [7]: archived_journal_ids
Out[7]: [7, 8]
```
After Fix:
```py
In [8]: payment_method_lines_with_fix = self.env['account.payment.method.line'].search([
...: # The journal is the source of the payment method line company
...: *self.env['account.journal']._check_company_domain(expense.company_id),
...: ('payment_type', '=', 'outbound'),
...: ('journal_id.active', '=', True),
...: ])
In [9]: payment_method_lines_with_fix
Out[9]: account.payment.method.line(153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [10]: archived_journal_ids_with_fix = []
In [11]: for payment_method_line in payment_method_lines_with_fix:
...: if not payment_method_line.journal_id.active:
...: archived_journal_ids_with_fix.append(payment_method_line.journal_id.id)
In [12]: archived_journal_ids_with_fix
Out[12]: []
```
OPW-5461359
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242743This update fixes an issue with how Saudi social insurance contributions are recorded in Odoo. The change ensures that employer payments are accurately assigned to the correct accounting accounts, improving financial reporting for Saudi businesses using this module. This resolves a discrepancy in the posting of social insurance contributions.
Original PR description
Fix the account configuration used by Saudi social insurance contribution salary rules for the company. This ensures employer contributions are posted to the correct accounting accounts. Task-5468575 Forward-Port-Of: odoo/enterprise#105182
This update resolves a test failure related to the audit trail functionality within the account module. Specifically, a change was made to ensure data flushing occurs during certain tests, improving the reliability of the audit trail reporting. This ensures accurate tracking of account transactions.
Original PR description
Since this commit https://github.com/odoo/odoo/pull/242248/changes flushing inside `test_cant_unlink_message1`, `test_cant_unown_message` is now required. https://runbot.odoo.com/odoo/runbot.build.error/237803 runbot/error-237803 Forward-Port-Of: odoo/odoo#246353
This update corrects a minor issue in the website product pricing calculation. An unnecessary 'target_currency' parameter was being passed, causing confusion. The change simplifies the process by removing this parameter, ensuring accurate pricing without impacting functionality.
Original PR description
In website_sale product price computation in [_to_markup_data](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale/models/product_product.py#L163) and…
In website_sale product price computation in [_to_markup_data](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale/models/product_product.py#L163) and [_get_additionnal_combination_info](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale/models/product_template.py#L490), the target_currency is passed but it is unused parameter.
The product_pricelist price computation logic relies on the [currency](https://github.com/odoo/odoo/blob/saas-18.2/addons/product/models/product_pricelist.py#L162) and target_currency is not used anywhere in the pricing flow. As a result, passing target_currency adds confusion without affecting the outcome.
The target_currency parameter was unused in the method call flow and, due to this, it was always being passed as NULL. This made the parameter ineffective and confusing, while the actual logic expects a valid currency value.
This commit replaces target_currency with currency to avoid unused / misleading parameter.
Traceback
```py
2026-01-22 12:50:48,564 48232 ERROR currency_19 odoo.addons.website_sale.tests.test_website_sale_product_template: ERROR: TestWebsiteSaleProductTemplate.test_markup_data_uses_taxes_included_price_when_configured_on_website
Traceback (most recent call last):
File "/home/odoo/odoo/odoo/addons/website_sale/tests/test_website_sale_product_template.py", line 81, in test_markup_data_uses_taxes_included_price_when_configured_on_website
markup_data = self.product._to_markup_data(self.website)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/addons/website_sale/models/product_product.py", line 162, in _to_markup_data
product_price = request.pricelist._get_product_price(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/addons/product/models/product_pricelist.py", line 121, in _get_product_price
return self._compute_price_rule(product, *args, **kwargs)[product.id][0]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/addons/product/models/product_pricelist.py", line 220, in _compute_price_rule
price = suitable_rule._compute_price(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: ProductPricelistItem._compute_price() got an unexpected keyword argument 'target_currency'
```
Before fix,
```py
(Pdb) > /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(166)_compute_price_rule()
(Pdb) args
self = product.pricelist(2,)
products = product.product(4,)
quantity = 1
currency = None
uom = None
date = False
compute_price = True
kwargs = {'target_currency': res.currency(20,)}
> /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(186)_compute_price_rule()
(Pdb) currency
(Pdb) self.currency_id
res.currency(20,)
(Pdb) self.env.company.currency_id
res.currency(1,)
(Pdb)
```
After fix,
```py
(Pdb) > /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(166)_compute_price_rule()
(Pdb) args
self = product.pricelist(2,)
products = product.product(4,)
quantity = 1
currency = res.currency(20,)
uom = None
date = False
compute_price = True
kwargs = {}
> /home/odoo/odoo/saas~18.2/odoo/addons/product/models/product_pricelist.py(186)_compute_price_rule()
(Pdb) currency
res.currency(20,)
(Pdb) self.currency_id
res.currency(20,)
(Pdb) self.env.company.currency_id
res.currency(1,)
```
- opw - [5447980](https://www.odoo.com/odoo/project/70/tasks/5447980)
- upg - [3782135](https://upgrade.odoo.com/odoo/upgrade.request/3782135)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#246180
Forward-Port-Of: odoo/odoo#242998This update streamlines the user experience by embedding relevant actions, like 'Create Vendor Bill,' directly into the appropriate journal folders (e.g., Purchase, Sales). This ensures users have the necessary tools available where they're working, improving efficiency.
Original PR description
What: Previously, actions like "Create Vendor Bill" were only embedded in the main "Finance" folder. Now, these actions are also embedded directly into the specific subfolders for each journal type…
What: Previously, actions like "Create Vendor Bill" were only embedded in the main "Finance" folder. Now, these actions are also embedded directly into the specific subfolders for each journal type (e.g., "Purchase", "Sales"). All relevant actions are also kept in the parent "Finance" for general accessibility. The purchase actions are also added to the "Inbox" folder. Why: The previous behavior was inefficient. A user uploading a vendor bill to the "Purchase" folder would not see the "Create Vendor Bill" action. He would only see it when he is in the parent "Finance" folder. By embedding it by default this streamlines the process by ensuring the necessary tools are available exactly where the user is working. How: The logic is implemented within the _documents_configure_sync method of the account.journal model. This is the ideal location because it handles the complete setup of a journal for the Documents app. This ensures that actions are embedded correctly both during module installation and dynamically whenever a new journal is created by a user. Notes: - Tests were rewritten to check these embeddings on install. And were refactored to be more maintainable and cover bank statements better. - The test for importing bank statements had to be moved to a separate testing module, as it needs the `account_bank_statement_extract` module, which is not in the dependencies of `account_move`. - The tests for bank statement processing errors was improved to match the tests in later versions Task-5410752 Related Task-5075610 Forward-Port-Of: odoo/enterprise#102039
This update fixes a misclassification of account 649 in the French Profit and Loss report. The change aligns the report with French accounting standards (PCG 2025 & 2026) by correctly categorizing this account within Wages and Salaries and Social Security Charges. This ensures accurate financial reporting for French businesses using the Odoo Enterprise solution.
Original PR description
## Issue In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"*…
## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).
## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
- *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
- *Wages and salaries*: **649 is not mentioned**
- *Social security charges*: **649 is not mentioned**
## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.
opw-5724559
Forward-Port-Of: odoo/enterprise#105856
Forward-Port-Of: odoo/enterprise#105474This update resolves a frustrating user experience issue where a notification about delayed translations would block access to editing features on multilingual websites. Previously, clicking 'Edit' after a translation update would simply hide the notification, preventing users from making necessary changes. This fix ensures notifications disappear correctly, allowing seamless website editing.
Original PR description
When we have a delayed translation, we get a notification saying that we should edit, or translate to apply the changes made in the default language. However, when we click on edit, the notification is still present, and it blocks the dropdown, so the user doesn't see it until the notification disappears. Steps to see the issue: - In a multilingual websites: - Add a content in the default language, 'A' - Translate the content in your other language 'B' - Come back to 'A', and edit the content, e. g. add some style - Come back to the language 'B' => A toaster notification appears, and if you click on "Edit" button, you cannot see what's below. task-5447519 Forward-Port-Of: odoo/odoo#245260
This update ensures that WebGL testing continues to function correctly in Chrome's headless mode (version 144+). Chrome's default settings now disable WebGL, so this change re-enables it for testing purposes, specifically to maintain functionality for features like image filters in the website builder. While SwiftShader is less secure, it's deemed acceptable for controlled test environments.
Original PR description
Since Chrome 144 disabled [^1] by default the WebGL fallback to the software renderer SwiftShader, this commit reenables [^2][^3] it when running in headless mode to allow to keep testing WebGL features (i.e. image filters in website builder). Note: the SwiftShader implementation is considered deprecated and less safe than proper hardware based ones, hence not recommended for a regular usage with untrusted content. However, as tests are run in a more controlled environment, it looks reasonnable to opt-in to keep actually testing WebGL features. [^1]: https://chromium-review.googlesource.com/c/chromium/src/+/7128438 [^2]: https://issues.chromium.org/issues/476172421 [^3]: https://chromestatus.com/feature/5166674414927872 Forward-Port-Of: odoo/odoo#246289
This update resolves an issue in the Peppol demo mode where a branch company with the same VAT number as the parent company would receive an 'id_client already in use' error. The fix ensures each company receives a unique id_client, preventing data conflicts and improving demo stability. This ensures the demo accurately reflects the intended Peppol functionality.
Original PR description
Steps to reproduce in demo: 1. Activate Peppol in the main company for both sending and receiving; 2. Create a branch company (with same VAT number as the main company); 3. Activate Peppol in the branch and select "Send from parent company"; 4. Error message: "This id_client is already used on another user.". In demo edi_mode, when trying to connect a branch company with the same VAT than the parent company, the demo function took the same id_client for every company, which violates the unique constraint on id_client. task-5888203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246287
This update ensures that the current day location field is consistently included when retrieving data for the homeworking feature. Previously, this data was sometimes missing, causing issues when the feature was used in different parts of the system, such as the studio. This fix guarantees accurate location information is always available.
Original PR description
Before this commit, the feature at commit odoo/odoo@b3be3af61cc08d0dea84969425d24957f215b26f worked by chance, because in most cases ALL fields where returned in the get views, since most of the time the search view is asked for as well, hence yielding all fields in the model There were issues when triggering get_views from another place, namely studio when creating a many2many. After this commit, we make sure the current day location field's description is sent opw-5484321 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246096 Forward-Port-Of: odoo/odoo#245740
This update fixes an issue where embedded actions within folders were hidden from the interface, preventing users from managing or deleting them. The change ensures that embedded child actions are now correctly displayed and accessible, streamlining the process of managing actions within documents. This improves usability and reduces potential data management issues.
Original PR description
### ISSUE Certain embedded actions inside a folder may not appear in the folder’s server actions list (accessible via the gear icon), making them impossible to find or delete through the interface. This occurs because documents.document.get_documents_actions applies overly broad filtering that removes all child server actions, regardless of whether they are embedded in the folder. As a result, if two embedded actions are created in a folder and one is later set as a child of the other, the embedded child action disappears from the visible list but remains embedded in the folder, leaving no way to remove it from the UI. ### SOLUTION The method has been updated to exclude only non-embedded child actions. Embedded child actions are now preserved and correctly displayed in the folder’s actions list, allowing them to be managed and deleted as expected. opw-5213881 Forward-Port-Of: odoo/enterprise#105800 Forward-Port-Of: odoo/enterprise#100395
This update resolves a user experience inconsistency within the account_peppol module. Previously, the system used 'demo' for user neutralization, while the edi_mode was set to 'test'. This change ensures a clear and consistent approach, simplifying the setup and operation for users.
Original PR description
Currently, the proxy_client_user is neutralized as demo. But the edi_mode is set to test. It's confusing for the users, and we should be consistent. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246181
This update resolves an issue where a technical error during bill import could lead to duplicate entries in the PEPPOL system. The fix ensures that the import process doesn't block confirmation and allows for unlinked bills, preventing potential data inconsistencies. It also handles unexpected errors after move creation to maintain data integrity.
Original PR description
A UserError there can cause duplicates in peppol fetching. It should never block an ack. We can leave them unlinked We also do the same for any unexpected error that occurs after we've created the move. opw-5492092 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246233 Forward-Port-Of: odoo/odoo#246133
This update resolves a small technical issue where a missing space in a route caused a problem with the account online synchronization process. This fix ensures the synchronization feature functions correctly, preventing potential disruptions to data synchronization.
Original PR description
During this forward port: https://github.com/odoo/enterprise/commit/a5b9372ca0b23151046c14c9a8ead0ed9cd46b80 there was a missing space in the route. no task id Forward-Port-Of: odoo/enterprise#105849
This update enhances the mobile signing experience by addressing layout issues and navigation problems. Specifically, it cleans up the user interface, clarifies empty states, and ensures smoother transitions during the signing process, leading to a more polished and user-friendly experience.
Original PR description
Before: - Several mobile screens had layout issues such as extra white space, misaligned elements, and uneven spacing. - During signing, the "Next" navigation appeared abruptly without a smooth transition. After: - Improved mobile layouts to remove unnecessary white space and keep grid alignment consistent. - Added placeholders on relevant screens (e.g. Documents folder, Authorized Users, redirect link) to clarify empty states. - Fixed transition issues when navigating between fields during the signing flow. Impact: - Provides a cleaner and more polished mobile signing experience. - Improves usability by making empty states clearer and navigation smoother. Task: 5493477 Forward-Port-Of: odoo/enterprise#104606
The Point of Sale system now gracefully handles errors during initialization, preventing the app from getting stuck on a loading screen. Users are presented with an option to clear local data and refresh, particularly beneficial for mobile users who don't want to manually reset their data. This enhances the user experience and improves POS reliability.
Original PR description
Inconsistent data in the localDB or local storage can cause the POS to fail before it can get initialized. When this happens the page just stays showing the loading screen forever. Now when an error happens while initializing the POS the loader will disappear and the app will give the user the option to clear all local data and refresh the page. This should be especially useful for users on mobile where it's a pain to refresh the local data manually. Task-[5420544](https://www.odoo.com/odoo/project/1737/tasks/5420544) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242532
This update addresses a potential error in Odoo that could occur when attempting to access related records through 'res_id' fields. Specifically, the system would fail if a 'res_id' was set to 0. This change ensures the system handles this scenario gracefully, preventing errors and improving data reliability.
Original PR description
`browse(x.mapped('res_id'))` may fail if there are res_ids that are equal to 0. Update existing code.
odoo/enterprise#105767
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update addresses a potential issue where incorrect IDs were being used within Odoo's core modules. The fix ensures that all IDs are properly validated, enhancing data accuracy and reliability across various business processes. This improves the overall stability and trustworthiness of the system.
Original PR description
https://github.com/odoo/odoo/pull/246097
A recent issue preventing users from switching to superuser mode has been resolved. The problem stemmed from a simple typo – 'sesssion' instead of 'session' – in the code. This fix ensures a smoother and more reliable experience for all users.
Original PR description
Currently an error occurs when user tries to switch to superuser. Steps to replicate: - Make a DB and turn on debug mode. - Click on the bug icon and click `Become Superuser`. Error: `AttributeError: 'Request' object has no attribute 'sesssion'` Cause: - Session incorrectly spelled as `sesssion`. Fix: - Corrected `request.sesssion` to `request.session`. No Id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that tests for KPI reporting in the email system run consistently. Previously, demo data could create mail activities that interfered with test results. Now, the tests are run with a clean slate, guaranteeing accurate and reliable reporting.
Original PR description
Commit ff941e6555c12918803db4a72511c9381cc58c31 introduced a test that counts the amount of mail activities grouped by type. However, the test doesn't take into consideration that the demo data might have created some activities. With this commit, we ensure the tests run with a clean state by removing any pre-existing mail activities so that we have consistent and expected results. Runbot-build-error-id: [234966](https://runbot.odoo.com/odoo/runbot.build.error/234966)
This update corrects a bug where 'todo' and 'none' audit statuses on accounts were incorrectly grouped together in reports. Previously, sorting or filtering by 'todo' status didn't accurately reflect the actual status of accounts. This change ensures accurate reporting and filtering based on account status.
Original PR description
When going on the balance view of a working file, when trying to sort by the status or filtering on 'todo', the audit status with no value would still be here.
To Reproduce:
- Install the demo data
- Create a working file _ Click on Status
- The To Review and nothing are not sorted
- Add a domain ("audit_status", "=", "todo")
- THe audit status with no value are still hereThis update fixes a limitation in the document search feature, allowing users to now search across multiple user root folders. The original system missed a key test scenario, resulting in incomplete search results. This change ensures a more comprehensive and accurate search experience for all users.
Original PR description
Introduced with 7994db2c, where we forgot about the click all tests that would enable all filters at once. See runbot error 237504 Task-5893183
5 changes
Resolved issues and error corrections
This update fixes an issue in the French Profit and Loss report where account 649 was incorrectly categorized. The change aligns the report with French accounting standards (PCG 2025 & 2026) by moving the account to the appropriate 'Wages and Salaries' section. This ensures accurate financial reporting for French businesses using the Odoo Enterprise solution.
Original PR description
## Issue In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"*…
## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).
## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
- *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
- *Wages and salaries*: **649 is not mentioned**
- *Social security charges*: **649 is not mentioned**
## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.
opw-5724559
Forward-Port-Of: odoo/enterprise#105856
Forward-Port-Of: odoo/enterprise#105474This update resolves a bug where the 'Today' filter in Frontdesk was incorrectly displaying visitors due to timezone differences. The fix converts all date/time comparisons to UTC, ensuring accurate filtering regardless of the user's location. This ensures all visitor records are correctly displayed.
Original PR description
Steps to reproduce -------------------------- 1. Install Frontdesk 2. Go to Frontdesk → Visitors 3. Create a visitor with a check-in time before today 05:30 (local timezone: Asia/Kolkata) 4. Check visitors Issue: -------- The created record is not displayed because "today" filter used the user's local date to build a datetime range but failed to convert those boundaries to UTC before querying the database, leading to incorrect filtering in non-UTC time zones. Solution ------------- Convert those datetimes to UTC using `.to_utc()` in the filter domain opw-5385995 Forward-Port-Of: odoo/enterprise#102865
This update addresses a small technical issue where a missing space in a route caused a problem with the account online synchronization process. This correction ensures the synchronization feature functions correctly, preventing potential disruptions to data synchronization. It's a routine fix to maintain system stability.
Original PR description
During this forward port: https://github.com/odoo/enterprise/commit/a5b9372ca0b23151046c14c9a8ead0ed9cd46b80 there was a missing space in the route. no task id Forward-Port-Of: odoo/enterprise#105849
This update corrects a bug where the serial number on delivery orders was incorrectly updated when adding new items in the 'ready' state. The fix ensures that the original serial number is maintained, preventing discrepancies in inventory tracking and improving order accuracy. This resolves an issue impacting product traceability.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state. opw-5385993 Forward-Port-Of: odoo/enterprise#105420 Forward-Port-Of: odoo/enterprise#105338
A bug was causing the input field for campaign testing to disappear, requiring users to close and reopen the dialog to use it. This fix addresses a technical issue with how the system handles empty input fields, ensuring the field remains visible and functional. The scope was limited to marketing automation to prioritize this specific problem.
Original PR description
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: -…
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: - The input area has disappeared. Now, the only way to get it back is by closing the dialog and reopening it Cause: - Field `resource_ref` uses `hide_model: True`, and when cleared, the widget has no value and no model selector to determine the target model because of the function `getRelation` that now returns `undefined`, by this XML fails to render the `<Many2OneField/>` https://github.com/odoo/odoo/blob/7680b83501cef18362be38f90715d824f2bf9cd6/addons/web/static/src/views/fields/reference/reference_field.js#L107-L119 Solution: - Add `model_field: model_id` option to the view so the widget can resolve the model from the `model_id` field even when input is empty Note: - This behavior also occurs in other places. After discussion with the framework team, we agreed to keep the scope of this PR limited to marketing_automation, as this is not a priority issue. A broader fix can be addressed in the master if needed. opw-5473320 Forward-Port-Of: odoo/enterprise#104547
16 changes
Resolved issues and error corrections
This update resolves an issue where dynamic product snippets would cause horizontal scrolling when the content width was set to 'max'. The fix repositions the navigation buttons to prevent this, ensuring a consistent and user-friendly experience across larger devices. This improves the visual presentation of product listings.
Original PR description
Steps to reproduce: 1. Drag and drop the dynamic products snippet. 2. Select it and change the content width to **max**. Issue: When the content width is set to **max**, an unnecessary horizontal scroll appears. Reason: The issue occurs because the `previous` and `next` navigation buttons were not properly positioned. Fix: For devices larger than "mobile", the `previous` and `next` buttons are re-positioned, horizontally inward by "**50%**" of their own width with the help of `transform` property. This keeps the controls within the visible area and prevents horizontal scrolling. task-5090468 Before: <img width="1915" height="966" alt="image" src="https://github.com/user-attachments/assets/0c20d0b6-32cc-477b-8403-55bb0d372d8d" /> After: <img width="1920" height="963" alt="image" src="https://github.com/user-attachments/assets/4194b0f1-f3ad-4818-aa6f-2fda4561d2c7" /> Forward-Port-Of: odoo/odoo#237876
This update corrects a bug where archived journals with outbound payment methods were still appearing as selectable options when creating expense reports. The fix ensures that only active journals are considered, preventing users from selecting outdated payment methods and improving data accuracy. This resolves an issue that could have led to incorrect expense reporting.
Original PR description
Steps to Reproduce: 1. Go to Accounting > Configuration > Journals 2. Archive a Journal with outgoing payment method 3. Go to Expenses > Create an Expense paid by company 4. Note that payment methods…
Steps to Reproduce:
1. Go to Accounting > Configuration > Journals
2. Archive a Journal with outgoing payment method
3. Go to Expenses > Create an Expense paid by company
4. Note that payment methods from archived journal are still visible and can be selected.
Issue:
- Archived journals with outbound payment methods were still selectable when creating company-paid expenses.
- Due to this [commit](https://github.com/odoo/odoo/commit/5c9a6704dd54bbbde1703850619ddcc1a3552547) The journals can be archived without system prevention as the action_archived method has been removed.
Solution:
- This occurred because selectable_payment_method_line_ids did not filter out inactive journals when falling back to a generic search. -Aligning the search domain with
[company_expense_allowed_payment_method_line_ids]
(https://github.com/odoo/odoo/blob/19.0/addons/hr_expense/models/res_company.py#L20) by excluding payment method lines linked to inactive journals.
Before Fix:
```py
In [1]: expense = self.env['hr.expense'].browse(1639)
In [2]: expense.selectable_payment_method_line_ids
Out[2]: account.payment.method.line(2, 4, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [3]: archived_journal_ids = []
In [4]: payment_method_lines = self.env['account.payment.method.line'].search([
...: *self.env['account.journal']._check_company_domain(expense.company_id),
...: ('payment_type', '=', 'outbound'),
...: ])
In [5]: payment_method_lines
Out[5]: account.payment.method.line(2, 4, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [6]: for payment_method_line in payment_method_lines:
...: if not payment_method_line.journal_id.active:
...: archived_journal_ids.append(payment_method_line.journal_id.id)
...:
In [7]: archived_journal_ids
Out[7]: [7, 8]
```
After Fix:
```py
In [8]: payment_method_lines_with_fix = self.env['account.payment.method.line'].search([
...: # The journal is the source of the payment method line company
...: *self.env['account.journal']._check_company_domain(expense.company_id),
...: ('payment_type', '=', 'outbound'),
...: ('journal_id.active', '=', True),
...: ])
In [9]: payment_method_lines_with_fix
Out[9]: account.payment.method.line(153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [10]: archived_journal_ids_with_fix = []
In [11]: for payment_method_line in payment_method_lines_with_fix:
...: if not payment_method_line.journal_id.active:
...: archived_journal_ids_with_fix.append(payment_method_line.journal_id.id)
In [12]: archived_journal_ids_with_fix
Out[12]: []
```
OPW-5461359
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242743This update corrects a bug that prevented new partner records from being created when attempting to add them to an existing recordset. The issue stemmed from a mismanaged 'self' variable within the partner creation process. This fix ensures correct record handling during partner creation, improving data integrity.
Original PR description
**Issue:** `ValueError: Expected singleton` when creating new partners on a non empty (no singleton) recordset due to the `_add_missing_default_values` call. The default create method uses `self = self.browse()` to remove the records, but the `res.partner` override was still using its original `self`. **Fix:** Properly call the method on an empty recordset. related: https://github.com/odoo/odoo/commit/79486ec3fc553845cac14fb135c16fe0b093e3b4 opw-4932114
This update fixes an error in the French Profit and Loss report (`l10n_fr_reports`) where account 649 was incorrectly placed. The change aligns with French accounting standards (PCG 2025 & 2026) by correctly categorizing this account within 'Wages and Salaries' and 'Social Security Charges'.
Original PR description
## Issue In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"*…
## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).
## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
- *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
- *Wages and salaries*: **649 is not mentioned**
- *Social security charges*: **649 is not mentioned**
## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.
opw-5724559
Forward-Port-Of: odoo/enterprise#105856
Forward-Port-Of: odoo/enterprise#105474This update corrects a bug that prevented visitors from appearing in search results when their check-in times were recorded in time zones other than the user's local time. The fix ensures all date/time comparisons are done in UTC, resolving filtering inaccuracies and improving visitor data visibility across different locations.
Original PR description
Steps to reproduce -------------------------- 1. Install Frontdesk 2. Go to Frontdesk → Visitors 3. Create a visitor with a check-in time before today 05:30 (local timezone: Asia/Kolkata) 4. Check visitors Issue: -------- The created record is not displayed because "today" filter used the user's local date to build a datetime range but failed to convert those boundaries to UTC before querying the database, leading to incorrect filtering in non-UTC time zones. Solution ------------- Convert those datetimes to UTC using `.to_utc()` in the filter domain opw-5385995 Forward-Port-Of: odoo/enterprise#102865
This update ensures that WebGL testing continues to function correctly in Odoo's automated tests, even with recent changes in Chrome. Because SwiftShader (a software renderer) is now the default fallback for Chrome 144 in headless mode, this change re-enables WebGL to maintain testing of features like image filters. While SwiftShader is less secure, it's deemed acceptable for controlled test environments.
Original PR description
Since Chrome 144 disabled [^1] by default the WebGL fallback to the software renderer SwiftShader, this commit reenables [^2][^3] it when running in headless mode to allow to keep testing WebGL features (i.e. image filters in website builder). Note: the SwiftShader implementation is considered deprecated and less safe than proper hardware based ones, hence not recommended for a regular usage with untrusted content. However, as tests are run in a more controlled environment, it looks reasonnable to opt-in to keep actually testing WebGL features. [^1]: https://chromium-review.googlesource.com/c/chromium/src/+/7128438 [^2]: https://issues.chromium.org/issues/476172421 [^3]: https://chromestatus.com/feature/5166674414927872 Forward-Port-Of: odoo/odoo#246289
This update resolves an issue where editing a bank statement line caused unnecessary recalculations of all related lines, including reconciled ones. The change now ensures that only the edited line is recomputed, improving performance and stability when working with bank statement data. This optimization enhances the user experience and reduces processing time.
Original PR description
When we edit a bank statement line, it triggers the recompute of all other lines, even the reconciled ones. This commit changes this behavior so reconciled lines are not recomputed task-5882885
This update ensures that the current day location field is consistently included when retrieving data for the homeworking feature, particularly in scenarios like creating many-to-many relationships in Studio. Previously, this data was sometimes missing, causing issues. This fix guarantees accurate location information is provided, improving the functionality of the homeworking workflow.
Original PR description
Before this commit, the feature at commit odoo/odoo@b3be3af61cc08d0dea84969425d24957f215b26f worked by chance, because in most cases ALL fields where returned in the get views, since most of the time the search view is asked for as well, hence yielding all fields in the model There were issues when triggering get_views from another place, namely studio when creating a many2many. After this commit, we make sure the current day location field's description is sent opw-5484321 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246096 Forward-Port-Of: odoo/odoo#245740
This update resolves a problem where customer claims weren't being processed correctly due to a limitation in how the system matched invoices with VAT numbers. Specifically, when a child invoice shared the same VAT number as the parent, the system would incorrectly select a partner, preventing the necessary account move updates. This fix ensures accurate claim processing.
Original PR description
When we process new customer claims, we need to search for the corresponding account moves in order to update their `l10n_cl_dte_acceptation_status`. Currently, we only expect 1 partner per VAT number when searching for a partner to match with the account move. However, this is not always true. For instance, a child invoice contact will share the same VAT number than the parent partner. This can lead to the selection of the wrong partner in the search domain and consequently, the account move not being found. Related ticket: opw-5257481 Forward-Port-Of: odoo/enterprise#105653 Forward-Port-Of: odoo/enterprise#103366
This update resolves a confusion for users of the account_peppol module. Previously, a setting was configured as 'demo' while another related setting was 'test'. This change ensures a consistent and clear setup process, improving usability and reducing potential errors.
Original PR description
Currently, the proxy_client_user is neutralized as demo. But the edi_mode is set to test. It's confusing for the users, and we should be consistent. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246181
This update corrects a bug where the serial number of products on 'ready' delivery orders was being incorrectly updated. The fix prevents changes to the assigned serial number when adding new moves to these orders, ensuring accurate stock tracking and order fulfillment. This resolves an issue that could lead to discrepancies in inventory counts.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state. Forward-Port-Of: odoo/odoo#245622 Forward-Port-Of: odoo/odoo#245447
This update resolves a bug where the serial number assigned to products on 'ready' pickings was incorrectly updated during delivery order creation. The fix prevents unnecessary serial number changes, ensuring accurate tracking of stock and serial numbers. This improves data integrity and reduces potential errors in inventory management.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state. opw-5385993 Forward-Port-Of: odoo/enterprise#105420 Forward-Port-Of: odoo/enterprise#105338
This fix ensures that customers purchasing event tickets through POS are accurately registered as attendees. Previously, if customer information wasn't provided at the time of purchase, the registration was incomplete. This update aligns the POS registration process with the website, ensuring consistent attendee tracking and reporting.
Original PR description
Currently, when a customer is set on the order and buys a event ticket, the information is not set as partner on the registration. Steps to reproduce: ------------------- * Create an event that asks…
Currently, when a customer is set on the order and buys a event ticket, the information is not set as partner on the registration. Steps to reproduce: ------------------- * Create an event that asks for name but is not required * Open pos and sell on ticket * Do not put name info * Select a customer for the order * Validate order * Check registrations > Observation: The customer is not registered as the attendee Why the fix: ------------ We compare the scenarios with the same flow but from website registrations. On the website if there is no user registered: - If information is not filled, nothing will be registered on the registration - If information is filled it will be used to populate attendee fields If there is a user registered while on website: - If no information is filled, attendee fields will be populated with the data from the connected user - If information is filled, it will be used for attendee fields - If partial information is filled, it will be used for attendee fields but will also be completed with data coming from the connected user To achieve the same behavior from the pos we first need to register the customer as the partner for the event. During event creation we also remove values regarding attendee name, email, phone and company if they were not provided during the order. From the website they are not used during creation if they were not given by the customer. However, in the pos this information is present anyway (as empty string or False) as they are fields on the model "event.registration" and are still send to the backennd even if we remove the information here https://github.com/odoo/odoo/blob/787621e44a9cef30469849929df267cae9e977f2/addons/pos_event/static/src/app/screens/product_screen/product_screen.js#L127 We do the fix server-side as a fix in the frontend would not be as straightforward. A customer might be on the order before selecting event ticket and it's easy but one might also add the customer after the ticket was selected. opw-5137197 Forward-Port-Of: odoo/odoo#242783 Forward-Port-Of: odoo/odoo#234871
This update resolves a technical issue where a missing space in a route caused a problem with the account online synchronization process. This fix ensures the synchronization functionality operates correctly, preventing potential disruptions to data synchronization. It's a routine maintenance update.
Original PR description
During this forward port: https://github.com/odoo/enterprise/commit/a5b9372ca0b23151046c14c9a8ead0ed9cd46b80 there was a missing space in the route. no task id Forward-Port-Of: odoo/enterprise#105849
This update fixes an issue where some Odoo records wouldn't open correctly in their default form view. The change ensures that other views are enabled when opening records, providing a smoother and more reliable user experience. This resolves a technical glitch that impacted record access.
Original PR description
Records of some models may not want to be shown in their form view by default. See related ENT PR for documents. We re-export to avoid patching order issues. In particular, this makes sure that if we are in the webclient, the chat window is opened before executing the "real" open. Task-5386466 Forward-Port-Of: odoo/odoo#246173 Forward-Port-Of: odoo/odoo#244289
This update prevents documents from automatically opening in a form view when accessed through various channels like links or notifications. Previously, users were unexpectedly directed to the document's form, which has now been corrected to align with how documents are accessed in other views. This improves the user experience and ensures consistent document access.
Original PR description
Users do not want to access the form view of the document by default. This PR solves three cases for accessing documents.document records that were not covered before: * From the basic path pattern `odoo/x/documents.document/<id>` * From a systray notification "Open Form View" * when we are not yet in Documents * when we already are in Documents * From the Discuss app, on the record's thread Tests for most of these are included. Additionally, make sure the document is selected on accessing from `_get_access_action`. Task-5386466 Forward-Port-Of: odoo/enterprise#105809 Forward-Port-Of: odoo/enterprise#104622
4 changes
Resolved issues and error corrections
This update fixes an error in the French Profit and Loss report where account 649 was incorrectly placed. The change aligns the report with French accounting standards (PCG 2025 & 2026) by correctly categorizing this account within Wages and Salaries and Social Security Charges. This ensures accurate financial reporting for French businesses using the Odoo Enterprise solution.
Original PR description
## Issue In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"*…
## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).
## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
- *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
- *Wages and salaries*: **649 is not mentioned**
- *Social security charges*: **649 is not mentioned**
## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.
opw-5724559
Forward-Port-Of: odoo/enterprise#105856
Forward-Port-Of: odoo/enterprise#105474This update corrects a bug that prevented visitors from being displayed correctly when using the 'Today' filter in the Frontdesk module. The issue stemmed from incorrect timezone handling during filtering, which caused inaccurate results for users in non-UTC time zones. The fix converts all date/time values to UTC before querying, ensuring accurate visitor filtering regardless of the user's location.
Original PR description
Steps to reproduce -------------------------- 1. Install Frontdesk 2. Go to Frontdesk → Visitors 3. Create a visitor with a check-in time before today 05:30 (local timezone: Asia/Kolkata) 4. Check visitors Issue: -------- The created record is not displayed because "today" filter used the user's local date to build a datetime range but failed to convert those boundaries to UTC before querying the database, leading to incorrect filtering in non-UTC time zones. Solution ------------- Convert those datetimes to UTC using `.to_utc()` in the filter domain opw-5385995 Forward-Port-Of: odoo/enterprise#102865
This update addresses a small technical issue that prevented the online accounting synchronization feature from functioning correctly. A missing space in a route definition was corrected, ensuring the synchronization process operates as intended. This ensures seamless data updates between our cloud-based accounting system and local versions.
Original PR description
During this forward port: https://github.com/odoo/enterprise/commit/a5b9372ca0b23151046c14c9a8ead0ed9cd46b80 there was a missing space in the route. no task id Forward-Port-Of: odoo/enterprise#105849
This update resolves a bug where the input field for campaign tests would disappear when cleared. The fix adds a configuration to ensure the field always displays correctly, preventing users from needing to close and reopen the dialog to re-enter information. This improves the user experience for campaign testing.
Original PR description
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: -…
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: - The input area has disappeared. Now, the only way to get it back is by closing the dialog and reopening it Cause: - Field `resource_ref` uses `hide_model: True`, and when cleared, the widget has no value and no model selector to determine the target model because of the function `getRelation` that now returns `undefined`, by this XML fails to render the `<Many2OneField/>` https://github.com/odoo/odoo/blob/7680b83501cef18362be38f90715d824f2bf9cd6/addons/web/static/src/views/fields/reference/reference_field.js#L107-L119 Solution: - Add `model_field: model_id` option to the view so the widget can resolve the model from the `model_id` field even when input is empty Note: - This behavior also occurs in other places. After discussion with the framework team, we agreed to keep the scope of this PR limited to marketing_automation, as this is not a priority issue. A broader fix can be addressed in the master if needed. opw-5473320 Forward-Port-Of: odoo/enterprise#104547
16 changes
Enhancements to existing features
This update introduces a new warning in the payroll system to alert HR regarding employees with four consecutive fixed-term contracts (CDD). Specifically, it flags employees who meet certain criteria related to contract durations and start dates, helping ensure compliance and accurate payroll calculations. This change addresses a previously identified issue with employee profiles.
Original PR description
This commit adds a new warning "4th consecutive fixed-term contract" It should show up any employee that answers to this condition : - Being in the fourth consecutive contract where they all are CDD (= contract type). - Each of the 3 firsts contracts must have a value higher than 3 months - The date delta between today and the start contract date of the first CDD must be smaller than 2 years, or, if set, the date delta between the start contract date of the first CDD and the end contract date of the 4th one. The warning lead to concerned employees profiles. task-5421414
This update adds a new option to the invoice PDF legend, required by recent Argentinian regulations (RG 5762/2025). Users can now select 'Payment on informed CBU' or 'Operation Subject to Withholding' for the invoice legend, ensuring compliance with local tax requirements. This change is implemented within the accounting settings.
Original PR description
Before: - There is only one option for the legend of the invoice PDF for Document type 'A' and 'M'. - After ARCA's new regulation RG 5762/2025, we need to add one extra option 'Payment on informed CBU', for legend. After: - Now we have two options for the invoice PDF legend string. 1. 'Payment on Informed CBU.' 2. 'Operation Subject to Withholding.' - The user can set the value of the legend from the accounting settings. task-5409173
This update adjusts the default value for a critical field ('id') across several core Odoo modules, including AI, Approvals, Planning, VoIP, and WhatsApp. This change ensures consistency and simplifies configuration for these features, streamlining the user experience.
Original PR description
* planning,voip,website_helpdesk_livechat,whatsapp "id" is now the default value in the parent class. task-4801145 PR community: https://github.com/odoo/odoo/pull/246122
This update strengthens the security of our spreadsheet edition by introducing sheet protection. This prevents unauthorized modifications to spreadsheets, safeguarding important data and ensuring data integrity. It's a proactive measure to maintain the reliability and security of this key business tool.
Original PR description
task-5103728
This update introduces a 'draft' status for calendar events, allowing users to create events and fill in details without immediate notifications. This prevents unnecessary notifications and ensures accurate event tracking, particularly for events that are not yet confirmed. The change also streamlines the event status flow to avoid user errors.
Original PR description
This PR is a backup. Some features need more time and their commits are saved here. Original PR: https://github.com/odoo/enterprise/pull/103469 Community PR:
Resolved issues and error corrections
This update resolves an issue where the default appointment view wasn't consistently displayed. The previous code prioritized a Gantt view, overriding the intended list view. The fix removes unnecessary code calls to ensure the list view is used by default, while still allowing customization through Odoo's studio interface.
Original PR description
Steps to reproduce ================== - Install web_studio,appointment - Go to Appointment > Schedule > Staff Bookings - Open studio - Click on Views > List > Set As Default - Exit studio - Refresh the page => The list view is not used by default Cause of the issue ================== The action is overriden in python in order the have the gantt view first. Solution ======== insert_reorder_action_views is called for three actions and all of them already contains the inserted views in the correct position. We can thus remove calls to it. By default, it will be as intended, and if someone wants to change the order with studio, it will be possible. opw-4969903
A recent update to WhatsApp functionality within the Odoo Enterprise platform has been fixed. Specifically, an error occurred when users without WhatsApp access attempted to view conversations, preventing them from seeing messages. This fix ensures all users can access and view WhatsApp conversations correctly.
Original PR description
As we refactored the scale driver, we need to update the checksum. see odoo/odoo#239695
This update ensures compatibility with standard CSS by requiring custom property values to use interpolation. Previously, older versions of the Sass compiler allowed full SassScript expressions, which created inconsistencies with CSS. This change aligns with industry best practices and improves the overall stability of our design tools.
Original PR description
Older versions of LibSass and Ruby Sass parsed custom property declarations just like any other property declaration, allowing the full range of SassScript expressions as values. But this wasn’t compatible with CSS. To provide maximum compatibility with plain CSS, since version 3.5.0, LibSass requires SassScript expressions in custom property values to be written within interpolation. Reference: https://sass-lang.com/documentation/breaking-changes/css-vars/
This update fixes an issue with the IoT Box's driver download process. Previously, enabling a setting allowed it to download standard drivers, leading to potential conflicts and duplicated files. Now, the system avoids downloading standard drivers from standard modules to prevent these issues and ensure stability.
Original PR description
The stable IoT Box uses drivers from git repository: it doesn't download them from the database as it used to do. However, sh/on premise clients might want to develop custom drivers that the IoT Box would download. For that, they have to enable a checkbox on the IoT homepage, making the IoT Box download handlers as before. The issue is it will also download standard drivers that are already present on the IoT Box: on newer databases it would simply overwrite them, but on older ones, it would duplicate as names might have changed. Also, it would introduce issues back that were already fixed. To avoid this, we avoid adding drivers from standard modules to the downloaded archive, to prevent issues with the main ones. Forward-Port-Of: odoo/enterprise#105770 Forward-Port-Of: odoo/enterprise#105531
This update fixes an issue where the Follow-Up Report displayed incorrect amounts for reconciled entries. Now, the report accurately shows the remaining balance (residual amount) for each entry, ensuring accurate reporting and financial analysis. This improves the reliability of financial data presented to users.
Original PR description
Currently, when viewing the followup report with reconciled entries, we display full amounts instead of the residual amounts. task-5868881 Forward-Port-Of: odoo/enterprise#105507
This update corrects a technical issue where order documents weren't being properly updated in the l10n_mx_edi module. By forcing a write-date update, the system now accurately reflects the document's status, ensuring data consistency and compliance. This resolves a previous limitation in how documents were identified for updates.
Original PR description
Before the commit 8b118a7, the search of the documents to update has been limited and ordered. With the actual domain the records to update will be most of the time the same because is not being updated. To fix this issue we force to update it. OPW-5368047 Forward-Port-Of: odoo/enterprise#105282 Forward-Port-Of: odoo/enterprise#103272
This update fixes a discrepancy in Odoo's Balance Sheet reports for certain localized versions (CO, EC, KR, TW, and ZM). It ensures that 'Other Expenses' are correctly included in the 'Unallocated Earnings' calculation, providing a more accurate financial overview. This was caused by a previous update that didn't properly integrate this new expense type into the localization reports.
Original PR description
*= co, ec, kr, tw, zm Currently, the `Other Expense(expense_other)` account type, introduced in saas-18.3, is missing from the Balance Sheet reports of certain `localizations`, even though it's…
*= co, ec, kr, tw, zm Currently, the `Other Expense(expense_other)` account type, introduced in saas-18.3, is missing from the Balance Sheet reports of certain `localizations`, even though it's correctly implemented in the standard reports. **Steps to reproduce:** - Install the `l10n_co_reports` and `accountant` modules. - Switch to `CO company `and navigate to Accounting > Reporting > Balance Sheet. - Ensure the `report` smart button is set to `Balance Sheet (CO)`. - Equity > Previous Years Unallocated Earnings and click the `info icon`. - Observe the formula of `balance_domain`. **Observation:** The formula does not include the `expense_other` account type. **Root Cause:** After PR [1], at [2] `expense_other` was added to the Previous Years Unallocated Earnings balance domain only in the main `account_reports` module. The corresponding localization reports mentioned above were not updated accordingly, resulting in incomplete Balance Sheet formulas. **Fix:** This commit updates the Balance Sheet report and includes the `expense_other` account type in the Previous Years Unallocated Earnings balance domain, aligning them with the standard reports. [1]: https://github.com/odoo/enterprise/pull/101591 [2]: https://github.com/odoo/enterprise/blob/316a5965e5fae83bd7d901929160c87eb28d13cf/account_reports/data/balance_sheet.xml#L205 opw-5491639 Forward-Port-Of: odoo/enterprise#105852 Forward-Port-Of: odoo/enterprise#105262
This update ensures document discoverability settings (like public or private access) are consistently maintained when moving documents within the system. Previously, moving a document could unintentionally change its visibility based on the destination folder's settings. The move confirmation dialog now clearly reflects this change, providing users with accurate information.
Original PR description
This commit improves the handling of a document's discoverability setting (`is_access_via_link_hidden`) when it is moved between folders. Previously, when a document was moved, it would inherit the…
This commit improves the handling of a document's discoverability setting (`is_access_via_link_hidden`) when it is moved between folders. Previously, when a document was moved, it would inherit the discoverability setting from the destination folder. This could lead to unintended changes in a document's visibility. For example, a publicly discoverable document could become private (requiring a direct link) simply by being reorganized into a different folder. This behavior was inconsistent with a previous improvement that prevented discoverability from propagating downwards from a parent folder to its children. See PR-93697. With this change, a document's discoverability is now treated as an intrinsic property that is fully preserved when the document is moved. It is no longer affected by the settings of its destination folder. To ensure clarity for the user, the move confirmation dialog has been updated to reflect this new logic. It now correctly informs the user that the document's original discoverability setting will be maintained. Task-5159832 Forward-Port-Of: odoo/enterprise#105877 Forward-Port-Of: odoo/enterprise#97045
This update ensures that AI chat windows always appear above other dialog windows, improving user experience and making it easier to interact with the AI. Previously, dialogs were hidden behind chat windows, causing confusion. This change prioritizes the visibility of the AI chat feature.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Dialogs were rendered behind chat windows, making them difficult to see and interact with. **Current behavior before PR:** --------------------------------- - The dialog appears behind the chat window **Desired behavior after PR is merged:** ----------------------------------------- - Dialogs are displayed above all chat windows except AI - The AI chat window remains intentionally above dialogs **Task:** 5367135 Forward-Port-Of: odoo/enterprise#105789 Forward-Port-Of: odoo/enterprise#103076
Code cleanup and technical improvements
This update modernizes the process for sending Chilean Electronic Data Interchange (EDI) reports – invoices, factoring documents, and stock pickings – to government servers. Previously, these were automatically sent via a daily cron job. Now, invoices and factoring documents use a new Send & Print wizard, while stock pickings require manual sending. This change enhances efficiency and aligns with Odoo's current system.
Original PR description
`l10n_cl_edi` was written before `account_edi` was developed, as such, it doesn't actually rely on it's sending process for communicating with the SII and government servers. Nevertheless, it still…
`l10n_cl_edi` was written before `account_edi` was developed, as such, it doesn't actually rely on it's sending process for communicating with the SII and government servers. Nevertheless, it still uses a cron to automatically send the records on post rather than the more modern send & print system. This commit refactors the `l10n_cl_edi*` modules to utilize Send & Print where possible. Regression: Before, all Invoices, Factoring Documents, and Stock Pickings would be sent automatically and linked properly when the custom cron ran once a day. For invoices and factoring documents this is now accomplished via the Send & Print wizard, but for pickings since there isn't any Send & Print functionality, it must manually be sent now via the button on the form view. Note: I can't actually find any reason why `l10n_cl_edi` was depending on `account_edi`. It was added in a commit that added it to a lot of modules but never actually used for the sending process or any of the edi format/document code. As such there are no upgrade scripts necessary to migrate from the document system to custom fields. task-5190489
This update refactors how salary input data is identified in the payroll system, moving from using a numerical ID to a more descriptive key (name). This change enhances data accuracy and simplifies the process of defining salary components for employees, leading to more reliable payroll calculations.
12 changes
Enhancements to existing features
This update aligns the TDS XLSX report with the official utility format, ensuring accurate reporting for tax purposes in Russia. A key change is automatically retrieving partner information from AML records, which now correctly formats miscellaneous entries in the report. This improves data reliability and compliance.
Original PR description
This commit aligns the TDS XLSX report with the official TDS utility format. Additionally, We now fetch the partner from AML record, so even miscellaneous entries generate a correctly formatted XLSX sheet. task-5237518
Resolved issues and error corrections
This update fixes a previous issue where users with standard access rights couldn't open the documents application. The change restricts access to a sensitive field and limits visibility of certain features within the application to only system administrator users, ensuring proper access control and stability.
Original PR description
Internal Users with the "Access Rights" access right were not able to open the documents application, which raised an access error traceback on the `ai_sort_prompt` field - which has restricted access to only admins. The access error was raised because the `ai_sort_prompt` field was added to the search_panel_fields for users with Access Rights access rights. We changed it so it is only added when users have the document system adminstrator role. We also changed the document_service's start method to also define the documentSystem user which is the system adminstrator user. With that we could limit visibility of the System Prompt item in the cog menu to those users. task-5375110
This update streamlines the database synchronization process by removing outdated XMLRPC support and enhancing error handling. The changes improve stability and user experience by preventing errors from halting synchronization and providing clearer error messages.
Original PR description
### [IMP] databases: remove xmlrpc fallback for odoo.com Since odoo.com migrated to 19.0, it will always support the json2 API, and XMLRPC support will be dropped on the next version. In order to…
### [IMP] databases: remove xmlrpc fallback for odoo.com Since odoo.com migrated to 19.0, it will always support the json2 API, and XMLRPC support will be dropped on the next version. In order to simplify the code and avoid subsequent requests in case of errors on the json2 API, the XMLRPC fallback is stripped off from `databases.api`. In this commit, we only adapt the tests so that they don't test the fallback to XMLRPC when calling odoo.com. In the next commit, we will remove the dead code. The configuration parameter `databases.odoocom_apiuser` is removed, as well as the corresponding field in the Settings page. ### [FIX] databases: disable the KPI-selection wizard With this commit, we disable the wizard displayed at the end of a synchronization to select which KPIs are added to the properties field. Instead, we always store all the KPIs that are provided by the databases, and the users can still select which ones they want to display on the list view. The wizard is still used in the background for stable compliance, but it is not displayed to the user any more. It will be removed in the next stable version (saas~19.2). Task-id: [5868314](https://www.odoo.com/odoo/project.task/5868314) ### [FIX] databases: handle fetch errors better With this commit, fetching errors like 502 Bad Gateway are handled better, as they are reported as an error message in the final summary instead of interrupting the whole synchronization and showing a traceback to the end user. ### [FIX] databases: synchronize up to immediate_sync_limit databases synchronously Previously, if the number of databases to be synchronized exceeded `databases.immediate_sync_limit`, no databases were synchronized synchronously. Instead, all were queued for a triggered scheduled action. With this commit, the synchronization process will handle up to `immediate_sync_limit` databases synchronously, while the remaining databases will be sent to the scheduled action.
This update corrects a technical issue preventing invoices from successfully validating with DIAN, Colombia's tax authority. The fix involved updating a specific tag format within the invoice XML files to match DIAN's requirements. This ensures invoices are properly processed and avoids validation errors.
Original PR description
Problem: When validating invoices with DIAN, an error is received. Cause: Incorrect tags are being used in the invoices. These tags are checked when invoices are validated with DIAN. Solution: Use the correct tags in the invoices. schemeName should be used instead of scheme_name. Steps to reproduce: - Install l10n_co_dian module - Choose a Colombian company - Activate DIAN service in Settings - Create an invoice and send it while making sure the DIAN checkbox is ticked - Download the generated zip file and uncompress - Open the XML file and check for scheme_name. It should be replaced by schemeName. opw-5829958 Forward-Port-Of: odoo/enterprise#105659
This update fixes an issue where the system incorrectly blocked automatic reconciliation when an invoice's reference matched its payment reference. Now, the system correctly identifies and matches invoices with their corresponding payments, streamlining the accounting process. This change was driven by a user report and ensures accurate reconciliation.
Original PR description
The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference. It also…
The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference. It also modify a docstring of a test because it was lying about what it was really testing. The usecase it says it forbid is actually enforced by `test_matching_algorithm_for_multiple_invoices`. Before this commit: - functionally: The obvious matching was denied and the accountant had to manually make the match. - technically: The `aml.ref` and the `move.payment_reference` were the exact same and thus postgres regrouped the invoice (through aml) with itself as if there were 2 invoices matching the same word. After this commit: - functionally: The obvious match is made. - technically: The initial intend was to avoid having several invoices (proxy by amls) reported for a specific matching word preventing the system to take a difficult and arbitrary functional decision which might be wrong. In order to comply with that and to not block the match of an invoice that would be matched through several matching words, we don't gather twice the same aml for the same word. task-id: None (The issue arose on odoo.com and was brought by APFA) Forward-Port-Of: odoo/enterprise#105648
This update fixes a misclassification of account 649 in the French Profit and Loss report. The change aligns with French accounting standards (PCG 2025 & 2026) by correctly categorizing this account within Wages and Salaries and Social Security Charges. This ensures accurate financial reporting for French businesses using the Odoo Enterprise system.
Original PR description
## Issue In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"*…
## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).
## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
- *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
- *Wages and salaries*: **649 is not mentioned**
- *Social security charges*: **649 is not mentioned**
## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.
opw-5724559
Forward-Port-Of: odoo/enterprise#105856
Forward-Port-Of: odoo/enterprise#105474This update addresses a small technical issue where a missing space in a route caused a problem with the account online synchronization process. This fix ensures the synchronization feature functions correctly, preventing potential disruptions to data synchronization.
Original PR description
During this forward port: https://github.com/odoo/enterprise/commit/a5b9372ca0b23151046c14c9a8ead0ed9cd46b80 there was a missing space in the route. no task id Forward-Port-Of: odoo/enterprise#105849
This update hides potentially confusing channel commands (like `/help`) from website visitors and guests. Previously, these commands were visible even though they didn't function for non-users. This change enhances the user experience and prevents accidental actions by guests, improving overall website security.
Original PR description
**Before PR:** channel commands like `/help ` or `/leave` and more are visible to visitors or guest even it is not functional for them. **After PR:** all commands are now hidden from visitors/guests. task-4548666 Forward-Port-Of: odoo/enterprise#105380 Forward-Port-Of: odoo/enterprise#82963
This update fixes an issue where changing the Payment Partner in the accounting system didn't consistently save the new selection. The fix removes a restriction that prevented the system from properly updating the Payment Partner record, ensuring changes are saved and reflected after refreshing the record.
Original PR description
**Steps to reproduce:** 1. Install Accounting. 2. Go to Return Type. 3. Create a record and set a Payment Partner Bank. 4. Change the Payment Partner. **Issue:** Changing the Payment Partner creates a log entry but does not update partner on the selected Payment Partner Bank. After refreshing the record the value is reverted to the previous partner. **Cause:** The field payment_partner_id is defined as `readonly` at the model level. As a result, when the ORM attempts to update this field, the write operation is silently ignored. Although the field appears editable in the view due to `readonly="0"`, model-level `readonly=True` still prevents the value from being saved. **Fix:** Make the field writable at the model level so that ORM updates are persisted, This ensures that changes to Payment Partner are properly saved and no longer reverted after refresh. **opw-5423029**
This update corrects a technical issue in the Datev export functionality for tax groups with children. Previously, the system incorrectly accessed the parent tax group instead of the child groups, leading to inaccurate data. This fix ensures that Datev exports correctly represent tax groups and their associated children.
Original PR description
Issue: Before this commit, when a tax type is group and has children, we access the parent, even though the dict has only the children Fix: as a solution, we map through the originated tax list received from the compute all function opw-5480918 opw-5874567
This update fixes a potential issue where Stripe account creation would fail intermittently, leading to duplicated accounts. It now ensures the Stripe account is always set correctly, even if subsequent steps fail, and sanitizes URLs to prevent errors when requesting Stripe account information. This improves the overall reliability of the expense tracking feature.
Original PR description
## [FIX] hr_expense_stripe: Fix account duplication Add a transaction commit when the account is created, to ensure that even if any further action fails the stripe account is properly set on the company. This will prevent users from creating accounts every time if the account creation part succeeded ## [FIX] hr_expense_stripe: Sanitize values for webhook url Sometimes the web.base_url is the http version of the database url, where the https is properly setup. At account creation we test the https connection, and allow the creation of the account forcing https on IAP side. But when we request the links for the account, the database will still send the http version of the url, refused by stripe. This adds a sanitization of the URLs on the database side
This update resolves an issue where the input field within the campaign test dialog would disappear when cleared. The fix adds a configuration to ensure the field correctly displays, preventing users from needing to close and reopen the dialog to use it. This improves the user experience for campaign testing.
Original PR description
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: -…
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: - The input area has disappeared. Now, the only way to get it back is by closing the dialog and reopening it Cause: - Field `resource_ref` uses `hide_model: True`, and when cleared, the widget has no value and no model selector to determine the target model because of the function `getRelation` that now returns `undefined`, by this XML fails to render the `<Many2OneField/>` https://github.com/odoo/odoo/blob/7680b83501cef18362be38f90715d824f2bf9cd6/addons/web/static/src/views/fields/reference/reference_field.js#L107-L119 Solution: - Add `model_field: model_id` option to the view so the widget can resolve the model from the `model_id` field even when input is empty Note: - This behavior also occurs in other places. After discussion with the framework team, we agreed to keep the scope of this PR limited to marketing_automation, as this is not a priority issue. A broader fix can be addressed in the master if needed. opw-5473320 Forward-Port-Of: odoo/enterprise#104547
15 changes
Resolved issues and error corrections
This update fixes a technical error that could occur when changing invoicing policies after a sales order was created and the user who created it was deleted. The change ensures the system correctly handles scenarios where the original user's information is no longer available, preventing a traceback and maintaining proper functionality.
Original PR description
Steps to reproduce: 1. Create a new user in the database 2. Create a new sales order as the new user 3. Add an order line where the product is of type "Service" and has an invoicing policy of "Based on Timesheets" 4. Confirm the sales order 5. Sign out of the new users account and sign in as admin 6. Delete the newly created user 7. Go into Settings > Timesheets > Invoicing Policy 8. Attempt to change the policy to "Validated timesheets only" 9. Save your changes 10. Observe the traceback The `if` statement would trigger if any record in the recordset had a `create_uid`, which would cause a traceback if the first record in the recordset happened to not have a `create_uid`. This can occur if the user who created a given sale order is deleted from the database. This change will ensure that the function correctly falls back to the currently signed in user if the sale order create_uid doesn't exist. opw-5868538
This update fixes an issue in version 17 where paid event registrations automatically confirmed after a sale, leading to incorrect notifications and a less effective attendee editor. Now, registrations remain in 'draft' mode until attendee details are entered, ensuring notifications go to the correct recipient and maintaining administrative control.
Original PR description
Problem: - In version 17, event records linked to a sales order can be automatically set to ‘open’ immediately after the sale. This makes the wizard editor less useful (the data provided is not used…
Problem: - In version 17, event records linked to a sales order can be automatically set to ‘open’ immediately after the sale. This makes the wizard editor less useful (the data provided is not used for the record that is already confirmed) and notifications go to the sales partner instead of the actual assistant. Current behaviour: - Confirmed orders automatically confirm attendees, reducing the value of the wizard step and sending emails to the wrong recipient. Expected behaviour: - Paid attendee registrations created from Sales should remain in “draft” until attendee details are provided. Solution: - Do not set ‘state=“open”’ for payment records created from a sale involving the data wizard for records. Ensure they remain in “draft”. - Confirm registrations once attendee details are present. Advantages: - Restores the usefulness of the attendee editor: confirmation occurs after data entry, so notifications are directed to the attendee, not just the sales partner. - Meets functional expectations for administrative control and proper recipient targeting. Tests to reproduce the error: - Create quote with payment entry - Confirm SO - Enter attendee details and confirm - Registrations change to ‘open’ and a confirmation email is sent to the order partner and not to the registered attendee. @Tecnativa TT58160 @pedrobaeza please review --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230500
This update resolves an issue where modifying the quantity of a subcontracting receipt after a BOM change resulted in incorrect stock move line quantities. The fix skips a redundant check, ensuring accurate quantity updates are applied when a BOM is modified post-PO creation.
Original PR description
**Issue** In subcontracting, if a BOM is modified after the creation of a PO, then modifying the move quantity of the associated receipt can lead to inconsistency between move and move line…
**Issue** In subcontracting, if a BOM is modified after the creation of a PO, then modifying the move quantity of the associated receipt can lead to inconsistency between move and move line quantities. **Steps to reproduce** - Create a subcontracting BOM of a final product using 1 component product - Create a PO of the final product for a quantity of 10 and confirm it - Modify the BOM to use 2 component products instead - Go to the receipt of the PO and modify the quantity to 2 and validate it - Click on the move line of the receipt -> The displayed quantity is 10 instead of 2 **Cause** Setting the quantity triggers this line: https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/stock_move.py#L78-L78 which calls: https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/stock_move.py#L107 Since the BOM has been modified, a `consumption_issues` is detected and `_update_finished_move()` won't be called: https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/mrp_production.py#L86-L89 And since the returned action is not used when calling `subcontracting_record_component`, `_update_finished_move()` won't be called later neither, which is the method responsible for updating the move line quantities: https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/mrp_production.py#L142-L146 **Solution** Since the consumption issue actions are ignored in this case, just skipped it and avoid inconsistencies. opw-5493577 Forward-Port-Of: odoo/odoo#245065
This update corrects a bug where canceled refunds were incorrectly included in global invoices generated from Point of Sale (PoS) orders. The fix filters out canceled refund lines, ensuring that only valid refunds are reflected in the global invoice. This improves invoice accuracy and reporting for Mexican VAT compliance.
Original PR description
When generating global invoices for orders in the PoS, refund of those orders are also included in the global invoice. However, if the refund has been canceled, it should not be included in the global invoice. Steps to reproduce: ------------------- * Create a PoS order and validate it. * Go to the backend and create a refund for that order. * Cancel the refund. * Go to the PoS order list and select the original order * Click on "Generate Global Invoice" > Observation: The canceled refund is included in the global invoice. Why the fix: ------------ We simply filter out the canceled orders when searching for refunded order lines. opw-5492576
This update ensures that dates sent to ECPay (a payment gateway) are formatted correctly for Taiwan's time zone. Previously, dates were stored in UTC, leading to errors when ECPay searched for invoices. This fix resolves the issue, guaranteeing accurate invoice retrieval and preventing processing failures.
Original PR description
sending to ECPay The date store in Odoo is in utc format, we need to convert it to tw time when sending the date to ECPay. The APIs are using the date to search for the invoices, if the date is not correct, it cannot find the invoices and return error. task-5884616 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the carrier type selection box would become disabled after validating a mobile barcode. The fix ensures the carrier number input remains editable, allowing users to correctly select and input their carrier information during the order process. This improves the user experience and prevents data loss.
Original PR description
carrier type After the user clicks on "Validate" button to validate the mobile barcode, the carrier type selection is disabled and the carrier type pass to the SO is None. This commit fixes the issue by instead of disabling the carrier type selection, we just set the input box of carrier number to readonly and set back the carrier number to not readonly when the user changes the carrier type to ensure the carrier number input is editable. task-5880421 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previous issue where attendance overlaps weren't properly accounted for in hourly accrual plans. The change ensures that all worked time, including periods where an employee worked across multiple days, is correctly included in the accrual calculation. This improves the accuracy of time-off balances.
Original PR description
### Issue: Attendances overlapping on two days are ignored for hourly accrual plans based on attendances. ### Steps to reproduce: - Install 'hr_holidays_attendance' - In Time Off > Configuration >…
### Issue: Attendances overlapping on two days are ignored for hourly accrual plans based on attendances. ### Steps to reproduce: - Install 'hr_holidays_attendance' - In Time Off > Configuration > Accrual Plan, create a new plan - Based on worked time - Hourly rule - Attendances as Source - In Management > Allocations, create an allocation for an employee using the new accrual plan - Create an Attendance for this employee in the period of the Accrual Plan - Check-in at 22pm for example - Check-out at 7am - Run the cron "Accrual Time Off: Updates the number of time off" - The Allocation ignores the worked time from the attendance ### Cause: `_get_accrual_plan_level_work_entry_prorata()` is called on each day of the accrual period. So `start_dt` is `datetime.datetime(2026, 1, 2, 0, 0)` and `end_dt` is `datetime.datetime(2026, 1, 3, 0, 0)` for example. This means that the search will always excludes attendances overlapping on two days. https://github.com/odoo/odoo/blob/26f3026ed45cc409cd7f67fa219d44f1adbac9b7/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L79-L83 ### Solution: To count the attendances on several days, we need to split these attendances by day because `_get_accrual_plan_level_work_entry_prorata()` is only called with an interval of one day from midnight to midnight. First we get all attendances overlapping with the day by changing the domain in the search. Then we could simply take the difference between `max(attendance.check_in, start_dt)` and `min(attendance.check_out, end_dt)` but we also need to remove the lunch breaks (they were not counted in `attendance.worked_hours`). This would mean duplicating the code present in `_compute_worked_hours()`. To avoid this we create a new method for `hr.attendance` named `_get_worked_hours_in_range()`. That returns the number of hours worked due to this attendance in a given time frame. This new method can be used in both cases to get the needed value. opw-5172669
This update corrects a bug where the 'Today' filter in the Frontdesk module was incorrectly filtering visitors based on the user's local timezone. The fix converts all date/time values to UTC before querying the database, ensuring accurate filtering regardless of the user's location. This prevents visitors from being missed when check-in times are recorded in different timezones.
Original PR description
Steps to reproduce -------------------------- 1. Install Frontdesk 2. Go to Frontdesk → Visitors 3. Create a visitor with a check-in time before today 05:30 (local timezone: Asia/Kolkata) 4. Check visitors Issue: -------- The created record is not displayed because "today" filter used the user's local date to build a datetime range but failed to convert those boundaries to UTC before querying the database, leading to incorrect filtering in non-UTC time zones. Solution ------------- Convert those datetimes to UTC using `.to_utc()` in the filter domain opw-5385995 Forward-Port-Of: odoo/enterprise#102865
This update fixes an error where tax amounts were incorrectly identified as discounts in the MyInvois XML invoices generated for Malaysian e-invoices. The change ensures that tax-excluded amounts are used for discount calculations, aligning with Peppol Malaysia specifications and preventing inaccurate reporting. This ensures compliance with e-invoice standards.
Original PR description
The _add_consolidated_invoice_base_lines_vals method computed the gross subtotal using `price_unit * quantity`. When taxes are configured as "Included in Price", `price_unit` contains the…
The _add_consolidated_invoice_base_lines_vals method computed the gross subtotal using `price_unit * quantity`. When taxes are configured as "Included in Price", `price_unit` contains the tax-included amount, but `total_excluded` (used for the discounted amount) is tax-excluded.
This caused the tax amount to be incorrectly reported as an AllowanceCharge (discount) in the MyInvois XML, because:
discount_amount = price_unit * qty - total_excluded
= tax_included - tax_excluded
= TAX AMOUNT (not a discount!)
Example: Product priced at 110 MYR with 10% tax included:
- price_unit = 110 (tax-included)
- total_excluded = 100 (tax-excluded: 110 / 1.10)
- discount_amount = 110 - 100 = 10 ← incorrectly reported as discount
refs:
The cac:AllowanceCharge element in UBL is specifically for discounts and surcharges, NOT for taxes. According to the Peppol Malaysia e-Invoice specification:
https://docs.peppol.eu/poac/my/pint-my-sb/bis/#_allowances_and_charges
https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL5189/ (For this case we are interested in code 95)
Steps to Reproduce:
1. Configure a tax as "Included in Price" with Malaysia tax type
2. Create a product with that tax.
3. Create POS orders without any discount
4. Generate consolidated invoice and XML
5. XML incorrectly shows <cac:AllowanceCharge> with tax amount as discount
The fix uses `raw_total_excluded / discount_factor` (always tax-excluded) instead of `price_unit * quantity` (may be tax-included), consistent with the parent method:
https://github.com/odoo/odoo/blob/d645361a95037ac580d55e80bcb61d1eeb293efd/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1846-L1876
Ticket [link](https://www.odoo.com/odoo/project.task/5476526)
opw-5476526
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update ensures that WebGL testing continues to function correctly in Chrome's headless mode (version 144+). Chrome's default settings now disable WebGL, so this change re-enables it for testing purposes, specifically to maintain functionality for features like image filters in the website builder. While SwiftShader is less secure, it's deemed acceptable for controlled test environments.
Original PR description
Since Chrome 144 disabled [^1] by default the WebGL fallback to the software renderer SwiftShader, this commit reenables [^2][^3] it when running in headless mode to allow to keep testing WebGL features (i.e. image filters in website builder). Note: the SwiftShader implementation is considered deprecated and less safe than proper hardware based ones, hence not recommended for a regular usage with untrusted content. However, as tests are run in a more controlled environment, it looks reasonnable to opt-in to keep actually testing WebGL features. [^1]: https://chromium-review.googlesource.com/c/chromium/src/+/7128438 [^2]: https://issues.chromium.org/issues/476172421 [^3]: https://chromestatus.com/feature/5166674414927872 Forward-Port-Of: odoo/odoo#246289
This update resolves a confusion for users of the Odoo PEPPOL integration. Previously, the system used 'demo' for one setting and 'test' for another, creating inconsistency. This change ensures both settings are aligned, providing a clearer and more reliable experience for users.
Original PR description
Currently, the proxy_client_user is neutralized as demo. But the edi_mode is set to test. It's confusing for the users, and we should be consistent. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246181
This update corrects a previous issue where confirming one upsell on a subscription would leave other upsells in a pending state. Now, confirming any upsell automatically cancels all remaining upsells associated with that subscription, ensuring accurate order status and preventing unnecessary charges.
Original PR description
Currently, when creating multiple upsells for a specific subscription, confirming one of them leaves the others in the sent state instead of cancelling them. This fix ensures that all other upsells for the same subscription are cancelled once one upsell is confirmed. task-5270139 Forward-Port-Of: odoo/enterprise#100058
This update fixes an issue where the UrbanPiper store identifier field was visually overflowing its container. The changes include wrapping the field and button in a container with appropriate styling for a cleaner and more user-friendly display within the settings interface.
Original PR description
Before this commit: --- - The UrbanPiper store identifier field could overflow its container. After this commit: --- - Wrap the store identifier field and action button in a container. - Apply `overflow-hidden` and flexible width to the store identifier field. task-5472992
This update resolves an issue where vendor partner creation from XML vendor bills would fail if the 'Departamento' tag was missing. The fix ensures the system correctly handles cases where this tag is empty, preventing incorrect state detection and successful partner creation. This improves data accuracy and streamlines the process of importing vendor information.
Original PR description
If the xml file has a tag "Departamento" without a value, the vendor partner creation fails because the state is searched with an empty string and detects a state that is not correct because the xml has no state value. Task Adhoc side: 109004
This update resolves a bug preventing the correct Open Graph description from being generated for card campaigns. The issue stemmed from a mismatch in variable names between the controller and the template, resulting in an empty meta tag. The fix ensures the campaign's suggestion text is correctly passed, enabling proper social sharing functionality.
Original PR description
**Current Behavior:** description is not available for the Crowler <img width="1159" height="802" alt="image" src="https://github.com/user-attachments/assets/2979f413-6487-4f44-993c-b9a806e0d0ef" />…
**Current Behavior:** description is not available for the Crowler <img width="1159" height="802" alt="image" src="https://github.com/user-attachments/assets/2979f413-6487-4f44-993c-b9a806e0d0ef" /> **Steps to reproduce:** 1. Install `marketing_card` 2. Create a card campaign 3. Set Recipient, Post Link and Post Suggestion 4. Save and Preview 5. Copy the URL and replace `preview` with `redirect` 6. To reproduce in locale, in the `contoller` make the marketing_card.card_campaign_crawler template the only return 7. Now paste that URL in the browser **Issue** - The `<meta property="og:description">` tag is empty in inspect. It does not contain any content **Cause:** - The controller `card_campaign_redirect` passes the campaign's suggestion text to the view using the key `post_text`. However, the template `card_campaign_crawler` attempts to access `post_suggestion`, which is not present in the rendering context. **Solution:** - Update the controller to pass `post_suggestion` opw-5351041
9 changes
Enhancements to existing features
This update adjusts the NSSF (National Social Security Fund) contribution limits in the Odoo Enterprise system to align with the latest regulations in Kenya. Specifically, the lower and upper earnings limits for Tier 1 and Tier 2 contributions have been revised, impacting the maximum combined contribution amount.
Original PR description
This commit updates the NSSF Lower and Upper Earnings Limits in accordance with the 4th year of implementation of the NSSF Act 2013. - Set Lower Earnings Limit (Tier 1) to 9,000. - Set Upper Earnings Limit (Tier 2) to 108,000. - Resulting max combined contribution is now 6,480. Task: 5485002
This update implements a new report for Italian businesses, fulfilling the requirement to generate VAT Registry reports as mandated by Italian tax regulations. This report provides the necessary data for accurate VAT reporting, ensuring compliance and reducing the risk of penalties.
Original PR description
Implementation of the VAT Registry report for the Italian localization. task-5248065
Resolved issues and error corrections
This update fixes an issue where unstable network connections could cause incorrect attendance records to be created. The fix includes a timeout for location updates and prevents multiple check-in/out attempts, ensuring accurate attendance data and a smoother user experience. It addresses a potential source of data errors.
Original PR description
when using signInOut with geolocation, slow or temporarily unavailable network connections could cause getCurrentPosition to hang indefinitely (default timeout is infinite). This led to: - Frontend…
when using signInOut with geolocation, slow or temporarily unavailable network connections could cause getCurrentPosition to hang indefinitely (default timeout is infinite). This led to: - Frontend not updating, allowing multiple clicks and creating duplicate attendance entries - Incorrect check-in/check-out data __Steps to reproduce:__ 1. check in while online and server reachable 2. disconnect network or make server unreachable 3. check out Currently, getCurrentPosition would hang indefinitely. till the network is restored. then it will trigger the rpc call much later than the action time. in the meantime, the user could click multiple times, creating multiple attendance records. With this fix, getCurrentPosition will timeout after 10 seconds, then it will proceed without position. and if the server is unreachable, it will show an error notification without allowing multiple clicks. __FIX__ - Adds a timeout to getCurrentPosition - Uses a `_attendanceInProgress` flag to prevent multiple clicks - Ensures only the first callback (success or error) triggers the RPC opw-5414044
This update fixes a rounding issue that occurred when invoicing in foreign currencies. Previously, tax calculations were imprecise, leading to discrepancies between printed invoices and accounting records. The change ensures taxes are rounded to 2 decimal places before conversion, guaranteeing accurate financial reporting and reconciliation.
Original PR description
This test shows that with `round_globally` set and invoices in foreign currency, tax amounts are not correctly rounded to 2 decimal places before conversion, causing differences between printed…
This test shows that with `round_globally` set and invoices in foreign currency, tax amounts are not correctly rounded to 2 decimal places before conversion, causing differences between printed invoice amounts and actual postings. **Description of the issue/feature this PR addresses:** When invoicing in a foreign currency (e.g. USD), and using the global tax rounding method (round_globally), the system calculates taxes using more than 2 decimal places in the foreign currency. For example, a 0.2% perception on a 124 USD invoice is calculated as 0.248 USD instead of 0.25 USD. While the printed invoice rounds it correctly, the internal accounting uses the unrounded amount, which after currency conversion (e.g. FX = 1066.50) results in discrepancies (e.g. 2.13 TEST difference in this case). T**hese rounding inconsistencies:** Accumulate over time across invoices. Cause mismatches between printed documents and accounting records. Create issues in supplier reconciliations and tax reports. **Current behavior before PR:** Taxes in foreign currency are computed with excessive precision (e.g., 0.248 USD instead of 0.25). The rounding is not applied before converting to the company currency. Causes accounting and fiscal inconsistencies. **Desired behavior after PR is merged:** Taxes in foreign currency are rounded to the correct number of decimals (e.g., 2) before conversion to company currency. The posted amounts in the company currency match the rounded foreign currency values, avoiding residuals and discrepancies. Ensures printed invoice amounts align with posted journal entries, maintaining consistency for both partners and fiscal reports. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a printing issue where DIN5008 expense reports displayed a duplicate title. The change adds a required field to the expense report data, ensuring the report title matches the standard 'Expenses Report' format, resolving the duplication and improving report consistency.
Original PR description
Issue: Expense title is duplicated when printing an expense report for localizations using the DIN5008 standard. Steps to reproduce: - Install German localization - Create a new expense report - Print the expense report PDF -> Title is duplicated Cause: DIN5008 reports tries to load a specific field `l10n_din5008_document_title` in their header and fallbacks to report's name With this commit, we add a bridge module to add the field `l10n_din5008_document_title` to `hr.expense.sheet` and set it to 'Expenses Report`, therefore the header will have 'Expenses Report' as title, like in the standard expense report. opw-4314414
This update enhances the Odoo editor's table functionality by allowing users to select rectangular ranges of cells when using Shift + arrow keys. Previously, selections were made one cell at a time. Now, the editor behaves more like Google Docs, providing a more intuitive and efficient way to select and edit data within tables.
Original PR description
Current behaviour before commit: -In table, when pressing shift + any arrow key, cells are selected one by one, not rectangularly. Desired behaviour after commit: -If no cell is selected then pressing shift + any arrow key selects current cell. -When there is one or more cells are selected, pressing shift + any arrow key expends cells rectangularly relative to the arrow key directions just like gdoc. task-3442805 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue (a 'runbot' bug) that was preventing the checkout tour from running correctly. The fix includes adjustments to the selection of Latin American identification types and a pause to ensure the checkout page loads fully, improving the tour's reliability.
Original PR description
This PR fixes a runbot bug happening in the tour test of `test_checkout.js`, by: 1. fixing selection of latam identification and obligation types. 2. adding a step waiting for the checkout page. runbot-233703
This update resolves an issue where work centers remained blocked after a work order was deleted. The fix ensures that the timer and associated productivity data are stopped when a work order is removed, preventing incorrect work center availability. This improves the reliability of our manufacturing scheduling.
Original PR description
Steps to reproduce: - Start the timer on the work order - Delete the work order - Try to block the work center Current behavior: - The work center is not blocked because the latest mrp.workcenter.productivity is still active Expected behavior: - The work center is blocked - mrp.workcenter.productivity is stopped opw-5475227
This update corrects a technical error in the Odoo Enterprise software related to service product packaging. The previous packaging type reference was invalid, preventing proper EDI processing. This fix ensures service products are correctly packaged for tax and regulatory compliance.
Original PR description
Update the xmlid for the default packaging type for service products, the previous one `l10n_ke_edi_oscu.packaging_type_ou` seems to have never existed. opw-5220129