Daily updates from Odoo
Wednesday, November 5, 2025
20 changes · master
Resolved issues and error corrections
The journal audit report now correctly shows the detailed tax grid breakdown again, including the separate plus and minus columns. This fixes missing tax information that could make audit review and tax reconciliation harder for accounting teams.
Original PR description
During the removal of tax tag signs, the detail of the tax grids has been removed and both columns `+` and `-` have been removed by mistake. Forward-Port-Of: odoo/enterprise#98499
The Auto Transfers option in Accounting settings now points to the correct underlying module after a module rename. This means users can enable the feature from settings and have it install as expected instead of silently remaining unchecked.
Original PR description
### Steps to reproduce: - Install "account_accountant" - Go in the settings - Search for "Enable Auto Transfers", tick the option - Save - The option is not ticked ### Cause: This option is supposed to install the module for Account Transfers. The option field is called `module_account_auto_transfer`. It's supposed to install the module `account_auto_transfer`. But this module was [refactored in 19.0](https://github.com/odoo/enterprise/commit/77c248981c9e1ccbb5d4c88a0915a231f040df84) and renamed `account_transfer`. So the settings can't find the module to install, nothing happen, and the option stays the same. ### Solution: Give the variable the correct name: `module_account_transfer`. opw-5149342 Forward-Port-Of: odoo/enterprise#97513
The automated SAT status check for Mexican electronic invoices now rotates through eligible documents instead of repeatedly checking the same first batch. This helps ensure imported posted invoices are all reviewed for possible SAT portal cancellations, improving reliability for companies with larger invoice volumes.
Original PR description
Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return…
Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return l10n_mx_edi_documents that have been imported from somewhere and whose invoice has been posted. This is because Odoo needs to always checked the value of the originator of an EDI document, in case it has been cancelled from the SAT Portal for instance.
Both `state = 'invoice_received'` and `'move_id.state = 'posted'` are mostly fixed value. The state needs to stay `invoice_received` as Odoo needs to always check the originator document's value. And once an invoice is posted, it's stays as so except in the case of cancellation.
This leads to an issue when the database contains more than 100 documents that are both `invoice_received` and `move_id.state = 'posted'`. In this case, the cron `_fetch_and_update_sat_status` will always process the same 100 documents. Once the limit of 100 is reached, the cron retriggers itself before terminating. Then on the next execution, the search call with the domain coming from `_get_update_sat_status_domain` will return the same 100 documents again.
This commit fixes this issue by ordering the documents in the cron method by `write_date asc`. Even if the SAT value of the documents does not change, the `write_date` should be updated as their is still a write that is triggered via `_update_document_sat_state`. This prevents the cron from always processing the same documents over and over again.
Forward-Port-Of: odoo/enterprise#97928
Forward-Port-Of: odoo/enterprise#93205The checkout process now handles external tax calculation errors more gracefully for Brazilian sales. Customers will no longer see an endless loading state when tax data or address validation fails, helping them continue or understand what needs to be corrected.
Original PR description
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with…
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with infinite loading. Examples include missing NCM codes or IAP service failures due to invalid addresses. **Steps to Reproduce** 1. Install Brazilian localizations (l10n_br, l10n_br_avatax, l10n_br_edi). 2. Configure Avatax Transfer API credentials (API ID and Key). 3. Create a website with a Brazilian company. 4. Add a product to the cart and proceed to checkout. 5. Choose a delivery method and observe that the UI gets stuck loading. **Root Cause** The `_order_summary_values` method in `website_sale_external_tax` called `_get_and_set_external_taxes_on_eligible_records()`, which could raise exceptions (e.g., IAPServerError). These exceptions were not handled, so they propagated to the frontend as generic RPC errors. The frontend has no built-in mechanism to display these exceptions as user-friendly messages, resulting in infinite loading. **Fix** Wrap the external tax calculation in `_order_summary_values` and catch `UserError`. Instead of letting the exception propagate as a generic RPC error, attach the error message to the result dictionary under `external_tax_error`. This prevents the frontend from hanging while still making the underlying problem visible in the next checkout step, where validation errors are properly handled and shown to the user. Opw-5052078 Forward-Port-Of: odoo/enterprise#96213 Forward-Port-Of: odoo/enterprise#95045
VoIP ringtones now fully stop when a call ends, so they cannot be accidentally restarted with media controls on a keyboard or headset. This avoids confusing or disruptive sounds after calls are already finished.
Original PR description
Before this commit, users can resume "stopped" ringtones by pressing the Media Play/Pause key of their keyboard/headphones, even after the call has ended. After this commit, stopping the ringtone clears the audio source, effectively preventing it from being resumed. Task-5222704 opw-5186087 Forward-Port-Of: odoo/enterprise#98660
Knowledge users can now publish or unpublish website articles from the share panel and have that choice saved. This fixes a problem where the toggle reverted after saving, which could prevent intended content visibility changes from taking effect.
Original PR description
Recently, we changed how fields are loaded in view_widgets: instead of relying on invisible fields defined in the main XML view (e.g., `<field name="website_published" invisible="1"/>`), we now load…
Recently, we changed how fields are loaded in view_widgets: instead of relying on invisible fields defined in the main XML view (e.g., `<field name="website_published" invisible="1"/>`), we now load them using the view widget's field descriptions (see: odoo/enterprise@301f63597b0c21fef16a1941314ac95602c8f01f) In the `addFieldDependencies` method of `addons/web/static/src/model/relational_model/utils.js`, the system retrieves field descriptions and, by default, marks the loaded fields as readonly. Since the readonly attribute is not explicitly defined for the `website_published` field, it is automatically treated as readonly. As a result, when a record is saved, any changes made to readonly fields are discarded. This means updates to the `website_published` field are lost, preventing users from publishing or unpublishing an article via the share panel. Steps to reproduce the issue: 1. Install `website_knowledge` 2. Open an article in Knowledge 3. Click on the share button 4. Click on the toggle to publish the article 5. Save the article => The toggle is set back to its initial position. Proposed fix: We will update the field description for `website_published` to explicitly set it as not readonly. This will allow users to successfully publish and unpublish articles using the share panel. Task-5240915
Salary offer previews now calculate gross pay correctly when a contract template has no working hours set. The system uses the most relevant available working calendar instead of showing a zero gross salary, giving payroll teams and candidates more accurate offer information.
Original PR description
Reproduce: In debug mode go to Payroll > Employees > Offers > Create a new offer with a contract template that has no working hours. The gross salary shown in the Salary Simulation Preview is 0. Issue: If the version has no resource calendar, its working hours are 0. This sets the `work_time_rate` to 0, and when multiplied by the wage the gross becomes 0 as well. Fix: Prioritize the version’s resource calendar when available, otherwise fallback to the offer’s calendar, and finally to the company’s. task-5051509 Forward-Port-Of: odoo/enterprise#95041
Belgian accounting reports now assign the correct receivable and payable accounts to VAT-related partners and add reconciliation rules for VAT payments. This helps bank transactions match VAT closing entries more reliably, reducing manual follow-up during VAT settlement.
Original PR description
This commit sets AR and AP accounts of "FPS" and "Collection Center" partners with the 2 new added VAT accounts. Additionally, a new reconciliation rules that detects the partner and the communication and creates a counter entry. The partner "FPS" have been added to the VAT closing line for auto-reconciliation with bank transaction. task-5148985 Forward-Port-Of: odoo/enterprise#98224
Salary package offers created from the Offers list now receive a valid access token, so their links work reliably outside the system. This fixes a gap where manually created offers could generate invalid links, while also tightening access rules for offers tied to employees with user accounts.
Original PR description
- Go to Recruitment > Applications > All Applications. - Open an applicant form and click "Generate Offer". - Repeat a few times so that the "Offers" smart button shows a list view. - From the list…
- Go to Recruitment > Applications > All Applications. - Open an applicant form and click "Generate Offer". - Repeat a few times so that the "Offers" smart button shows a list view. - From the list view, click "New" to create an offer. - Compare both flows: * With "Generate Offer" button: the generated offer link has a valid token and works even in an incognito window. * With "New" button: the generated offer link has `token=False`, which leads to an invalid link. #### Issue In the first scenario, `action_generate_offer()` generates an `access_token` for the offer's link in `hr.applicant`. In the second scenario, no token was generated in `hr.contract.salary.offer`, so offers created via the "New" button end up with `access_token=False` in their links. #### Fix Add a compute to `access_token` in `hr.contract.salary.offer` to generate a token if there is no employee or if the employee on the offer has no linked user. #### Additional - Mark the field `access_token` as readonly. task-5051394
This fixes ESG carbon emission reporting so currency and unit values stay aligned when an emission factor changes. It helps users see accurate emission report details without stale or mismatched values.
Original PR description
The `currency` and `unit` fields on emitted emissions are supposed to be related fields on the emission factor. However, due to how the report combining accounting emissions and other emissions is implemented, they are not correctly updated when the factor is modified. This PR makes them computed fields and enable the "store" attribute en them. Despite there being no actual table to store data into, this allows us to do a round trip to the server to fetch the correct values. Forward-Port-Of: odoo/enterprise#98724
Project users can now create updates on budgeted projects without encountering an error. The fix keeps profitability information hidden when the user does not have access to the underlying data, preventing the project update form from breaking.
Original PR description
Currently an issue is generated when the project user tries to add a project update. Steps to produce an error: - Install the 'project_account_budget' module with demo data. - Log in with the demo…
Currently an issue is generated when the project user tries to add a project update.
Steps to produce an error:
- Install the 'project_account_budget' module with demo data.
- Log in with the demo user
- Go to Project and open the dashboard of the Home Construction project
- Click new »> error occurs
Error
```
QWebError
Error while rendering the template:
KeyError: 'revenues'
Template: project.project_update_default_description
```
This issue occurs due to:
- The reference commit [1] enhances the project update form description by enabling the display of profitability even without the sale timesheet.
- With commit [1], code was added to set the `profitability_values` to an `empty dictionary ({})` and `show_profitability` to `False` (see [2]) , since the demo user does not belong to the `project.group_project_manager` group (see [3]).
- In the `project_account_budget` module, the value of `show_profitability` is updated and set to True because the total_budget_amount is present in the project (see [4]).
- In the template `project_update_default_description` rendering, the `profitability` is accessed when `show_profitability` is `True`. However, since `profitability` is an empty dictionary, attempting to access the key will result in an error (see [4]).
This commit fixes the above issue by preventing the recalculation of `show_profitability`, as it is already set based on whether `profitability` data is available or not.
[1]: https://github.com/odoo/odoo/commit/e81af984aabe61defa0932b7890ab373fe3c8e2a
[2]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/project/models/project_update.py#L114-L126
[3]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/project/models/project_project.py#L1111-L1112
[4]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/project/views/project_update_templates.xml#L26-L31
Sentry-6915109069,6981931420
Forward-Port-Of: odoo/enterprise#98441Self-order restaurant printing now includes the required IoT Box information when loading preparation printers. This helps kitchen or preparation orders print reliably through supported IoT connection methods.
Original PR description
Loading IoT preparation printers in self order was not providing the ID of the IoT Box record, required to print using both webrtc/longpolling/websocket. This commit fixes this issue by loading the whole device record, same as we do to load preparation printers in the regular pos. Forward-Port-Of: odoo/enterprise#98710
The signing confirmation dialog now has the right spacing and size after a document is signed. This fixes a visual issue introduced by a shared dialog behavior change, improving the post-signing experience for users.
Original PR description
Version: - master Steps to reproduce: - Upload a document. - Sign the document. - Notice that the “Thank You” dialog appears with incorrect margins. Issue: - After this [PR](https://github.com/odoo/odoo/pull/226581) was merged into the web module, the dialog component behavior changed medium-sized dialogs no longer include padding by default. Since the “Thank You” dialog is a medium dialog, it now appears with incorrect margins after signing a document. Solution: - Added a CSS class to fix the margin and adjust the dialog size. <img width="1570" height="789" alt="image" src="https://github.com/user-attachments/assets/4c6766df-6cc1-497a-9dcc-39a5f60054e1" />
The Journal Report now updates its Global Tax Summary values when users change the rounding unit. This keeps tax totals consistent with the rest of the report and avoids confusion from mixed number formats.
Original PR description
Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This…
Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This creates inconsistency where main report values update correctly but tax summary values stay unchanged. Cause: - The issue occurs because `_format_column_values` method in `account_report.py` wasn't handling the special tax summary data structures (`tax_report_lines` and `tax_grid_summary_lines`) that store pre-formatted values. These structures need to be reformatted when rounding unit changes, but the formatting logic only covered standard report columns. Fix Applied: - Updated frontend (`filters.js`) to call `format_column_values_from_client` via `dispatch_report_action` instead of calling `format_column_values` directly. (this enables proper routing through the custom handler system) - Added `format_column_values_from_client` override in `JournalReportCustomHandler` that intercepts the formatting call and applies special handling for tax summary lines by adding logic to reformat `tax_report_lines` and `tax_grid_summary_lines` monetary fields using their `_no_format` counterparts. - The custom handler then delegates to the base method via `report.format_column_values_from_client()` to format standard columns. - Also added missing `_no_format` fields in `account_journal_report.py` for `base_amount` and `tax_amount` to enable proper reformatting. Forward-Port-Of: odoo/enterprise#98662 Forward-Port-Of: odoo/enterprise#94660
Several screens now use the current standard button styling instead of an outdated style that no longer works. This keeps action buttons visually consistent and avoids confusing or broken-looking controls for users.
Original PR description
*: account_budget,industry_fsm,l10n_pe_edi,mrp_workorder,sign `btn-default` doesn't exist anymore, this is a dead utility class. This commit changes it for `btn-secondary` task-5236550 Com PR: https://github.com/odoo/odoo/pull/234401
Payroll processing now handles payslips that have no detected issues without causing an error. This prevents interruptions when checking multiple payslips, making payroll validation more reliable.
Original PR description
When there are multiple payslip on which we call get_error_message, some may have no issues. In this case, it raises a traceback as issues is False. Introduced in https://github.com/odoo/enterprise/pull/94748 Forward-Port-Of: odoo/enterprise#98803
Authorized users who are not administrators can now settle due invoices as expected. The update ensures the required screens load correctly, removing an access-related blockage in the point-of-sale settlement flow.
Original PR description
Before this commit, a user without the "Role / Administrator" group could not settle invoices because the required views were not loaded. After this commit, the necessary views are properly loaded, allowing all authorized users to settle invoices as expected. opw-5138892 Forward-Port-Of: odoo/enterprise#98487
This update resolves an internal warning in the Hong Kong payroll integration by using the correct access-checking method. It helps keep payroll processing stable and reduces noise from build or validation checks without changing business workflows.
Original PR description
Use `check_access` instead build-error-233453 Forward-Port-Of: odoo/enterprise#98654
### Before: - While printing payslip previously if an employee do not have any bank linked we were not printing anything,. ### After: - If no bank account present we will use: Amount to be paid to [employee_name]: [amount] task- 5101235 Forward-Port-Of: odoo/enterprise#95125
Original PR description
### Before: - While printing payslip previously if an employee do not have any bank linked we were not printing anything,. ### After: - If no bank account present we will use: Amount to be paid to [employee_name]: [amount] task- 5101235 Forward-Port-Of: odoo/enterprise#95125
The settings page now makes it clearer that accounting can be configured for inventory loss and production locations, including a direct link and helper text. This helps users find the right configuration when managing periodic closing alongside perpetual inventory accounting.
Original PR description
Forward-Port-Of: odoo/enterprise#98289