Daily updates from Odoo
Thursday, February 19, 2026
185 changes
24 changes
Resolved issues and error corrections
This update optimizes the MPS report to handle large production schedules more efficiently. By reducing the amount of data fetched and minimizing unnecessary queries, the report now runs significantly faster and consumes less memory, preventing potential errors. This improves the overall responsiveness of the system for users generating these reports.
Original PR description
Problem: When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error. Solution: We…
Problem:
When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error.
Solution:
We will fetch only the necessary fields to reduce queries and memory usage and set prefetch_fields=False to further reduce memory usage.
Benchmarks:
Run locally on a dupe of customer's db.
Time/queries measured by requests to /get_mps_view_state Memory measured using memray on method get_production_schedule_view_state()
<table>
<tr>
<th rowspan="2"># of Production Schedules</th>
<th colspan="3">Before</th>
<th colspan="3">After</th>
</tr>
<tr>
<th>Time</th>
<th># of Queries</th>
<th>Memory usage</th>
<th>Time</th>
<th># of Queries</th>
<th>Memory usage</th>
</tr>
<tr>
<td>20</td>
<td>22.846s</td>
<td>1,379</td>
<td>882.0MB</td>
<td>8.046s</td>
<td>1,180</td>
<td>103.4MB</td>
</tr>
<tr>
<td>300</td>
<td>41.098s</td>
<td>6,297</td>
<td>1.0GB</td>
<td>43.694s</td>
<td>5,732</td>
<td>363.5MB</td>
</tr>
<tr>
<td>1000</td>
<td>N/A (MemoryError)</td>
<td>N/A (MemoryError)</td>
<td>>2GB</td>
<td>88.416s</td>
<td>22,629</td>
<td>1.1GB</td>
</tr>
</table>
Average memory usage reduction: 75%
opw-5225472
Forward-Port-Of: odoo/enterprise#106392This update resolves an issue where the version history comparison displayed incorrectly when using toggle blocks within Knowledge articles. The fix corrects a flaw in the HTML generation process, ensuring accurate comparisons are shown. This prevents potential confusion and ensures data integrity within the system.
Original PR description
There is an issue with the history dialog in very specific scenarios where a toggle (or any similar block) is involved, resulting in an incorrect "comparison" being displayed. How to reproduce: -…
There is an issue with the history dialog in very specific scenarios where a
toggle (or any similar block) is involved, resulting in an incorrect
"comparison" being displayed.
How to reproduce:
- create a new Knowledge article, and replace the title with a toggle block
- in the "content" section of the toggle, write a word, e.g. "word" in the
paragraph.
- exactly below the toggle block, write the exact same word ("word") in a
paragraph.
- save the article
- open the version history
- click on the oldest entry (there should be 2 of them), and click "view
comparison"
Issue:
- the paragraph below the toggle is not shown.
Technical explanation:
- There is an incomplete constraint in `generate_comparison`, which is related
to a trade-off (see `test_replace_nested_divs`), which was supposed to ignore
identical successive `opening` tags. However, it also ignores `closing` tags,
which it shouldn't do (it causes this issue).
- This issue produces invalid html which could also cause owl crashes (in
addition to the incorrect comparison), if embedded components were present in
the invalid html part.
task-5933410
Forward-Port-Of: odoo/odoo#249184This update resolves a minor issue where the website tour wasn't functioning correctly after the initial loading screen refreshed. By waiting for the loading screen to disappear before checking for the 'editor_enable' class, the tour now flows seamlessly for users. This ensures a smoother and more reliable experience.
Original PR description
When the iframe reloading starts, the builder can still have the class `editor_enable`, which breaks the flow of the tour, as the next step is waiting for that class, so we should wait for the loading screen to disappear first, and only then check for the `editor_enable` class. runbot-234504 Forward-Port-Of: odoo/odoo#245688
This update resolves an issue preventing some iPhone users (particularly the iPhone 13 Pro) from correctly focusing on barcodes when scanning. A temporary workaround – a zoom slider – has been implemented to address this limitation, ensuring consistent barcode scanning functionality across all mobile devices. This improves the mobile sales process by allowing users to reliably scan barcodes.
Original PR description
This commit resolves an issue where certain mobile devices with multiple lenses (notably iPhone 13 Pro) failed to focus on barcodes at close range. Since the Web API does not allow direct manual focus control in Safari iOS, a zoom slider has been added as a workaround to help the camera sharpen the image. Note: While Chrome on Android supports direct focus adjustment, this zoom-based solution provides a consistent fix for all mobile users. Steps to reproduce: * Open Odoo on Mobile * Go to Sale app * Create a new SO * Add a product * Select the barcode icon to open the modal * Try to scan a barcode (Object is near the phone) => Bug opw-5870885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249292
This update resolves an issue preventing standard payroll users from accessing the 'One-time payments' feature within Swiss company contracts. The fix allows payroll officers and managers to open this functionality, ensuring they can correctly manage elm transmissions. This improves usability for payroll operations.
Original PR description
Steps to reproduce: ------------------- 1. Install l10n_ch_hr_payroll_elm_transmission. 2. Switch to a Swiss company and create a new employee. 3. Create a new internal user with Payroll…
Steps to reproduce: ------------------- 1. Install l10n_ch_hr_payroll_elm_transmission. 2. Switch to a Swiss company and create a new employee. 3. Create a new internal user with Payroll Officer/Manager access. 4. Log in as that user, create a contract, and click on "One-time payments". Issue: --------- A Traceback with AccessError: ```You are not allowed to access 'Action Window' (ir.actions.act_window) records.``` Cause: ---------- https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/l10n_ch_hr_payroll_elm_transmission/models/hr_contract.py#L195 The code attempts to call `.read()` on an `ir.actions.act_window` record. Standard users typically do not have read access to window action records, resulting in an **AccessError** even if they have rights to the payroll data. Solution: ------------- Use [_for_xml_id](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L187) to return action content for the provided xml id in a safe way by doing [sudo](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L205) internally to bypass the access restriction. opw-5491467 Forward-Port-Of: odoo/enterprise#107628 Forward-Port-Of: odoo/enterprise#106598
This update resolves an issue where cron jobs would repeatedly fail after exceeding a timeout threshold. The fix ensures that the cron job counter is correctly reset after a timeout, preventing the job from getting stuck and failing indefinitely. This improves the stability and reliability of automated tasks within Odoo.
Original PR description
CronJobs timed_out_counter is not getting reset when reaching the CONSECUTIVE_TIMEOUT_FOR_FAILURE due to a transaction rollback. This commit introduces a fix to ensure only records with an actual…
CronJobs timed_out_counter is not getting reset when reaching the CONSECUTIVE_TIMEOUT_FOR_FAILURE due to a transaction rollback. This commit introduces a fix to ensure only records with an actual exception tuple pass through in method: 'method_direct_trigger'. Description of the issue/feature this PR addresses: When a cron job reaches the timeout threshold (timed_out_counter >= 3), method_direct_trigger crashes because the ListLogHandler filter matches log records that have exc_info = None. But the original filter only checked hasattr(lr, 'exc_info') which is true for all LogRecord objects. This caused a TypeError when attempting to unpack exc_info (None) on the next line, which rolled back the transaction and prevented timed_out_counter from being reset. Current behavior before PR: Clicking "Run Manually" on a timed-out cron (timed_out_counter >= 3) raises TypeError: cannot unpack non-iterable NoneType object, rolling back the transaction. The timed_out_counter is never reset, leaving the cron permanently stuck. Desired behavior after PR is merged: The filter correctly skips log records where exc_info is None (i.e., non-exception errors like timeouts). method_direct_trigger returns True, the transaction commits, and timed_out_counter is properly reset to 0. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248978
This update adjusts the size of the 'RedirectWarningDialog' in the Odoo web interface. Previously, the dialog was too large, consuming unnecessary screen space. This change ensures a cleaner and more user-friendly experience by aligning the dialog's size with established styling guidelines.
Original PR description
Currently `RedirectWarningDialog` are using `xl` size which is way too big for the content it displays. Dialog sizes were reviewed in commit[1], the RedirectWarning should follow the same styling. task-5477287 [1]: odoo/odoo@01741aa2619998078bd19aca848146ac75c027fc --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where clicking links to specific messages in chatter wouldn't highlight the message correctly. The fix removes a redundant check that was preventing the auto-highlight feature from working when the targeted message wasn't among the initial 30 loaded. This ensures message links function as expected.
Original PR description
PR #223362 removes the early return for checking the origin thread in `highlightMessage()` while PR #234659 adds it again through the FW ports of a fix intended for mailbox (which has not been needed from 19.0 onwards). Since the auto-highlight of message is triggered when the thread is 1st loaded, i.e. has loaded 30 most recent messages, if the targeted message to highlight is not in the loaded messages, then the `highlightMessage()` call would be mistakenly and silently ignored by this early return. This trigger of `highlightMessage()` is done only once, hence the failed attempt to highlight the message. This PR removes reliance on the origin thread. Steps to reproduce the bug: - Send more than 30 messages in a chatter. - Copy the first message link and paste it into the browser to go to the message as a highlighted one. - Thread doesn't jump to the targeted message. task-5929780 Forward-Port-Of: odoo/odoo#249062
This update adjusts the Swiss tax reports to accurately include account 2970, which represents the 'Annual profit or annual loss' account. The change ensures correct reporting for Swiss tax compliance. This fix resolves a discrepancy in the account selection process.
Original PR description
This recent commit: odoo/enterprise@d223f826eaafa3189846b555af16b240f91936ba changed the formula for `account_financial_report_line_ch_290_a_balance` from: ```py [('account_id.code', '>=', '290'),…
This recent commit:
odoo/enterprise@d223f826eaafa3189846b555af16b240f91936ba
changed the formula for `account_financial_report_line_ch_290_a_balance` from:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2991'), ('account_id.account_type', '!=', 'equity_unaffected')]
```
to:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2970')]
```
The main goal of the commit was to remove the unaffected earnings account from the CH reports. While doing so, the formula was also modified by replacing `account_id.code = 2991` with `account_id.code = 2970`.
However, since the condition uses the `<` operator, the account with `code = 2970` is not taken into account. Account `2970` is the last account that should be considered before `Annual profit or annual loss`. see:
https://github.com/odoo/odoo/blob/19.0/addons/l10n_ch/data/template/account.account-ch.csv#L106
Ticket [link](https://www.odoo.com/odoo/project.task/5387092)
opw-5387092
Forward-Port-Of: odoo/enterprise#102247This update fixes an issue where tables copied from the Knowledge editor were only partially copied, resulting in incomplete table structures when pasted elsewhere. The change ensures that tables are fully copied, regardless of whether the content is editable or locked, providing a consistent user experience. This improves the usability of the Knowledge feature for creating and sharing tables.
Original PR description
Problem: In Knowledge, when adding a clipboard block and inserting a table inside it, clicking on the copy button only copies the text inside the table instead of the full table structure. Cause: In `html_viewer`, the copy logic clones only the deepest selected node. In contrast, `html_editor` (via `clipboard_plugin`) copies the entire selection range. This difference causes inconsistent behavior between editable and locked content. Solution: Align the behavior by copying the full selection in `html_viewer`, ensuring tables and other complex structures are copied entirely and consistently. Steps to reproduce: - Open Knowledge. - Add a clipboard block. - Insert a table inside the block. - Lock the content. - Click the copy button. - Paste into any editable field. - Observe that only the text (not the table) is pasted. opw-5476320 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247930
This update resolves an issue where grouped tax reports were generating incorrect results when invoices included both positive and negative tax amounts. The fix ensures that all tax line amounts, including negative ones, are correctly considered during report generation, preventing errors and ensuring accurate tax reporting.
Original PR description
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous…
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the base lines of type entry which have a balance of the same sign as the tax line. Yet in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error. So now, the logic is only considering lines with the same sign to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'. We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined. Steps to reproduce: - Activate Cash Basis in the Settings - Create a tax based on payment - Create an invoice with two lines: - One with a negative amount, an income account and the created tax - One with a positive amount big enough to compensate the previous line, a different income account and the same tax - Confirm - Click "Pay", validate the payment - In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice - Reconcile it with the invoice - Accounting > Reporting > Tax Return - Select "Group By: Account tax" Ticket [link](https://www.odoo.com/odoo/project.task/5089790) opw-5089790 Forward-Port-Of: odoo/odoo#249099 Forward-Port-Of: odoo/odoo#239081
This update resolves an issue where grouped tax reports were generating incorrect results when invoices included both positive and negative tax amounts. The fix ensures that all tax lines, including those with negative balances (CABA moves), are properly considered during report generation. This improves the accuracy of tax reporting.
Original PR description
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous…
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the baselines of type 'entry' which have a balance of the same sign as the tax line. But in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error. So now, the logic of the only considering lines with the same sign is to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'. We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined. Steps to reproduce: - Activate Cash Basis in the Settings - Create a tax based on payment - Create an invoice with two lines: - One with a negative amount, an income account and the created tax - One with a positive amount big enough to compensate the previous line, a different income account and the same tax - Confirm - Click "Pay", validate the payment - In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice - Reconcile it with the invoice - Accounting > Reporting > Tax Return - Select "Group By: Account tax" Community PR: odoo/odoo#239081 Ticket [link](https://www.odoo.com/odoo/project.task/5089790) opw-5089790 Forward-Port-Of: odoo/enterprise#107707 Forward-Port-Of: odoo/enterprise#101601
This update corrects a visual inconsistency in Odoo's note-taking feature. Previously, checklists and bullet lists had different indentation levels, leading to a misaligned appearance. This change ensures all list types are consistently formatted for improved readability and a more polished user experience.
Original PR description
The checklist has different indents than bullet list and numbered list. It should not be the case. This commit removes the extra indent from checklist entries. Steps to reproduce: - Go to a "To do" note - Create a checklist with indented items - Create a bullet list with indented items => Both list were not aligned task-5916723 Forward-Port-Of: odoo/odoo#249149 Forward-Port-Of: odoo/odoo#247568
This update resolves an issue where tooltips would unexpectedly disappear when a user moved between a parent and child element within the Odoo interface. Previously, the tooltip would be terminated, now it persists as long as the user remains within the parent element's area. This ensures a smoother and more intuitive user experience.
Original PR description
Have a tooltip on a parent. Hover on a child of that parent. Now, leave the child but stay in parent. Before this commit, the tooltip would be killed and never respawn. After this commit, the tooltip is not even killed if we stayed within the parent's physical space. task-5346498 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#248857
A recent update to the appointment module caused installation issues due to a problem with how the system checks template data. This fix prevents errors during reinstallations by temporarily skipping the generation of invitation URLs, ensuring the module installs correctly. This resolves a previous installation failure.
Original PR description
Reinstalling the appointment module fails during mail template validation. ### Reproduction Steps 1. Install the `appointment_hr_recruitment` module. 2. Uninstall `appointment`. 3. Reinstall…
Reinstalling the appointment module fails during mail template validation. ### Reproduction Steps 1. Install the `appointment_hr_recruitment` module. 2. Uninstall `appointment`. 3. Reinstall `appointment`. → A template parsing error appears. ### Cause The global `request.env` is bound to the registry active at the start of the request. When reinstalling a module, this registry becomes stale and does not include the models being re-added. During installation, the `mail.template` model performs a test render to validate its XML data. One of the templates calls `_get_interview_invite_url`, which invokes a controller that looks up the `appointment.type` model using `request.env`. Because the registry is stale and does not contain this model, the lookup raises a KeyError and the installation fails. ### Fix Rationale Skip invite URL generation when `install_mode` is set to avoid using the stale `request.env`. opw-5898780 Forward-Port-Of: odoo/enterprise#107650
This update resolves an issue where DHL shipping rate calculations failed when requested for dates outside of DHL's business hours. Adding a 'next business day' flag ensures rates are accurately calculated, preventing errors and ensuring reliable shipping options for our customers. This addresses a previous error causing 'Product not found' issues.
Original PR description
Before this commit, there was an issue when trying to get the rates for DHL shipping late in the day. The issue happened because `plannedShippingDate` fell outside of the working hours. This commit adds the nextBusinessDay flag for the rating request to avoid the error. Error: ``` Product not found 996: The requested product(s) not available for the requested pickup date. Process ID associated for this transaction') ``` opw-5393684 Forward-Port-Of: odoo/enterprise#107153
This update clarifies the visibility of specific fields within the Belgian payroll and fleet modules. Previously, generic fields were consolidated across all countries, but this change restores the original design, keeping BE-specific fiscal logic contained within the Belgian module. This ensures accurate reporting and compliance for Belgian businesses.
Original PR description
This branch only hides BE-specific fields in l10n_be_hr_payroll_fleet (they remain defined/used there and are invisible for non‑BE companies). On master (19.3) those generic fields (can_be_requested, default_car_value) were refactored into hr_payroll_fleet so payroll+fleet consumers across all countries can use them; BE fiscal logic stays in l10n_be_hr_payroll_fleet task-5906656 Forward-Port-Of: odoo/enterprise#106456
This update resolves an issue where the onboarding tour incorrectly targeted disabled calendar slots in the yearly holiday calendar. The fix excludes 'disabled' calendar cells, ensuring the tour reliably selects the first available Thursday, regardless of the server date (specifically impacting years 2027/2028).
Original PR description
Before, the tour attempted to click the “first Thursday” by selecting the first .fc-day-thu element in the DOM. The yearly calendar sometimes renders an initial “empty”/disabled weekday cell (when Jan 1 is Fri/Sat/Sun), so the first .fc-day-thu can be a disabled slot with no actionable element. That makes firstChild de-facto empty and the tour fails (seen reproducibly when the server date is set to years like 2027/2028, for example). Excluding .fc-day-disabled makes the selector target the first real Thursday cell task-5930501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248275
This pull request reverts a previous change related to how contract templates were being generated. The issue stemmed from a problem with triggering compute fields, which wasn't a critical bug. This change ensures the contract template functionality is working correctly and will be addressed fully in the main version.
Original PR description
This reverts commit 1d5e75900c0326f7b5293ad4cdafcc32d0f662fc. The problem was due to compute fields not triggered. It'll be fixed in master as this is not really a bug. task-5948571 Forward-Port-Of: odoo/enterprise#107791
This update resolves an issue where payroll warnings weren't being properly reflected or updated within the Odoo system. The fix ensures that warning messages are now reliably displayed and can be updated, leading to more accurate and timely payroll reporting. This improves the reliability of financial data.
Original PR description
Forward-Port-Of: odoo/enterprise#107792
This update resolves a technical issue preventing notifications from the signature field. The notification service was missing a necessary declaration, causing an error. This fix ensures that signature field notifications are now correctly processed, improving the user experience.
Original PR description
The notification service is later used in this [method](https://github.com/odoo/odoo/blob/04f3473da52ec74f3955cadd58eb016537497d44/addons/web/static/src/views/fields/signature/signature_field.js#L120), but it was never declared so it was causing an error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248602
This update fixes a potential issue where global invoices sent from the POS in Mexico could fail due to timeouts when interacting with the SAT portal. Increasing the read timeout for these requests helps prevent duplicate invoice submissions and ensures accurate data transmission, improving the reliability of tax filing.
Original PR description
**Fix:** Increase the read timeout for POST requests to SW sapien PAC. It may prevent timeout issue when sending a global invoice from the POS with a lot of POS orders that could lead to duplicated documents on the SAT portal when retrying to send the global invoice again. opw-5347962 Forward-Port-Of: odoo/enterprise#107735
This update simplifies the accounting setup for Spanish businesses within Odoo. Previously, there were separate account configurations for sales within Spain, intra-community transactions, and exports. This change removes this unnecessary complexity, aligning with Spanish tax regulations and streamlining the accounting process. It ensures a more straightforward and accurate representation of financial data.
Original PR description
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#247543
This update resolves an issue where test runs were repeatedly generating unnecessary assets, slowing down the testing process. By adding a specific asset bundle to the pregeneration list, we've streamlined test execution and improved overall efficiency. This change ensures tests run faster and more reliably.
Original PR description
During tests runs, lazy loaded assets are generated on the fly, and eventually multiple hundred of times (i.e. +/- 150 times on runbot). This commit adds the `web_studio.studio_assets` bundle to the pregeneration list to avoid regenerating during tests runs. Forward-Port-Of: odoo/enterprise#107147
4 changes
Resolved issues and error corrections
This update enhances the accuracy of payment reference checks by tailoring validation to the bank account's country. Previously, a single check applied to all countries could lead to incorrect validations. Now, the system prioritizes country-specific formats, with a fallback to a standard check for unsupported countries, ensuring more reliable payment processing.
Original PR description
Currently, when initiating a payment, we check if the reference is a structured one by using `is_valid_structured_reference` which checks the validity of the structure accross all supported countries. This can lead to issues when it matches formats accepted by other countries but not the one of the bank account. With this commit, we replace this check by a call to a new function that checks the structure validity according to the country of the bank account, with a fallback to the generic check (ISO 11649) if the country is not supported. opw-5387269 Forward-Port-Of: odoo/enterprise#107589 Forward-Port-Of: odoo/enterprise#107116
This update resolves an issue where grouped tax reports were generating incorrect results when invoices included both positive and negative tax amounts. The fix ensures that all tax lines, including those with negative balances (CABA moves), are correctly processed, preventing report errors. This ensures accurate tax reporting.
Original PR description
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous…
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the baselines of type 'entry' which have a balance of the same sign as the tax line. But in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error. So now, the logic of the only considering lines with the same sign is to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'. We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined. Steps to reproduce: - Activate Cash Basis in the Settings - Create a tax based on payment - Create an invoice with two lines: - One with a negative amount, an income account and the created tax - One with a positive amount big enough to compensate the previous line, a different income account and the same tax - Confirm - Click "Pay", validate the payment - In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice - Reconcile it with the invoice - Accounting > Reporting > Tax Return - Select "Group By: Account tax" Community PR: odoo/odoo#239081 Ticket [link](https://www.odoo.com/odoo/project.task/5089790) opw-5089790 Forward-Port-Of: odoo/enterprise#107707 Forward-Port-Of: odoo/enterprise#101601
A recent update to the appointment module caused installation errors due to outdated data. This fix prevents a template validation failure during module reinstallation by skipping the generation of invitation URLs, ensuring smoother module updates.
Original PR description
Reinstalling the appointment module fails during mail template validation. ### Reproduction Steps 1. Install the `appointment_hr_recruitment` module. 2. Uninstall `appointment`. 3. Reinstall…
Reinstalling the appointment module fails during mail template validation. ### Reproduction Steps 1. Install the `appointment_hr_recruitment` module. 2. Uninstall `appointment`. 3. Reinstall `appointment`. → A template parsing error appears. ### Cause The global `request.env` is bound to the registry active at the start of the request. When reinstalling a module, this registry becomes stale and does not include the models being re-added. During installation, the `mail.template` model performs a test render to validate its XML data. One of the templates calls `_get_interview_invite_url`, which invokes a controller that looks up the `appointment.type` model using `request.env`. Because the registry is stale and does not contain this model, the lookup raises a KeyError and the installation fails. ### Fix Rationale Skip invite URL generation when `install_mode` is set to avoid using the stale `request.env`. opw-5898780 Forward-Port-Of: odoo/enterprise#107650
This update resolves an issue where DHL shipping rate calculations failed when requested late in the day. Adding a 'next business day' flag ensures rates are accurately determined, preventing errors and ensuring reliable shipping calculations. This improves the overall shipping process for our customers.
Original PR description
Before this commit, there was an issue when trying to get the rates for DHL shipping late in the day. The issue happened because `plannedShippingDate` fell outside of the working hours. This commit adds the nextBusinessDay flag for the rating request to avoid the error. Error: ``` Product not found 996: The requested product(s) not available for the requested pickup date. Process ID associated for this transaction') ``` opw-5393684 Forward-Port-Of: odoo/enterprise#107153
8 changes
Resolved issues and error corrections
This update resolves a minor issue with the testing of the ChatGPT command button within the Odoo Enterprise SaaS platform. The fix ensures the button's functionality is consistently tested, improving the reliability of the AI-powered features. This change focuses on internal testing and does not directly impact user experience.
Original PR description
community-https://github.com/odoo/odoo/pull/244478 task-5499625
This update resolves an issue where tooltips would unexpectedly disappear when a user moved between a parent and child element within the Odoo interface. Previously, the tooltip would be terminated if the user left the parent's area. Now, the tooltip remains active even when navigating within the parent element, improving the user experience.
Original PR description
Have a tooltip on a parent. Hover on a child of that parent. Now, leave the child but stay in parent. Before this commit, the tooltip would be killed and never respawn. After this commit, the tooltip is not even killed if we stayed within the parent's physical space. task-5346498 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#248857
This update resolves a technical glitch that was preventing the calendar tour from functioning correctly for users. The fix ensures the tour consistently displays and guides users through the holiday request process, improving the user experience. This was a minor issue impacting a specific test.
Original PR description
This fix adjusts the tour in `test_hours_time_off_request_calendar_view` as it was failing in some cases. runbot error 237682
This update fixes an issue where the default putaway strategy wasn't consistently applied in stock transfers. Specifically, it ensures the correct child location is used as the default destination, improving the reliability of stock movements. This change ensures products are routed to the intended storage locations.
Original PR description
Steps to reproduce ----- - Enable locations & by products - Create 4 locations - View A of type view (parent: Stock) - View B of type view (parent: Stock) - Storage A of type internal location…
Steps to reproduce ----- - Enable locations & by products - Create 4 locations - View A of type view (parent: Stock) - View B of type view (parent: Stock) - Storage A of type internal location (parent: View A) - Storage B of type internal location (parent: View B) - Create a "Manufacture to A" route - Rule 1: Manufacture, Stock -> Stock - Rule 2: Push To, Internal Transfer, Stock -> View A - Create a "By Products to B" route - Rule 1: Push To, Internal Transfer, Stock -> View B - Create a "Bonus" product with route "By Products to B" - Create a "Finished" product with route "Manufacture to A" - BoM with "Bonus" as by product - Create a MO for Finished, and produce it - Open the linked transfers' list view - Open the "Bonus" transfer > "Destination Location" states View B - Open the line's details (hamburger button) > "Store To" states View A/Storage A Cause ----- When retrieving the location in https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L280-L282 we pass `locations` as a context key. The problem is that `locations` contains the childs of **all** of the SMLs' locations https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L260 This means that, in `_get_putaway_strategy`, when no `putaway_location` is found, we end up defaulting to the first element of the list https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L370-L371 which might not be a child of the location. Solution ----- By removing the context key, locations get populated as such https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L328-L330 This is ok because we know the call to `_get_putaway_strategy` is made on a single record (`sml.move_id.location_dest_id`) so the default will correctly be a child of said location. ----- Ticket: opw-5359945 Forward-Port-Of: odoo/odoo#249262 Forward-Port-Of: odoo/odoo#247403
This update resolves an issue where DHL shipping rate calculations failed when requested for dates outside of DHL's business hours. Adding a 'next business day' flag ensures rates are accurately calculated, preventing errors and ensuring reliable shipping options for our customers. This addresses a previous technical problem impacting shipping functionality.
Original PR description
Before this commit, there was an issue when trying to get the rates for DHL shipping late in the day. The issue happened because `plannedShippingDate` fell outside of the working hours. This commit adds the nextBusinessDay flag for the rating request to avoid the error. Error: ``` Product not found 996: The requested product(s) not available for the requested pickup date. Process ID associated for this transaction') ``` opw-5393684 Forward-Port-Of: odoo/enterprise#107153
This update corrects a problem where the timesheet approval reminder email was sending to an outdated action. The action was updated as part of a larger change in 17.3 to consolidate previous week/month actions. This ensures the email now correctly triggers the approval process.
Original PR description
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in…
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461 Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45 The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198 opw-5890269 Forward-Port-Of: odoo/enterprise#107385
This update resolves an issue preventing early receipt printing with Italian fiscal printers, specifically addressing tracebacks related to data synchronization. The fix allows for basic receipt printing and now supports early printing functionality, ensuring accurate and timely receipt generation for Italian restaurants.
Original PR description
Fix 1: ------- Using the early receipt printing option leads to a traceback when using the italian fiscal printer. Steps to reproduce: ------------------- * Setup the italian fiscal printer for a…
Fix 1:
-------
Using the early receipt printing option leads to a traceback when using the italian fiscal printer.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: Traceback
Why the fix:
------------
Initially the traceback is related to trying to read `decimal_places` out of undefined. The current order doesn't have yet a currency.
To solve this initial issue we can just take the currency of the config if there's none on the order. The pos does not handle multicurrency so the order will always have the same currency as the config anyway.
After solving this part another issue would still happen. If the order was no sent to the kitchen yet. Such orders are not yet synced to the backend and do not have an id of type number. If the order had been send to the display.
This scenario was sending the printer, the data to print and with a successful print we were trying to sync data to the server with
```
await this.data.write("pos.order", [order.id], updateData);
```
which was triggering an error in `orm_services` with `validatePrimitiveList`.
> Invalid ids list: pos.order_4
If we try to reprint AGAIN the bill for some reason, we get another traceback. It's because the nb_print is now 1 and therefore we now try to print with
```
printResult = await this.fiscalPrinter.printContentByNumbers({
order: order,
});
```
which will try to split undefined here
```
this.receiptNumber = this.props.order.it_fiscal_receipt_number;
const dateParts = this.props.order.it_fiscal_receipt_date.split("/");
```
Those two last issues are solved by not syncing the data to the server when we simply print the bill early.
-------
-------
Fix 2:
-------
Currently the early printing option does not work as desired. The fiscal printer does not print the receipt.
Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: the printer stops in the middle of printing the receipt
Why the fix:
------------
The early receipt was trying to be printed as a fiscal document. However it cannot be considered as such.
We backport this fix that enables basic receipt printing and alter it to also work with early printing.
Fix being backported: https://github.com/odoo/enterprise/commit/b8fd13b802729ccee080ab14f2958d59f57d0f97
There are a few differences between the early receipt and the basic print, mainly the fact that prices need to be shown on the early receipt.
There are a few differences with the original commit. In the documentation of the printer, `printNormal` uses data and the original commit mixes between `data` and `message` so it is harmonized here.
opw-5387572
Results:
-----------
Basic receipt:
<img width="672" height="835" alt="image" src="https://github.com/user-attachments/assets/3de96523-22db-4a27-adbd-3464802604aa" />
Early receipt:
<img width="658" height="842" alt="image" src="https://github.com/user-attachments/assets/f6b7ab24-e27b-4deb-8d5f-1b0c41bb28f0" />
Forward-Port-Of: odoo/enterprise#106672
Forward-Port-Of: odoo/enterprise#105511This update resolves a potential issue where global invoices sent from the POS in Mexico could fail to send correctly, leading to duplicate documents being submitted to the SAT portal. Increasing the timeout for communication with the SAT portal (SW sapien) helps ensure invoices are successfully transmitted, improving the overall reliability of the invoicing process. This addresses a specific problem related to high transaction volumes.
Original PR description
**Fix:** Increase the read timeout for POST requests to SW sapien PAC. It may prevent timeout issue when sending a global invoice from the POS with a lot of POS orders that could lead to duplicated documents on the SAT portal when retrying to send the global invoice again. opw-5347962 Forward-Port-Of: odoo/enterprise#107735
2 changes
Resolved issues and error corrections
This update resolves an issue where DHL shipping rate calculations failed when requested for dates outside of business hours. Adding a 'next business day' flag ensures rates are accurately calculated, preventing errors and ensuring reliable shipping options for customers. This addresses a previous problem that resulted in unavailable product messages.
Original PR description
Before this commit, there was an issue when trying to get the rates for DHL shipping late in the day. The issue happened because `plannedShippingDate` fell outside of the working hours. This commit adds the nextBusinessDay flag for the rating request to avoid the error. Error: ``` Product not found 996: The requested product(s) not available for the requested pickup date. Process ID associated for this transaction') ``` opw-5393684 Forward-Port-Of: odoo/enterprise#107153
This update resolves an issue where users in the Invoicing and Banks security groups were unable to access certain basic reports. The change adds necessary security permissions, allowing these users to open and utilize key reports without encountering access errors. This ensures consistent reporting functionality for all user groups.
Original PR description
* Revert commit https://github.com/odoo/enterprise/commit/86c3c212bb79fbc2becac46f4d83b6f2fc381854 that introduced having Accounting features, menu items, and Account on invoice lines available for Invoicing users. * Allow Invoicing & Banks group to access basic reports * Backport missing access rights to properly open the reports without an access error. task-5925567 Forward-Port-Of: odoo/enterprise#107654
22 changes
Resolved issues and error corrections
This update resolves an issue where the 'Remove date filter' button on the Booking tab of the POS kanban view was not functioning correctly, causing a technical error. The fix ensures this button now works as expected, allowing users to manage their booking filters effectively.
Original PR description
Steps: - Install pos_appointment. - Open a POS session with bookings configured. - Open the Booking tab and click Remove date filter in the header. Issue: - A traceback occurs with `Invalid handler`. Cause: - The Remove date filter button’s onclick handler was not defined. Fix: - Define a valid onclick handler for the Remove date filter button. Task-5902656 Forward-Port-Of: odoo/enterprise#107633 Forward-Port-Of: odoo/enterprise#106684
This update resolves an issue where embedded videos were not visible within shopfloor work order instructions. The fix re-applies a previous change that was inadvertently lost during a recent system update. Now, users can view video instructions directly within the shopfloor interface, improving training and operational clarity.
Original PR description
Issue ----- Embedded videos are not displayed in the shopfloor. Steps to reproduce ----- - Create a BOM with at least one operation - Create an instruction in the work order operation - In the instruction text, add a video link - Create a MO and plan it - Open the work order in shopfloor - Open the instruction > Empty window, no video Cause ----- Fix of 61fdab3 got lost in some refactor, so reapplying the logic. ----- Ticket: opw-5926557 Forward-Port-Of: odoo/enterprise#107538
This update fixes a calculation error in the Saudi HR payroll system. Previously, employees resigning after less than two years received a negative value for their end-of-service benefit, which was incorrect. The change ensures that these employees receive a zero value, aligning with Saudi regulations.
Original PR description
purpose: In the saudi eos rule, if the employee resigned after working in the company less than 2 years, their end of service is being computed as a negative value when it should be 0 instead. - added the correct check for the case of employee resignation - moved the logic of the salary rules for EOS benefit and provision from python methods to the rule itself to be more clear for the user task-id: 5499646 Forward-Port-Of: odoo/enterprise#107251 Forward-Port-Of: odoo/enterprise#104466
This update resolves an issue where customer display URLs weren't consistently being sent to IoT devices when records were updated. The change ensures that the correct URL is transmitted, improving the functionality of the IoT integration. This was a critical fix impacting data synchronization.
Original PR description
This PR fixes the customer display url not being sent to the iot box when updating the corresponding record in iot device form view. By replacing onWillSaveRecord by onRecordSaved we ensure that our method is always called ticket-5782927 Forward-Port-Of: odoo/enterprise#107174 Forward-Port-Of: odoo/enterprise#106331
This update ensures that screenshots taken during the trial mode of Odoo Enterprise capture the correct end-result data. Previously, the system lacked the database URL needed to fetch the final data, now it forwards the URL to ensure accurate screenshots are generated.
Original PR description
During the trial flow, we don't know the db url when making the ws request. To still be able to take screenshots of the end result in trial mode, we forward the db_url when getting the result back. Forward-Port-Of: odoo/enterprise#107034
This update resolves a bug that was causing errors during record creation within the Australian Payroll module. The fix avoids using a temporary ID (NewId) in search queries, ensuring proper record functionality and stability. This improves the reliability of payroll processing.
Original PR description
The generic `TestEveryModel` fails because a virtual ID (NewId) is used in a search domain during record creation, causing a crash. This commit uses `.ids` with the `'in'` operator to idiomatically handle virtual records and prevent the framework error. runbot-115303 Forward-Port-Of: odoo/enterprise#107644
This update corrects a bug where the 'CFDI to Public' checkbox was incorrectly checked when creating new invoices in the Mexican accounting module. The fix ensures this checkbox remains unchecked unless a customer is selected, preventing potential compliance issues. This change improves the accuracy of invoice generation for Mexican businesses.
Original PR description
Steps to produce: --- - Install `l10n_mx` and `accountant` modules. - Switch to a Mexican company. - Go to Accounting > Customers > Invoices. - Click on New to create a new invoice. Issue: --- - The `CFDI to Public` checkbox is automatically checked even when no customer is selected. Root cause: --- - Here at [1], the field l10n_mx_edi_partner_address_complete evaluates to False when no partner is set. - Due to the OR condition, this causes l10n_mx_edi_cfdi_to_public to be set to True, even though no partner has been selected yet. Solution: --- - We should only evaluate partner address completeness when a partner is explicitly set. - Also, add VAT check for `l10n_mx_edi_partner_address_complete`, as requested by mial(PO). [1] https://github.com/odoo/enterprise/blob/cc00e8f3bb75b8c782fea3a42ad3bbcdbc240e2f/l10n_mx_edi/models/account_move.py#L649 opw-5911542 --- Forward-Port-Of: odoo/enterprise#106943
This update resolves a memory error that occurred when calculating averages and standard deviations for quality checks. By limiting the data fetched and disabling a prefetcher, the system now handles larger datasets more efficiently, preventing crashes and improving performance. The changes resulted in a significant reduction in memory usage during testing.
Original PR description
Before this commit, computing the `standard_deviation` and the `average` of a `quality.point` involved fetching all the quality checks and all their fields. This can cause a memory error because of the field called `notes` that might involve HTML code. To avoid this, I have disabled the prefetcher since we only need two fields for the computation (`x_quality_state` and `measure`). The benchmark done below involved a recordset of quality points of size 1000 and the average size of the `notes` field was 6MB. The recordset was ordered by the size of the note section descending and for the different test cases it was sliced by the $K$ top elements and the compute function was triggered on the sliced version. | Scenario | Before | After | | :--- | :--- | :--- | | 100 | Memory LIMIT | 289.0MB | | 200 | Memory LIMIT | 290.0MB | | 500 | Memory LIMIT | 292.0MB | | 1000 | Memory LIMIT | 331.0MB | Forward-Port-Of: odoo/enterprise#106493
This update fixes an issue where VoIP calls weren't properly handled when a client was already busy. The previous approach was unreliable, leading to missed calls. This change ensures calls are correctly transferred and managed, improving the overall user experience.
Original PR description
task-4917399 <details><summary>old diagrams</summary> <p> ```mermaid sequenceDiagram actor EC as External Caller participant VC as VoIP Carrier participant PX as Proxy Provider participant OD as Odoo…
task-4917399
<details><summary>old diagrams</summary>
<p>
```mermaid
sequenceDiagram
actor EC as External Caller
participant VC as VoIP Carrier
participant PX as Proxy Provider
participant OD as Odoo DB
participant PS as Push Notification Server
participant SW as Service Worker of Marc's Android Phone
actor MD as Marc Demo
participant PWA
EC -->> VC: INVITE
VC -->> PX: INVITE
PX -->> OD: WebHook /voip/new-call
OD -->> PS: Push Notification
OD -->> PX: Dial Marc Demo, if not available play ringback
PX -->> VC: 183 RINGING EARLY MEDIA
PS -->> SW: Notif is received
SW -->> MD: Display Notif
MD -->> SW: Answer call
SW -->> PWA: Open PWA window
PWA -->> PX: REGISTER
PX -->> PWA: OK
PWA -->> SW: Ready
SW -->> PWA: User action is Answer
PWA -->> OD: Resend INVITE
OD -->> PX: For current call, dial MD
PX -->> PWA: INVITE
PWA -->> PX: ANSWER
```
## Scenario: Client Ready and Not Busy
```mermaid
sequenceDiagram
actor A as Alice
participant T as Telnyx
participant I as Odoo IAP
participant O as Odoo Server
participant F as Google FCM
participant S as Service Worker
%% participant R as SW Registration
participant W as WebClient
%% actor B as Bob
A -->> T: Call +3281123456
T -->> O: call.initiated
O -->> O: create voip.call
O -->> F: notify
F -->> S: notify
O -->> T: OK 200
S -->> W: post message
W -->> O: ready to receive call invite
O -->> I: Transfer to Bob
I -->> I: inject api key
I -->> T: Transfer to Bob
T -->> W: SIP INVITE
```
### Alternative Idea: use bus ws?
(is this doable?)
```mermaid
sequenceDiagram
actor A as Alice
participant T as Telnyx
participant I as Odoo IAP
participant O as Odoo Server
%% participant S as Service Worker
%% participant R as SW Registration
participant W as WebClient
%% actor B as Bob
A -->> T: Call +3281123456
T -->> O: call.initiated
O -->> W: bus.message: ready?
W -->> O: yes
O -->> I: Transfer to Bob
O -->> T: OK 200
I -->> I: inject api key
I -->> T: Transfer to Bob
T -->> W: SIP INVITE
```
</p>
</details>
### 20251110
```mermaid
---
title: Base Scenario
---
sequenceDiagram
actor A as Alice
participant T as Telnyx
participant O as Odoo Server
participant S as Service Worker
participant W as WebClient
actor B as Bob
A ->> T: Call +3281123456
T ->>+ O: call.initiated
O ->> O: create voip.call
O ->>- T: OK 200
par Blind Transfer
O -->> T: Transfer to Bob (through IAP)
%% T ->>+ O: Transfer Session Hangup (reason: not found)
%% O ->>- T: OK 200
and Notification Push
O -->> S: notify (through FCM)
S ->> S: display notification
end
opt Receive invite at first transfer
T ->> W: SIP INVITE (+header X-Odoo-Call-ID)
end
opt Decline
alt From Softphone
B ->> W: interact with softphone
W ->> T: SIP DECLINE
W ->> W: voip.call state = rejected
else From notification
B ->> S: interact with notification (decline)
S ->> O: decline call
O ->> O: voip.call state = rejected
O -->> T: Reject
end
T ->> A: Reject
end
opt Answer
alt From Softphone
B ->> W: interact with softphone
else From notification
rect rgb(220, 240, 255)
B ->> S: interact with notification
S ->> W: wake up WebClient
W ->> O: ready to receive call invite
O -->> T: Transfer to Bob (through IAP)
T ->> W: SIP INVITE (+header X-Odoo-Call-ID)
end
alt Manual
B ->> W: interact with softphone
else Automatic
W ->> W: AUTO_ANSWER
end
end
W ->> T: ANSWER
T ->> W: OK
A <<->> B: RTP Media
W ->> W: voip.call state = ongoing
end
%% alt Decline From notification
%% else Open from notification
%% B ->> S: interact with notification
%% S ->> W: wake up WebClient
%% W ->> O: ready to receive call invite
%% O -->> T: Transfer to Bob (through IAP)
%% T ->> W: SIP INVITE (+header X-Odoo-Call-ID)
%% opt Answer
%% alt Manual
%% B ->> W: ANSWER
%% else Automatic
%% W ->> W: AUTO_ANSWER
%% end
%% W ->> T: ANSWER
%% T ->> W: OK
%% A <<->> B: RTP Media
%% W ->> W: voip.call state = ongoing
%% end
%% end
```This change reverses a recent update that was causing all upsell quotes to be canceled, disrupting legitimate business processes. The previous code incorrectly called a function that resulted in errors and prevented proper filtering of alternative quotes. This reversion restores the expected functionality.
Original PR description
…mmit/55b6bbe27cc31abcaee40cd4a196e087fdfd4ce5 This commit introduced an issue. All upsell quote were canceled and no filtering was done on "alternative quotes". As a result it could disrupt legit business flow. Moreover, action_cancel was called instead of _action_cancell which can lead to ValueError: Expected singleton as action_cancel can require single record sometimes. Forward-Port-Of: odoo/enterprise#107503 Forward-Port-Of: odoo/enterprise#107417
This update ensures that the preparation display in the backend accurately reflects changes when a POS order is cancelled or deleted. Specifically, related preparation orders and data are removed, maintaining data consistency and a more reliable view of order preparation activities.
Original PR description
**In this commit:** Ensure the preparation display UI is updated when a POS order is cancelled or deleted from the backend. - On order cancellation, the preparation display is refreshed accordingly. - On order deletion, related preparation orders, lines, and states are removed via notify call. Task-5373116 Related: https://github.com/odoo/odoo/pull/240523 Forward-Port-Of: odoo/enterprise#107734 Forward-Port-Of: odoo/enterprise#103052
This update resolves an issue preventing standard payroll users from accessing the 'One-time payments' feature within Swiss company contracts. The fix addresses a permission restriction that was incorrectly denying access to action records, ensuring payroll managers can now fulfill their duties. This improves usability for payroll staff.
Original PR description
Steps to reproduce: ------------------- 1. Install l10n_ch_hr_payroll_elm_transmission. 2. Switch to a Swiss company and create a new employee. 3. Create a new internal user with Payroll…
Steps to reproduce: ------------------- 1. Install l10n_ch_hr_payroll_elm_transmission. 2. Switch to a Swiss company and create a new employee. 3. Create a new internal user with Payroll Officer/Manager access. 4. Log in as that user, create a contract, and click on "One-time payments". Issue: --------- A Traceback with AccessError: ```You are not allowed to access 'Action Window' (ir.actions.act_window) records.``` Cause: ---------- https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/l10n_ch_hr_payroll_elm_transmission/models/hr_contract.py#L195 The code attempts to call `.read()` on an `ir.actions.act_window` record. Standard users typically do not have read access to window action records, resulting in an **AccessError** even if they have rights to the payroll data. Solution: ------------- Use [_for_xml_id](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L187) to return action content for the provided xml id in a safe way by doing [sudo](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L205) internally to bypass the access restriction. opw-5491467 Forward-Port-Of: odoo/enterprise#107628 Forward-Port-Of: odoo/enterprise#106598
This update simplifies and stabilizes the pivot table autofill feature, addressing previous complexity and bugs. The new approach uses data within the pivot table itself to determine the next cell to populate, resulting in a more reliable and user-friendly experience. This change improves the overall performance and stability of the spreadsheet edition.
Original PR description
The current implementation of the pivot autofill is very complex, and very buggy. This commit rewrite it completely. We will now use the cells of the pivot table to get the next pivot cell to autofill, insteaf of complex logic based on the pivot definition. Task: [5913563](https://www.odoo.com/web#id=5913563&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
This update resolves an issue in the Swiss tax reports (l10n_ch_reports) by adjusting the account selection criteria. Specifically, it ensures that account 2970 is now correctly considered before 'Annual profit or annual loss,' aligning with Swiss accounting standards. This ensures accurate reporting for Swiss businesses.
Original PR description
This recent commit: odoo/enterprise@d223f826eaafa3189846b555af16b240f91936ba changed the formula for `account_financial_report_line_ch_290_a_balance` from: ```py [('account_id.code', '>=', '290'),…
This recent commit:
odoo/enterprise@d223f826eaafa3189846b555af16b240f91936ba
changed the formula for `account_financial_report_line_ch_290_a_balance` from:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2991'), ('account_id.account_type', '!=', 'equity_unaffected')]
```
to:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2970')]
```
The main goal of the commit was to remove the unaffected earnings account from the CH reports. While doing so, the formula was also modified by replacing `account_id.code = 2991` with `account_id.code = 2970`.
However, since the condition uses the `<` operator, the account with `code = 2970` is not taken into account. Account `2970` is the last account that should be considered before `Annual profit or annual loss`. see:
https://github.com/odoo/odoo/blob/19.0/addons/l10n_ch/data/template/account.account-ch.csv#L106
Ticket [link](https://www.odoo.com/odoo/project.task/5387092)
opw-5387092
Forward-Port-Of: odoo/enterprise#102247This update resolves an issue where grouped tax reports were generating incorrect results when invoices included both positive and negative tax amounts. The fix ensures that all tax line balances are correctly considered, regardless of their sign, preventing report errors. This improves the accuracy of tax reporting.
Original PR description
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous…
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the baselines of type 'entry' which have a balance of the same sign as the tax line. But in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error. So now, the logic of the only considering lines with the same sign is to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'. We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined. Steps to reproduce: - Activate Cash Basis in the Settings - Create a tax based on payment - Create an invoice with two lines: - One with a negative amount, an income account and the created tax - One with a positive amount big enough to compensate the previous line, a different income account and the same tax - Confirm - Click "Pay", validate the payment - In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice - Reconcile it with the invoice - Accounting > Reporting > Tax Return - Select "Group By: Account tax" Community PR: odoo/odoo#239081 Ticket [link](https://www.odoo.com/odoo/project.task/5089790) opw-5089790 Forward-Port-Of: odoo/enterprise#107707 Forward-Port-Of: odoo/enterprise#101601
This update resolves an issue preventing the generation of P9 reports (tax documents) in the Kenya payroll module, specifically for versions 19.0 and above. The fix removes an outdated employee PIN field reference, ensuring the report can now correctly generate PDFs. This ensures accurate tax reporting for Kenyan employees.
Original PR description
Bug reproduction: When version >= 19.0, install Kenya payroll and accounting, create payslip for one of the Kenyan employee -> validate the payslip -> Reporting: P9 Report in payroll app -> Create…
Bug reproduction: When version >= 19.0, install Kenya payroll and accounting, create payslip for one of the Kenyan employee -> validate the payslip -> Reporting: P9 Report in payroll app -> Create new tax deduction card -> populate employees -> in the inside of the card: select employees and click to generate pdf -> it will not be generated
Bug cause:
1 - In cron parameters, context passed wrongly, it should take place in the clickable parameters
2 - After saas-18.4 in the migration, employee.l10n_ke_pin field is removed but this field still takes place in l10n_ke_tax_reduction_card_templates.xml and it gets error when the user clicks to generate PDF.
Bug solution:
1 - Fixing cron parameter passing
2 - Removing PIN of employee field from P9 report since it is not available anymore.
Testing: Unit test is written to check PDF's are generated for sure.
1 - Creating Kenya company, employees
2 - Creating payslip for employees and validate them
3 - Creating tax deduction card and generate declarations
4 - Checking PDF's are created
task - 5395267
Forward-Port-Of: odoo/enterprise#107744
Forward-Port-Of: odoo/enterprise#104816This update simplifies website template code by replacing an outdated method (`request.env`) with the standard `env`. This change ensures consistent behavior across all website templates and resolves potential issues with how the system tracks data dependencies, ultimately improving reliability.
Original PR description
Target: remove all request in models/files and view/files.
This update fixes an issue where incoming calls were incorrectly marked as 'rejected' when the system was already in a call. Now, incoming calls while a call is active will be marked as 'missed', ensuring accurate call tracking and preventing missed opportunities. This improves the reliability of our VoIP system.
Original PR description
Since [1], an incoming call while already in an active call makes sure a voip.call record is created, but its state is marked as "rejected" and it should be "missed" instead. This commit fixes that. [1]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e
A previous issue prevented the appointment module from reinstalling properly, resulting in errors during mail template validation. This update resolves the problem by skipping the generation of invitation URLs during the installation process, ensuring a smooth and successful module reinstallation.
Original PR description
Reinstalling the appointment module fails during mail template validation. ### Reproduction Steps 1. Install the `appointment_hr_recruitment` module. 2. Uninstall `appointment`. 3. Reinstall…
Reinstalling the appointment module fails during mail template validation. ### Reproduction Steps 1. Install the `appointment_hr_recruitment` module. 2. Uninstall `appointment`. 3. Reinstall `appointment`. → A template parsing error appears. ### Cause The global `request.env` is bound to the registry active at the start of the request. When reinstalling a module, this registry becomes stale and does not include the models being re-added. During installation, the `mail.template` model performs a test render to validate its XML data. One of the templates calls `_get_interview_invite_url`, which invokes a controller that looks up the `appointment.type` model using `request.env`. Because the registry is stale and does not contain this model, the lookup raises a KeyError and the installation fails. ### Fix Rationale Skip invite URL generation when `install_mode` is set to avoid using the stale `request.env`. opw-5898780 Forward-Port-Of: odoo/enterprise#107650
This update resolves an issue where DHL shipping rate calculations failed when requested for dates outside of business hours. Adding a 'next business day' flag ensures rates are accurately determined, preventing errors and improving the reliability of shipping estimates.
Original PR description
Before this commit, there was an issue when trying to get the rates for DHL shipping late in the day. The issue happened because `plannedShippingDate` fell outside of the working hours. This commit adds the nextBusinessDay flag for the rating request to avoid the error. Error: ``` Product not found 996: The requested product(s) not available for the requested pickup date. Process ID associated for this transaction') ``` opw-5393684 Forward-Port-Of: odoo/enterprise#107153
This update corrects a bug that prevented users from successfully testing new printer configurations within the Point of Sale module. The fix ensures that the printer's IP address is correctly updated when using the test printer button, resolving a previous error. This improves the reliability of the test functionality.
Original PR description
When creating a new printer and test it with the test printer button, it will cause an error because the field of the ip address in pos.printer has changed and it was not changed into the test button.
This update streamlines the way AI Documents sends notifications within Odoo. The team replaced a specific function call with a new, more efficient method, improving the underlying system. This change enhances the stability and performance of the AI Documents module.
Original PR description
This commit replaces the uses of `self.env["bus.bus"]._sendone()` by `_bus_send()` in the `ai_documents` module. Following https://github.com/odoo/enterprise/pull/90124#discussion_r2822278385
21 changes
Resolved issues and error corrections
This update resolves an issue where payroll warnings weren't being properly updated in the reporting dashboard. The fix ensures that warning messages are now accurately reflected, providing more reliable and up-to-date information for payroll reporting. This improves the accuracy of financial data.
This pull request reverts a previous change related to how contract templates were handled. The issue was a minor technical problem with how calculations were triggered, which wasn't a significant problem for users. This update ensures the contract template functionality is working correctly and will be addressed in the main version of Odoo.
Original PR description
This reverts commit 1d5e75900c0326f7b5293ad4cdafcc32d0f662fc. The problem was due to compute fields not triggered. It'll be fixed in master as this is not really a bug. task-5948571
This update resolves an issue where closing a POS session would trigger an error if the partner's address (street or postal code) was missing. Now, the system gracefully handles empty address fields, ensuring POS sessions can be completed without interruption. This improves the reliability of the German POS certification process.
Original PR description
Before this commit, if a POS order was created with a partner that had an empty street or postal code, the system would raise an error when closing the POS session. opw-5897334
This update adjusts the calculation for Swiss CH reports to accurately include account 2970, which represents the 'Annual profit or annual loss'. The previous formula excluded this account, leading to incorrect report data. This change ensures compliance with Swiss accounting standards.
Original PR description
This recent commit:
odoo/enterprise@d223f826eaafa3189846b555af16b240f91936ba
changed the formula for `account_financial_report_line_ch_290_a_balance` from:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2991'), ('account_id.account_type', '!=', 'equity_unaffected')]
```
to:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2970')]
```
The main goal of the commit was to remove the unaffected earnings account from the CH reports. While doing so, the formula was also modified by replacing `account_id.code = 2991` with `account_id.code = 2970`.
However, since the condition uses the `<` operator, the account with `code = 2970` is not taken into account. Account `2970` is the last account that should be considered before `Annual profit or annual loss`. see:
https://github.com/odoo/odoo/blob/19.0/addons/l10n_ch/data/template/account.account-ch.csv#L106
Ticket [link](https://www.odoo.com/odoo/project.task/5387092)
opw-5387092This update addresses a technical adjustment to the checksum associated with the l10n_eu_iot_scale_cert module. A recent bugfix in the underlying code required an update to ensure data integrity. This change is a routine maintenance task to maintain the security and reliability of the module.
Original PR description
Checksum needs to be updated as the code of the scale changed for a bugfix Community PR: https://github.com/odoo/odoo/pull/249295
This update fixes a discrepancy in accounting calculations within the l10n_mx_edi_pos module. Previously, the POS was not correctly loading necessary assets, leading to incorrect amounts compared to Python calculations. This change ensures accurate accounting for transactions processed through the POS in Mexico.
Original PR description
Before this commit, the needed assets were not correctly loaded in the POS, which caused the amounts to be different from the ones computed in python. opw-5935191
This update resolves an issue where Odoo was incorrectly including a UETR tag in ISO 20022 payment files, causing rejection by strict banks. The change ensures compliance with SEPA regulations, preventing errors and ensuring seamless payment processing for our European users. This improves compatibility with major banking systems.
Original PR description
In Odoo 18.0, when a user selects the pain.001.001.09 format (ISO 20022), Odoo systematically includes the <UETR> (Unique End-to-end Transaction Reference) tag for every transaction. While valid under the general ISO 20022 XML schema, the <UETR> tag is not authorized by the EPC (European Payments Council) within the standard SEPA Credit Transfer (SCT) Rulebook. Strict banks (e.g., UBS, German banks) reject the entire file with errors such as: "No child element is expected at this point" when an UETR is detected in a domestic or intra-SEPA flow. Task: 5871528 Forward-Port-Of: odoo/enterprise#105792 Forward-Port-Of: odoo/enterprise#105518
This update resolves a bug that was causing errors when creating payroll records. The fix prevents the system from relying on a temporary ID (NewId) in search queries, ensuring stable record creation. This improves the reliability of the Australian Payroll module.
Original PR description
The generic `TestEveryModel` fails because a virtual ID (NewId) is used in a search domain during record creation, causing a crash. This commit uses `.ids` with the `'in'` operator to idiomatically handle virtual records and prevent the framework error. runbot-115303 Forward-Port-Of: odoo/enterprise#107644
This update corrects a bug where the 'CFDI to Public' checkbox was incorrectly checked when creating new invoices in the Mexican accounting module. The fix ensures this checkbox remains unchecked unless a customer is selected, preventing unintended public disclosures of invoices. This improves data accuracy and compliance.
Original PR description
Steps to produce: --- - Install `l10n_mx` and `accountant` modules. - Switch to a Mexican company. - Go to Accounting > Customers > Invoices. - Click on New to create a new invoice. Issue: --- - The `CFDI to Public` checkbox is automatically checked even when no customer is selected. Root cause: --- - Here at [1], the field l10n_mx_edi_partner_address_complete evaluates to False when no partner is set. - Due to the OR condition, this causes l10n_mx_edi_cfdi_to_public to be set to True, even though no partner has been selected yet. Solution: --- - We should only evaluate partner address completeness when a partner is explicitly set. - Also, add VAT check for `l10n_mx_edi_partner_address_complete`, as requested by mial(PO). [1] https://github.com/odoo/enterprise/blob/cc00e8f3bb75b8c782fea3a42ad3bbcdbc240e2f/l10n_mx_edi/models/account_move.py#L649 opw-5911542 --- Forward-Port-Of: odoo/enterprise#106943
This pull request resolves an issue where the Odoo enterprise template inheritance fails due to an outdated XPath targeting a renamed button. The fix updates the XPath to correctly identify the 'Add as link(s)' button, restoring proper dialog rendering and preventing errors.
Original PR description
[FIX] ai_documents_source: fix xpath after button rename
There is an issue where the template inheritance fails with an
OwlError because the xpath targets a button containing the text
"Paste Link(s)", which no longer exists.
How to reproduce:
- open the SelectAddDocumentCreateDialog
- trigger the dialog rendering
- the view crashes with an Owl lifecycle error
Issue:
- the xpath contains(., 'Paste Link') cannot locate the element
- the button label was renamed to "Add as link(s)" in commit
a4ca17329d7c21be487a53c5e0b9afa39e6dad3a
- template inheritance fails and raises an OwlError
Resolution:
Update the xpath to correctly target the new button definition
("Add as link(s)") instead of the old label, preventing the
element lookup failure and restoring proper dialog rendering.
Task-5946396This change reverses a recent update that caused all upsell quotes to be canceled, disrupting business processes. The previous code incorrectly called a function that resulted in errors and prevented proper filtering of alternative quotes. This reversion restores the expected functionality.
Original PR description
…mmit/55b6bbe27cc31abcaee40cd4a196e087fdfd4ce5 This commit introduced an issue. All upsell quote were canceled and no filtering was done on "alternative quotes". As a result it could disrupt legit business flow. Moreover, action_cancel was called instead of _action_cancell which can lead to ValueError: Expected singleton as action_cancel can require single record sometimes. Forward-Port-Of: odoo/enterprise#107503 Forward-Port-Of: odoo/enterprise#107417
This update addresses a recent discovery that the SAT (Mexican tax authority) sometimes accepts accented characters in invoices. Previously, the system automatically removed accents to comply with SAT rules. This change temporarily allows the ‘É’ character, and further investigation is underway to determine the full extent of SAT acceptance of accented characters.
Original PR description
An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices. In recent months, it has become clear that the SAT…
An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices. In recent months, it has become clear that the SAT does accept accents sometimes. First with umlauts on the `ü` in October (PR #96043), then all umlauts in February (PR #106557). As this PR has found another accepted accented character `É`, it may be necessary to undo the original improvment entirely. The [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17, indicates that accented characters are maintained in legal names. At least, `Í` is allowed. At this point in time I only added the exception for `É`. Steps to reproduce are [on the ticket](https://www.odoo.com/mail/message/999357619), as it requires a real person's tax information. [opw-5915515](https://www.odoo.com/odoo/project.task/5915515) ---- *Edit: Miguel (mial) confirmed that names are not always sanitized, but that we expect them to be.* Forward-Port-Of: odoo/enterprise#107677
This update streamlines the AI Documents module by replacing a specific function call with a more efficient one. This change enhances the module's performance and stability, ensuring smoother operation for users. The update was made as part of a broader effort to optimize internal processes.
Original PR description
This commit replaces the uses of `self.env["bus.bus"]._sendone()` by `_bus_send()` in the `ai_documents` module. Following https://github.com/odoo/enterprise/pull/90124#discussion_r2822278385
This update resolves an issue where grouped tax reports were failing when invoices included both positive and negative tax amounts. The fix ensures that all tax lines, including those with negative balances (CABA moves), are correctly processed, preventing report errors. This ensures accurate tax reporting for all invoice types.
Original PR description
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous…
The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts. [A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the baselines of type 'entry' which have a balance of the same sign as the tax line. But in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error. So now, the logic of the only considering lines with the same sign is to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'. We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined. Steps to reproduce: - Activate Cash Basis in the Settings - Create a tax based on payment - Create an invoice with two lines: - One with a negative amount, an income account and the created tax - One with a positive amount big enough to compensate the previous line, a different income account and the same tax - Confirm - Click "Pay", validate the payment - In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice - Reconcile it with the invoice - Accounting > Reporting > Tax Return - Select "Group By: Account tax" Community PR: odoo/odoo#239081 Ticket [link](https://www.odoo.com/odoo/project.task/5089790) opw-5089790 Forward-Port-Of: odoo/enterprise#107707 Forward-Port-Of: odoo/enterprise#101601
This update resolves an issue preventing standard payroll users from accessing the 'One-time payments' section within Swiss company contracts. The fix allows payroll officers and managers to open wages, ensuring proper access to critical payroll data. This improves usability for key personnel.
Original PR description
Steps to reproduce: ------------------- 1. Install l10n_ch_hr_payroll_elm_transmission. 2. Switch to a Swiss company and create a new employee. 3. Create a new internal user with Payroll…
Steps to reproduce: ------------------- 1. Install l10n_ch_hr_payroll_elm_transmission. 2. Switch to a Swiss company and create a new employee. 3. Create a new internal user with Payroll Officer/Manager access. 4. Log in as that user, create a contract, and click on "One-time payments". Issue: --------- A Traceback with AccessError: ```You are not allowed to access 'Action Window' (ir.actions.act_window) records.``` Cause: ---------- https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/l10n_ch_hr_payroll_elm_transmission/models/hr_contract.py#L195 The code attempts to call `.read()` on an `ir.actions.act_window` record. Standard users typically do not have read access to window action records, resulting in an **AccessError** even if they have rights to the payroll data. Solution: ------------- Use [_for_xml_id](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L187) to return action content for the provided xml id in a safe way by doing [sudo](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L205) internally to bypass the access restriction. opw-5491467 Forward-Port-Of: odoo/enterprise#107628 Forward-Port-Of: odoo/enterprise#106598
This update ensures Odoo's Mexican payroll system accurately reflects the latest Social Security Law regarding minimum wage exemptions. Specifically, it adjusts calculations for IMSS, ISR, and subsidy contributions when employee earnings are at or below the minimum wage, streamlining XML generation and improving compliance. Existing tests have been updated to align with these changes.
Original PR description
According to the Mexican Social Security Law, when an employee's total monthly earnings (including bonuses and commissions) are equal to or less than the monthly minimum wage (l10n_mx_daily_min_wage…
According to the Mexican Social Security Law, when an employee's total monthly earnings (including bonuses and commissions) are equal to or less than the monthly minimum wage (l10n_mx_daily_min_wage * 365 / 12), they are exempt from social security contributions and income tax, also they lost the subsidy benefit. - The next rules are zeroed out when the gross salary is equal or less than the minimum wage: - IMSS_EMPLOYEE: IMSS Total (Employee) - ISR: ISR (Income Tax) - SUBSIDY: Used Subsidy - IMSS_EMPLOYEE and ISR are omitted from the generated XML. - As the ISR is zero, the `totalDeducciones` attribute on the `nomina12:Nomina` node should be removed. - The SUBSIDY should be present in the `SubsidioCausado` attribute on the `nomina12:SubsidioAlEmpleo` node, but the `Importe` attribute on the `nomina12:OtroPago` node should be 0.0. This change requires updates to existing standard tests, as some previous test cases used amounts lower than the minimum wage. target: 19.0 task-5226971
A recent issue prevented the appointment module from being correctly reinstalled, resulting in installation errors. This update resolves the problem by temporarily skipping the generation of email invitation URLs during the installation process, preventing a key lookup error. This ensures a smoother and more reliable module reinstallation experience.
Original PR description
Reinstalling the appointment module fails during mail template validation. ### Reproduction Steps 1. Install the `appointment_hr_recruitment` module. 2. Uninstall `appointment`. 3. Reinstall…
Reinstalling the appointment module fails during mail template validation. ### Reproduction Steps 1. Install the `appointment_hr_recruitment` module. 2. Uninstall `appointment`. 3. Reinstall `appointment`. → A template parsing error appears. ### Cause The global `request.env` is bound to the registry active at the start of the request. When reinstalling a module, this registry becomes stale and does not include the models being re-added. During installation, the `mail.template` model performs a test render to validate its XML data. One of the templates calls `_get_interview_invite_url`, which invokes a controller that looks up the `appointment.type` model using `request.env`. Because the registry is stale and does not contain this model, the lookup raises a KeyError and the installation fails. ### Fix Rationale Skip invite URL generation when `install_mode` is set to avoid using the stale `request.env`. opw-5898780 Forward-Port-Of: odoo/enterprise#107650
This update enhances the accuracy of payment reference checks by tailoring the validation process to the bank account's country. Previously, a single check applied to all countries could lead to incorrect validation. Now, the system verifies the reference format against the specific country of the bank account, with a fallback for unsupported countries.
Original PR description
Currently, when initiating a payment, we check if the reference is a structured one by using `is_valid_structured_reference` which checks the validity of the structure accross all supported countries. This can lead to issues when it matches formats accepted by other countries but not the one of the bank account. With this commit, we replace this check by a call to a new function that checks the structure validity according to the country of the bank account, with a fallback to the generic check (ISO 11649) if the country is not supported. opw-5387269 Forward-Port-Of: odoo/enterprise#107721 Forward-Port-Of: odoo/enterprise#107116
This update resolves an issue where DHL shipping rate calculations failed when requested for dates outside of DHL's business hours. Adding a 'next business day' flag ensures rates are accurately calculated, preventing errors and ensuring reliable shipping options for customers. This addresses a previous technical problem impacting shipping functionality.
Original PR description
Before this commit, there was an issue when trying to get the rates for DHL shipping late in the day. The issue happened because `plannedShippingDate` fell outside of the working hours. This commit adds the nextBusinessDay flag for the rating request to avoid the error. Error: ``` Product not found 996: The requested product(s) not available for the requested pickup date. Process ID associated for this transaction') ``` opw-5393684 Forward-Port-Of: odoo/enterprise#107153
This update resolves a potential issue where global invoices sent from the POS could fail due to timeouts when interacting with the SAT portal. Increasing the timeout duration for these requests helps ensure invoices are successfully transmitted, preventing duplicate documents and improving the overall reliability of the Mexico tax filing process. This addresses a reported problem impacting users in Mexico.
Original PR description
**Fix:** Increase the read timeout for POST requests to SW sapien PAC. It may prevent timeout issue when sending a global invoice from the POS with a lot of POS orders that could lead to duplicated documents on the SAT portal when retrying to send the global invoice again. opw-5347962 Forward-Port-Of: odoo/enterprise#107735
This update ensures payslips accurately reflect an employee's start date with the company, regardless of internal job changes. Previously, payslips used the contract start date, which was inaccurate for long-term employees. This change, primarily impacting payroll in Switzerland and the UAE, provides a more precise and reliable view of employee tenure.
Original PR description
In the payslip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s). Since Switzerland uses a custom report for the payslip, the same change is applied there. Task: 5909637 Community PR: https://github.com/odoo/odoo/pull/248598 Forward-Port-Of: odoo/enterprise#106692
17 changes
Resolved issues and error corrections
This fix addresses an error that occurred when creating invoices with negative tax factors. The issue stemmed from a filtering process that resulted in an empty list, causing a data error. We've reverted the recent changes to ensure invoices with negative tax factors can be created without interruption.
Original PR description
Steps to reproduce: - Install `account` module - Taxes > open any existing tax > Set `factor_percent(%)` of repartition lines to negative(eg:…
Steps to reproduce: - Install `account` module - Taxes > open any existing tax > Set `factor_percent(%)` of repartition lines to negative(eg: [Image](https://www.awesomescreenshot.com/image/58851592?key=ce0017bb467a583ad020f33d21d4d8ba)) - Create a Invoice and add tax in move line and save Traceback: `IndexError: list index out of range` We are getting `factors` as empty because `target_factors` from `_add_accounting_data_to_base_line_tax_details` is empty. This happens because, in `tax_reps`, we are filtering repartition lines with a `factor` greater than `0`. However, when the `factor` is less than `0`, `tax_reps` becomes empty, which leads to the error. We are reverting this PR: https://github.com/odoo/odoo/pull/234334 because it prevents the validation error from being raised when there is a negative value in the repartition lines. [factors]: https://github.com/odoo/odoo/blob/de056cc784a3bbe2575fd3c9e81ca62e73c362d4/addons/account/models/account_tax.py#L1641 [tax_reps]: https://github.com/odoo/odoo/blob/de056cc784a3bbe2575fd3c9e81ca62e73c362d4/addons/account/models/account_tax.py#L2429-L2431 sentry-7102210210
This update resolves a potential issue where global invoices sent from the POS could fail to send correctly to the SAT portal, leading to duplicate documents. By increasing the timeout for communication with the SW sapien system, the fix enhances the reliability of invoice processing, particularly when handling multiple POS orders. This prevents errors and ensures accurate reporting to tax authorities.
Original PR description
**Fix:** Increase the read timeout for POST requests to SW sapien PAC. It may prevent timeout issue when sending a global invoice from the POS with a lot of POS orders that could lead to duplicated documents on the SAT portal when retrying to send the global invoice again. opw-5347962
This update corrects a default VAT rate issue for Odoo installations using the l10n_ee module. Estonia's VAT rate increased to 24% on July 1, 2025, and this change ensures all new Odoo setups and databases automatically use the correct 24% rate for sales and purchases. This update maintains accurate financial reporting for Estonian businesses.
Original PR description
Issue: Estonia increased its standard VAT rate from 22% to 24% effective July 1, 2025. Existing Odoo installations and new databases created with older templates still default to the outdated 22% rate for sales and purchases. Steps to Reproduce: 1. Install l10n_ee on a fresh database. 2. Go to Accounting > Configuration > Settings. 3. Observe that the default Sales and Purchase taxes are set to 22%. 4. Create a new product; observe it automatically assigns the 22% tax. Solution: - Updated account.tax-ee.csv to set active=False for 22% tax templates and ensure 24% templates are active. - Modified template_ee.py to update account_sale_tax_id and account_purchase_tax_id to point to the new 24% tax IDs. - Updated EU_TAX_MAP in l10n_eu_oss to reflect the 24% destination rate for Estonia across all EU member states. backport of: https://github.com/odoo/odoo/commit/55e3853313969918005757203fc63ee1bd0a3b43 opw-5407921
This update resolves a technical issue where `Image` and `Binary` objects were incorrectly linked. The fix ensures these object types maintain distinct type values, preventing potential data inconsistencies. This improves the stability and reliability of Odoo's file management system.
Original PR description
This fixes an oversight of 4840a6639deb171c28ae14b0269d420aa1503860 that `Image` and `Binary` objects have the same `self.type` value and thus an `Image` can relate to a `Binary`, after all. Forward-Port-Of: odoo/odoo#249260
This update resolves an issue where DHL shipping rate calculations failed when requested for dates outside of DHL's business hours. Adding a 'next business day' flag ensures rates are accurately calculated, preventing errors and ensuring reliable shipping options for customers. This addresses a previous error reported as opw-5393684.
Original PR description
Before this commit, there was an issue when trying to get the rates for DHL shipping late in the day. The issue happened because `plannedShippingDate` fell outside of the working hours. This commit adds the nextBusinessDay flag for the rating request to avoid the error. Error: ``` Product not found 996: The requested product(s) not available for the requested pickup date. Process ID associated for this transaction') ``` opw-5393684 Forward-Port-Of: odoo/enterprise#107153
This update resolves an issue where a backorder was incorrectly created when validating a stock picking involving a product with a quality control point and a serial number. The fix ensures that the 'picked' status is correctly set to 'False' after generating a serial number, preventing unnecessary backorders and improving order accuracy.
Original PR description
Issue ----- When validating a picking with a product with a QC and a product tracked by SN, the system creates a backorder although quantities haven't been manually edited. Steps to reproduce ----- -…
Issue ----- When validating a picking with a product with a QC and a product tracked by SN, the system creates a backorder although quantities haven't been manually edited. Steps to reproduce ----- - Create product A tracked by SN - Create product B with a quality check point upon reception - Create a reception for 1 of each product - Validate the picking > QC prompt - Pass the QC > Missing SN prompt for A - Generate a SN for A - Validate the picking > Backorder prompt Cause ----- When validating, the moves get `picked` set to True in `_pre_action_done_hook` https://github.com/odoo/odoo/blob/6b232a2dc96a995eaf3714f3f077a9205dfa7ca8/addons/stock/models/stock_picking.py#L1492 Then, we go through the override of `quality_control` https://github.com/odoo/enterprise/blob/fc6ef67dbbb0962c75393076abf6a0a53cfa61a3/quality_control/models/stock_picking.py#L102-L105 which returns the QC wizard https://github.com/odoo/enterprise/blob/fc6ef67dbbb0962c75393076abf6a0a53cfa61a3/quality_control/models/stock_picking.py#L79-L82 So it gets propagated as the return value of `button_validate` https://github.com/odoo/odoo/blob/6b232a2dc96a995eaf3714f3f077a9205dfa7ca8/addons/stock/models/stock_picking.py#L1421-L1423 When we later generate the SN, we create a new move, for which `picked` is False https://github.com/odoo/odoo/blob/6b232a2dc96a995eaf3714f3f077a9205dfa7ca8/addons/stock/static/src/widgets/generate_serial.js#L90-L93 https://github.com/odoo/odoo/blob/6b232a2dc96a995eaf3714f3f077a9205dfa7ca8/addons/stock/models/stock_move.py#L261-L267 In a flow without the control point, `button_validate` raises the missing SN exception https://github.com/odoo/odoo/blob/6b232a2dc96a995eaf3714f3f077a9205dfa7ca8/addons/stock/models/stock_move_line.py#L664-L672 The change to `picked` does not get applied to the records, so both moves stay unpicked. ----- Ticket: opw-5457667
This update fixes an issue in the barcode picking interface where adding multiple extra products triggered a confusing, repeated confirmation dialog. Now, the dialog opens only once and allows users to easily select and deselect products before confirming the addition, streamlining the picking process.
Original PR description
When adding extra products in the barcode picking interface, the confirmation dialog did not handle correctly the scan of multiple extra items. Before: Scanning multiple extra products successively opened (mutex + promise) the dialog multiple times. The user had to confirm/cancel each extra product addition one by one. After: The dialog is now only opened once and updated when scanning multiple extra products before confirming. The user can select/deselect the extra products to add before validating. [opw-5193269](https://www.odoo.com/odoo/project/49/tasks/5193269)
This update resolves an issue preventing custom address fields from being added to event registration forms. By adding a type check, the system now allows for greater flexibility in custom module overrides, ensuring event registration forms can accommodate a wider range of data inputs. This improves the extensibility of the website event module.
Original PR description
Before the addition of identification questions like "name", "email", and "phone" in the commit [1] as event questions instead of having them static, we could add custom data, such as fields for the address, with static inputs in the form. After that addition, it's no longer possible because the registration gives us the following error when trying to convert data that isn't a M2o ID or an Integer value:
invalid literal for int() with base 10
By adding the check for the field's type, we can still add custom fields with static fields in the template, as an alternative, given that there's no question type for other fields.
[1]: https://github.com/odoo/odoo/commit/6b8daa880c
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prA recent update caused a crash when users attempted to undo a duplicated list within the spreadsheet feature. This fix ensures that the undo function correctly handles list duplication, preventing unexpected errors and improving the user experience. This resolves a bug that impacted list management within the spreadsheet.
Original PR description
How to reproduce: - insert an odoo list in a spreadsheet - duplicate the list from the sidepanel - undo with Ctrl+z -> crash The command "DUPLICATE_ODOO_LIST" was not supported in the inverseCommand registry. Task-5943688 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 creating multiple email templates using favorites could lead to errors due to excessive nested HTML elements. The fix prevents unnecessary wrapping of templates, ensuring a smoother and more reliable email creation experience. This improvement enhances the stability of the Email Marketing app.
Original PR description
**Steps to reproduce:** - Go to Email Marketing app - Create a new mailing - Click on empty mail body and add only a Heading block - Set a subject, save it and click `Add to Templates` (favorites) - Create another mailing which use the first one as its template - Repeat the operation multiple times - Error will be raised at some point due to the depth of the template html **Issue:** Unnecessarily nested `div` are created when using favorites to create new `mailing.mailing` records, if those favorites are themselves based on other favorites etc., it later can lead to a recursion error when rendering the template. **Fix:** Check if the template comes from the favorites to avoid reapplying the wrappers on it. This seems to be solved in 19.0 with the refactoring (https://github.com/odoo/odoo/commit/354b8f60dbabcfac690d90bf657592e1347e4f86) opw-5275187
This update resolves a bug that caused forum posts to fail to create when Odoo was in debug mode. The issue stemmed from incorrect property settings being passed to a key component. By changing 'disabled' to 'isReadOnly', the system now correctly handles forum post creation, ensuring a stable user experience.
Original PR description
Following rewrite in odoo/odoo@33206fd1941ae, this commit update passed props (`disabled` -> `isReadOnly`) to avoid a crash when creating a new forum post while being in debug mode: `OwlError: Invalid props for component 'WebsiteForumTagsWrapper': unknown key 'disabled'` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a rounding issue in the stock barcode scanning process, specifically when handling delivery orders. Previously, quantities were being rounded to a less precise value, leading to discrepancies in stock levels. This fix ensures accurate stock updates during barcode scanning, improving inventory management.
Original PR description
To reproduce the issue: - Create a stock quantity of product1 for example of 275.84 kg in PACK1 - Create a delivery order of 3.6 kg - Go to the delivery order on stock barcode - Scan PACK1 - The new line is created as 272.2399999999
This update addresses a technical issue preventing Virtual IoT boxes from downloading handlers correctly. The change restores a secure process by explicitly verifying SSL certificates, ensuring that IoT handler downloads function reliably. This resolves a previous security oversight related to Python's urllib3 library on Windows.
Original PR description
In PR #233423, we rightfully removed `cert_reqs='CERT_NONE'` to enforce secure certificate validation during IoT handler downloads. However, this exposed a blind spot in Python's `urllib3` library on Windows. Because `urllib3` defaults to the host's underlying certificate list (which is limited on Windows) instead of the installed `certifi` package, Virtual IoT boxes get the following error during handler downloads: `certificate verify failed: unable to get local issuer certificate` This commit restores the broken flow while maintaining security by explicitly passing `certifi.where()` to the `urllib3.PoolManager` via the `ca_certs` parameter. opw-5902549 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249213
This update corrects a discrepancy in payslip calculations for the private car daily allowance. The daily amount is now rounded to two decimal places, ensuring it precisely matches the 'Quantity × Amount' displayed on payslips. This improves the accuracy and clarity of employee compensation information.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#106753
This update resolves an issue where tasks remained linked to sales orders even after sales order items were removed. Now, users can properly detach tasks from sales orders, preventing billing issues and allowing for easier task management. This ensures tasks can be accurately billed or re-assigned when needed.
Original PR description
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be…
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. **Steps to produce:** * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty the Sale Order Item Field **Observed Behavior:** * Sale Order is still linked to the task despite sale order line has been unlinked from that task. **Root cause:** * Compute method [1] only detaches the sale order if the customer has been changed. **Solution:** * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2]: https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 Related Enterprise PR: https://github.com/odoo/enterprise/pull/103487 opw-5215989 Forward-Port-Of: odoo/odoo#241446
This update resolves an issue where tasks remained linked to sales orders even without a related sales order item. Now, users can unlink tasks from sales orders without impacting the ability to bill tasks, particularly for field service tasks where materials can still be added to the existing order. This improves workflow efficiency.
Original PR description
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be…
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. **Steps to produce:** * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty Sale Order Item Field **Observed Behavior:** * Sale Order is still linked to the task despite sale order line has been unlinked from that task. **Root cause:** * Compute method [1] only detaches the sale order if the customer has been changed. **Solution:** * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2] https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 Related community PR: https://github.com/odoo/odoo/pull/241446 opw-5215989 Forward-Port-Of: odoo/enterprise#103487
This update resolves an issue where test runs were repeatedly generating unnecessary assets, slowing down the testing process. By adding the 'web_studio.studio_assets' bundle to the pregeneration list, tests now run more efficiently and reliably. This improves overall development speed.
Original PR description
During tests runs, lazy loaded assets are generated on the fly, and eventually multiple hundred of times (i.e. +/- 150 times on runbot). This commit adds the `web_studio.studio_assets` bundle to the pregeneration list to avoid regenerating during tests runs. Forward-Port-Of: odoo/enterprise#107147
2 changes
Resolved issues and error corrections
This update resolves an issue where the skills module's automated tour was failing due to a conflict with multiple popups. The fix ensures the tour correctly identifies and closes the intended popup, improving the user experience and reliability of the training process.
Original PR description
When looking for this selector `.modal-footer .btn-primary` multiple popup are opened and the tour could select the wrong one. It would then not close the correct popup and fail the tour. runbot-238877
This update resolves an issue where archived employee records were still visible in the attendance Gantt view. The change ensures that only currently active employees are displayed, improving data accuracy and clarity for reporting.
Original PR description
Steps to reproduce: 1. install `hr_attendance_gantt` 2. create an employee 3. make attendance records for the employee in the previous months 4. archive the employee When opening the gantt view of the attendance, a row appears for the archived employee, with no attendance showing up. This commit adds a constraint to only show the active employees. opw-5490119