Daily updates from Odoo
Tuesday, February 17, 2026
193 changes
38 changes
Resolved issues and error corrections
This update fixes a usability issue on small devices where users couldn't exit the QR code customer display popup. A back button and close action have been added, allowing users to easily dismiss the popup and continue using the Point of Sale system. This enhances the user experience and prevents frustration.
Original PR description
Before this commit: =================== On small devices, the customer display popup had no way to be closed, which made it impossible to exit the QR code screen. After this commit: ================== Added a header back button and a close action to allow users to dismiss the customer display popup on small devices as well. Task-5926747 Forward-Port-Of: odoo/odoo#248400
This update corrects a previous issue where the 'Employees' smart button in job postings incorrectly counted all companies associated with the job. Now, the button only reflects the employee count for the companies currently selected, ensuring accurate reporting and data. This improves the reliability of job postings.
Original PR description
### Steps to reproduce: - Create a job for multiple companies. - Go to its configuration and click the Employees smart button. - Click the smart button and compare the employee count. ### Before/Root cause: - Currently selected companies were not considered. Instead, all companies were taken into account during the computation. ### After: - When you click on employee smart button only currently selected companies will be considered. ### Fix: - Added a domain filter to consider only the currently selected companies. task-5785245 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244718
This update corrects a technical issue where the Delivery Date was incorrectly displayed twice in the Sales Order report preview. The fix removes the redundant data entry, ensuring accurate reporting and a cleaner presentation for sales professionals. This improves the reliability of sales data.
Original PR description
**Steps to reproduce:** 1. Install modules sale_management 2. Go to Settings, Configure Document Layout and set layout to DIN 5008 3. Create a new Sale Order 4. Set a customer, add a product, and fill in the Delivery Date (Other Info) 5. Click on Print and Preview **Issue:** The Delivery Date (commitment_date) is printed twice in the report. **Solution:** Remove duplicated Delivery Date entry from this module to avoid rendering it twice. Issues : https://github.com/odoo/odoo/issues/247522 **opw-5490651** Forward-Port-Of: odoo/odoo#248779
This update fixes potential issues within the website form builder by restricting unsupported options on submit buttons. Removing redundant actions and animation controls enhances stability and prevents unexpected behavior like cloning or deletion. This ensures a more reliable and consistent user experience for website content creation.
Original PR description
*: html_builder, website_mass_mailing Prevent unsupported actions and options on form submit buttons to avoid cloning/deletion issues and UI inconsistencies. - Remove Duplicate and Remove actions from the sidebar for submit buttons (newsletter popup, forms, etc.) instead of disabling them. - Hide the animation option for submit buttons, since it is already handled in the "Button" section. - Remove the Visibility option for submit buttons. Prevent unsupported actions and options on form submit buttons to avoid cloning/deletion issues and UI inconsistencies. task-4702429 Forward-Port-Of: odoo/odoo#241101
This update enhances accounting reports by allowing users to filter based on multiple journals instead of just one. Previously, the system only supported filtering by a single journal. This change provides greater flexibility and control when generating financial reports.
Original PR description
In accounting reports, we want to be able to filter on multiples journals if needed. This filter will allow us to do this. Using `context['search_default_journal_id'] = journal_ids` doesn't work as only the first id is passed to the filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247731
This update corrects a naming issue within the SEPA Direct Debit payment provider setup. Previously, two different payment methods had the same name, causing confusion for users. The change ensures clarity by renaming one method to 'Online SEPA', streamlining the setup process and improving user experience.
Original PR description
When activating SEPA Payment Provider and checking SEPA in your settings, the name of the two (different) method was the same. Rename the method line associated with the method that comes from the provider by 'Online SEPA' to avoid confusion. task-5875979 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246688
A technical issue causing a traceback when generating employee time off reports has been fixed. The fix ensures the report always returns a valid SQL query, even when no employee data is available, preventing errors and improving report reliability. This ensures all users can consistently access and generate their time off reports.
Original PR description
Steps to Reproduce: - Install time off module without demo data - open reporting menu - open 'by Employee' Issue: - Traceback occurs Reason: - the method _table_query returns an empty string when there is no data. - _table_query should return a valid SQL query for report, not an empty string. Solution: - Modify _generate_report_query to return a valid SQL query even when there are no records - Instead of returning an empty string, return a SELECT statement with NULL values for required columns task-5846974
This update restores a previously removed feature that allowed users to designate orders as 'trusted' within the Point of Sale system. This functionality was critical for streamlining order processing and reducing manual intervention. The change ensures that trusted orders are correctly handled, improving operational efficiency.
Original PR description
The button save and all the logic about trusted orders were removed. This commit puts it back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234941 Forward-Port-Of: odoo/odoo#200567
A recurring timeout issue during automated testing of the l10n_ke_edi_oscu_pos module was identified. This issue occurred when the system refreshed the page after adding products to the cart, triggering a database transaction. This PR increases the test timeout and adds debugging information to address the problem.
Original PR description
There is an issue that seems to only happen on l10n_ke runbot that times out on tests that try to add a product to the cart in pos and then refresh the page. The l10n_ke_edi_oscu_pos module has a…
There is an issue that seems to only happen on l10n_ke runbot that times out on tests that try to add a product to the cart in pos and then refresh the page. The l10n_ke_edi_oscu_pos module has a listener added on the order component which tries to automatically add the taxes to the products in the order. This triggers a transaction on indexed db. Since the tour test executes the refresh immediately after adding the product to the cart, it causes a timeout. I could not reproduce the issue locally, but it's been happening consistently on almost every nightly run, always on the l10n_ke run. This PR will increase the timeout and add some extra info to the timeout message to help with debugging in the future. Runbot error: [233525](https://runbot.odoo.com/odoo/runbot.build.error/233525) Task: [5897379](https://www.odoo.com/odoo/project/1737/tasks/5897379) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248257
This update prevents an infinite page reload cycle when applying multiple gift cards from the same program. The fix addresses a discrepancy in how discount lines are handled, specifically when multiple gift cards are used. This ensures a smoother checkout experience for customers.
Original PR description
### Issue: Applying multi gift card from the same program results in an infinite reload cycle. #### Steps to reproduce: 1- Create a gift card program and generate two gift cards. 2- In eCommerce add…
### Issue: Applying multi gift card from the same program results in an infinite reload cycle. #### Steps to reproduce: 1- Create a gift card program and generate two gift cards. 2- In eCommerce add a deliverable product to cart. 3- Open cart and add both gift card codes. 4- Click on checkout to navigate to delivery step. The page is going to keep refreshing. ### Cause: The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.: https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24 After the fix #191132, discount lines are grouped by `reward_id`. This is done because in the back-end, by applying a single percent discount, separate lines are created per product lines with different taxes, while in front-end there is still single line. However, that fix doesn't consider that a SO might have multiple lines of the same reward: ewallet, gift_card ### Fix: This can be fixed by separating logic of groupable lines which are the lines with `percent` mode, with `per-point` mode lines. Discount is the only mode that might be added to multiple lines separately, keeping #191132 fix, and `per-point` is the only mode that might be applied multiple times per reward (in ewallet and gift_card). opw-5485912 Forward-Port-Of: odoo/odoo#248215
A minor bug causing an error when hovering over the unselect button in BuilderMany2One components has been resolved. This change ensures the component functions correctly and prevents unexpected errors, improving the user experience.
Original PR description
Issue: The `BuilderMany2One` component throws an undefined error when hovering over the unselect button. Steps to reproduce: 1. Create a `BuilderMany2One` component with `allowUnselect=true` 2. Hover over the unselect button 3. Error occurs Cause: `undefined` was passed when `hasPreview` is `false`, but a callback function is expected. Solution: Pass an empty callback function instead of `undefined` when `hasPreview` is false. Forward-Port-Of: odoo/odoo#248824 Forward-Port-Of: odoo/odoo#248387
This update ensures that the language of live chats is consistently displayed in the information side panel. Previously, some live chats were missing this language information. This change consolidates code and improves the user experience by showing the visitor's language for all live chat sessions.
Original PR description
**Purpose of this PR:** some livechats are missing the language in the info side panel. now we moved the code from website_livechat to im_livechat since we are fetching the same in website_livechat task-[`5487074`](https://www.odoo.com/odoo/project/1519/tasks/5487074) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243462
This update fixes an error that occurred when users attempted to create invoices with a quantity of zero. The fix prevents a division-by-zero error during invoice calculation, ensuring invoices can be properly processed. This improves the reliability of the invoicing process.
Original PR description
Currently an error occurs when user tries to post an invoice with zero quantity. Steps to replicate: - Install `stock_account`, 'accountant' and `sale_management`. - Go to Settings and set `Inventory…
Currently an error occurs when user tries to post an invoice with zero quantity.
Steps to replicate:
- Install `stock_account`, 'accountant' and `sale_management`.
- Go to Settings and set `Inventory Valuation` to `Perpetual (at Invoicing)` and `Inventory Cost Method` to `FIFO`.
- Go to Products and create a new one with name `test`, set Track Inventory.
- Open Sale orders, create new one with product `test` and confirm.
- Go to the delivery and Validate it. (set the quantity to meet the demand).
- Go back to the Sale Order and click Create Invoice.
- On the Invoice make the quantity to be `0` and confirm it.
- Error will occur.
Error:
```
File /home/odoo/odoo18/community/addons/stock_account/models/account_move.py, line 37, in _post
self.env['account.move.line'].create(self._stock_account_prepare_realtime_out_lines_vals())
File /home/odoo/odoo18/community/addons/stock_account/models/account_move.py, line 122, in _stock_account_prepare_realtime_out_lines_vals
price_unit = line.with_context(anglo_saxon_price_ctx)._get_cogs_value()
File /home/odoo/odoo18/community/addons/stock_account/models/account_move_line.py, line 85, in _get_cogs_value
return (price_unit * total_qty - posted_cogs_value) / self.quantity
ZeroDivisionError: float division by zero
```
Cause:
- Error occurs after a recent [fix], that added some logic to correctly calculate cogs.
- As the user made quantity as 0, it caused the error at line [1].
Solution:
- Early return from the function if the quantity is zero.
[fix]: https://github.com/odoo/odoo/pull/237119
[1]: https://github.com/odoo/odoo/blob/d088dbad84492234ae792b76545497c6cd62e4f4/addons/stock_account/models/account_move_line.py#L83
sentry-7157442021
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241974This update resolves an issue where validated time entries were incorrectly flagged as conflicts. The new conflict state accurately reflects that these days have already been approved, streamlining the time tracking process and reducing potential confusion for HR and managers. This ensures accurate reporting and prevents unnecessary alerts.
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#239267
This update corrects a problem in the demo data for the HR Holidays module. Specifically, it ensures that Anita Oliver's leave is properly applied to her next payslip, triggering the 'Time Off to Defer' functionality as intended. This ensures the demo data accurately reflects the expected behavior of the HR Holidays feature.
Original PR description
Add leave for the 1st month against its payslip so that Time Off to Defer happens for the next payslip. task-5912512
This update corrects a technical issue where Odoo's translation system incorrectly identified nodes with directives (like 'groups') as translatable. This fix ensures that only standard content is translated, improving the accuracy and efficiency of the translation process. It resolves a potential inconsistency in how Odoo handles HTML elements.
Original PR description
Nodes with directives must not be included inside a translatable span. But the function `translatable` missed the directive `groups` (without `t-`), and the class `o_translate_inline` should only override the predicate about the element's tag. Forward-Port-Of: odoo/odoo#248591 Forward-Port-Of: odoo/odoo#246354
This update fixes an issue where product names, references, and prices in the Arabic version of the Product Catalog were misaligned. The change uses specific styling to ensure text aligns correctly in RTL (right-to-left) layouts, providing a better user experience for Arabic-speaking customers. This improves readability and consistency across all languages.
Original PR description
Steps to reproduce: 1. Switch the user language to Arabic. 2. Open the Product Catalog from a Sales/Purchase order. 3. Observe that the Name, Internal Reference, and Price collapse into a single line with inconsistent ordering due to unmanaged horizontal inline flow. Cause: The use of generic span elements inside a portal encourages horizontal inline flow that fails to mirror correctly in RTL without explicit flex instructions. Solution: Update the Order Line portal template to use 'd-inline-flex' and 'align-items-baseline'. This treats the price and reference as a logical unit that respects the global direction and ensures consistent text alignment in both English and Arabic. opw-5867434 Forward-Port-Of: odoo/odoo#248620
This pull request reverts a recent change to the HR holiday report, addressing a problem that was preventing accurate leave reporting. The change was rolled back to restore the previous, correct functionality, ensuring employees' leave balances are displayed accurately.
Original PR description
…b6c2 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 fixes an issue where the 'vertical video' setting for embedded videos was lost when the HTML editor dialog was reopened after replacing the video. The change ensures that users can consistently select and maintain their preferred video format, improving the user experience. This resolves a bug related to video embedding functionality.
Original PR description
#### Description of the issue this PR addresses: - In this [PR](https://github.com/odoo/odoo/pull/242219), `.media_iframe_video` class removed from embedded video. - No common selector for website video and embedded video block #### Steps to reproduce: - Insert a video from media dialog - Enable Vertical option - Reopen dialog via Replace action - Vertical option is not preserved task-5931717 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes how Odoo calculates employee holiday schedules, resulting in faster processing times. The change reduces the number of database queries performed, leading to a smoother and more responsive experience for users managing holiday requests. This improvement focuses on internal performance enhancements.
Original PR description
Given a recordset, we do O(n) queries. Rewrite `_get_first_working_interval` to use batching of the underlying functions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the website's redirection process was losing URL parameters, leading to incorrect page navigation and errors. The fix ensures that all parameters are properly encoded during redirection, maintaining accurate routing and functionality for users. This improves the overall website experience and prevents unexpected errors.
Original PR description
Scenario from 17.0:
- set domain on website
- go to website /website/force/1?path=%2F%3Fa%3Db%26c%3Dd with another
domain
=> you are redirected to {domain}/?a=b instead of {domain}/?a=b&c=d
Scenario from 18.0:
- set domain on website
- go to /appointment/1 on other domain, select person date and time
- click on "Editor"
=> you get error:
> TypeError: AppointmentController.appointment_type_id_form() missing 1
> required positional argument: 'duration'
Cause: the /website/force/ domain redirection doesn't encode the
parameter when redirecting, so we lose parameters after the first one.
Fix: encode parameters when redirecting domain in /website/force/ route.
opw-5441957
Forward-Port-Of: odoo/odoo#248523
Forward-Port-Of: odoo/odoo#242252This update removes an unnecessary step in the HR leave report generation process. Previously, the report created a snapshot of all holiday data, which slowed down performance. Now, the report simply returns an empty table when no data is needed, resulting in faster report generation times. This improves the overall efficiency of the HR reporting system.
Original PR description
Avoid creating the table with a snapshot of current data and just return an empty table when needed Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a problem with the demo data for the l10n_pl_edi module, ensuring accurate demonstration of the Polish VAT electronic invoicing functionality. The fix resolves an incorrect field being used in the demo data, preventing installation issues and providing a reliable demonstration for users. This ensures the demo data accurately reflects the module's intended use.
Original PR description
To reproduce: - Try to install l10n_pl_edit with demo data --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an access issue preventing users from applying the 'My Department' filter in the Time Off module. The fix avoids a security restriction by directly checking employee department membership instead of relying on a separate model. This ensures the filter functionality works correctly for all users.
Original PR description
**Steps to reproduce:** 1- Install Time off app with demo data 2- Log in as Marc Demo 3- Go to Time Off > Overview 4- Enable `My Department` filter **Issue:** An access error is raised because of not having enough rights to access the field `version_id` on hr.employee. **Fix:** Adding the field `member_of_department` directly on hr.employee to to do the compute and search on that field in sudo to know if the employees in the Overview are part of the department of the current user. Hence, avoiding the need to access the `hr.version` model which the user does not have access to. Task: 5470085
This update resolves an issue where tests were failing due to a helper function raising when a related module (often from the Enterprise version) wasn't installed. The change prevents this error, ensuring Odoo's automated testing process (runbots) continues to run smoothly. This improves the reliability of our software releases.
Original PR description
When the module pointed by ensure_installed is not installed, the caller test is skipped. In 19.1, this helper is raising if the module is not found. It was a great idea to detect if the corresponding module exists or not but is an issue in some runbot builds when the targeted module is in the enterprise version. So let's prevent the raising to make runbot happy again! --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the currency rate used to value purchase invoices wasn't correctly applied when the rate was manually adjusted. This resulted in inaccurate product valuations. The fix ensures that the correct currency rate is always used, regardless of manual rate changes, leading to accurate accounting.
Original PR description
**Problem:** The value of a move does not take the correct currency rate if it was changed manually on the invoice. **Steps to reproduce:** - make sure dollar is your main currency - activate euro…
**Problem:** The value of a move does not take the correct currency rate if it was changed manually on the invoice. **Steps to reproduce:** - make sure dollar is your main currency - activate euro and set a rate of 1 USD -> 2 euros - create an avco perpetual storable product with no tax - confirm a purchase order for 1 product at 100 euros with no tax - validate move - create a bill for this purchase order - set the currency to euro - below 'EUR' change the currency to 4 (the bug also happens if you open the widget calendar and select a date with another rate than the invoice date) - in the journal items tab you should see the value going from 50 to 25 for the account move lines. - confirm the invoice - open stock and search your product **Current behavior:** the unit price is 50 **Expected behavior:** it should be 25 **Cause of the issue:** In _get_value_from_account_move when computing the value, we convert the value of the account move line using the _convert method on the currency at the date of the invoice, but if the rate was changed manually this is no longer correct. https://github.com/odoo/odoo/blob/4ad397e94b4661cd64515e137b3e650dc330269c/addons/purchase_stock/models/stock_move.py#L170 **fix** When manually changing the rate on the widget, the account move lines are updated using currency_rate https://github.com/odoo/odoo/blob/8d7194128b26a09be75bf5bfe4e63c8bbfaac69f/addons/account/models/account_move_line.py#L1634 Using the same compution for the valuation of the move ensures alignment. currency_rate is computed based on invoice_currency_rate which is updated in case the rate was set manually. https://github.com/odoo/odoo/blob/4ad397e94b4661cd64515e137b3e650dc330269c/addons/account/models/account_move_line.py#L726 opw-5416654 Forward-Port-Of: odoo/odoo#245714
This update resolves payment issues with Adyen, Mercado Pago, and Stripe caused by incorrect currency rounding. The fix ensures all payment amounts are rounded down to the currency's minor unit during transaction validation, preventing payment failures and improving payment processing accuracy. This change impacts all payment provider integrations.
Original PR description
*: payment{,_adyen,_mercado_pago,_stripe} ### Issue: The payment in some payment providers are failing to due setting currency decimals. #### Steps to reproduce: 1- In USD currency form in developer…
*: payment{,_adyen,_mercado_pago,_stripe}
### Issue:
The payment in some payment providers are failing to due setting
currency decimals.
#### Steps to reproduce:
1- In USD currency form in developer mode, set the rounding factor
to `0.001000`, so we have 3 decimal places.
2- From `Decimal Accuracy` set Price Unit to 4 digits.
3- Refresh the page.
4- Create a SO and add a line. Set the price to `200.7647`.
5- Refresh the page again and generate a payment link.
6- Pay through Adyen. As you see payments fail.
### Cause and Fix:
This issue is the same as https://github.com/odoo/odoo/pull/245059. That fix only focused on Stripe, however, the same issue is reproducible on other providers e.g. `Adyen`. In order to avoid the same issue, we can have a general fix to round down all payment transaction amounts to currency's minor unit in `_validate_amount_and_currency`.
---
There is another issue in Mercado Pago which the if currency is not one of these currencies then it will not be sent to provider rounded:
https://github.com/odoo/odoo/blob/035b701cbf7bd654f56f07244e606e4038c4115a/addons/payment_mercado_pago/const.py#L39-L43
Mercado Pago rounds **up** in these cases, which will cause mismatch in `_validate_amount_and_currency`.
opw-5871470
Forward-Port-Of: odoo/odoo#248320
Forward-Port-Of: odoo/odoo#245877This update resolves an issue where importing EDI invoices with products restricted to a different company would fail. The fix ensures products are correctly identified during import, preventing 'Incompatible company' errors and improving the reliability of multi-company invoice processing. This ensures accurate financial data import across multiple companies.
Original PR description
In a multi-company environment, importing an EDI invoice could fail if a line contains a product restricted to another company. The error "Incompatible company on records" was raised because company consistency rules were applied.
Example steps to reproduce:
- Create two Italian companies, A and B
- In company A, create a product with default code or barcode "TEST"
- This can also occur using the barcode and the “Vendor Product code” from the Purchase supplier.
- Restrict this product to company A
- Create an EDI invoice in company A with this product for company B as customer
- Import the invoice in company B, which would fail
This fix adds a search domain to correctly find products during import
opw-5496912
Forward-Port-Of: odoo/odoo#248893
Forward-Port-Of: odoo/odoo#248149This update fixes a bug where future-dated POS orders placed via self-checkout weren't properly canceled. Now, canceling a future order correctly removes it from both the POS interface and the system, ensuring accurate order management. This improves the reliability of our POS system.
Original PR description
Before this fix, when we placed an order from the self-checkout with a preset slot for a future date, we weren't able to cancel it from the POS. The UI showed it as canceled, but after refreshing, the order was still there. Now, when we cancel an order scheduled for the future, it is correctly canceled both in the UI and in the POS. task : 5246089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248246 Forward-Port-Of: odoo/odoo#235775
This update corrects a problem where users could trigger errors when entering non-numeric values in the 'Number of SN' field during serial/lot number generation. By changing the field's input type to 'number' and adding a check for periods, the system now reliably handles numeric input, preventing errors and ensuring smooth operation.
Original PR description
Issue before this commit: ========================= When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")` in the `Number of SN` field of the Generate Serials/Lots…
Issue before this commit: ========================= When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")` in the `Number of SN` field of the Generate Serials/Lots wizard, a traceback is raised: `InvalidNumberError: "dhha" is not a correct number`. Steps to Reproduce: ========================= - Install the "stock" module. - Create a receipt for a serial-tracked product. - Open the detailed operations. - Click on "Generate Serials/Lots". - Enter a string value in the "Number of SN" field. Result: A traceback is raised with: InvalidNumberError: `"dhha" is not a correct number.` Cause of the issue: ========================= The [next_serial_count input](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/lots_dialog.xml#L36) field is defined as type="text", which allows users to enter string values, even though the field represents a numeric count. The value is later processed using [parseInteger](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/generate_serial.js#L33), which throws an error when the input is not a valid integer string, [Here](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/parsers.js#L139). With This Commit: ========================= The input type is changed from type="text" to type="number", ensuring that only numeric values can be entered. This prevents invalid input and avoids the traceback when generating serial or lot numbers. Additionally, a `t-on-keydown` handler is added to prevent entering a `dot (.)`, ensuring that only integer values are allowed. Forward-Port-Of: odoo/odoo#248729 Forward-Port-Of: odoo/odoo#248221
This update ensures that confirmation emails are reliably sent when an applicant declines a job offer. Previously, it was difficult to track whether these emails were successfully delivered, leading to potential communication issues. This change provides better visibility and ensures applicants receive timely notification of their decision.
Original PR description
Before this commit, applicant refusals were logged in the chatter separately from sending the mail, making impossible to see if the mail was correctly sent or not. Forward-Port-Of: odoo/odoo#235888
This update resolves a technical issue where the composer's content was incorrectly saved to local storage, even when it was empty. This change ensures that composer data is only saved when there's actual content, improving system efficiency and preventing unnecessary storage usage. It's a minor fix that enhances the overall stability of the messaging feature.
Original PR description
Before this commit, composer content was saved in local storage even when the content is empty. This happens because while there's code to clear local storage entry on message post, the content was necessarily saved from debounced or when triggering an action that unmounts the composer of thread, like a change of active thread in discuss. This commit fixes the issue by checking that composer has some content, to determine whether the content must be saved in local storage or explicitly removed. Task-5905834 Forward-Port-Of: odoo/odoo#247030
This update fixes an issue where the number of employees flagged with invalid bank account warnings on the payroll dashboard was inaccurate. The fix ensures a more precise count by optimizing data retrieval and eliminating duplicate employee IDs. This improves the accuracy of payroll reporting and alerts.
Original PR description
> note: to be r+'ed till `master` (`saas~19.2`) because the way we compute warning has been changed in `master` description: - `warning_count` for `hr_payroll_dashboard_warning_employee_invalid_bank_account` is wrong when there are multiple versions for a single employee. steps to reproduce: - install `hr_payroll_account_iso20022` - open Payroll (note: have atleast one employee with multiple versions) - find "Employees With Invalid IBAN Bank Accounts" warning on the dashboard - note the count and click on it, the record count differs fix: - returned unique employee ids from `_get_invalid_iban_employee_ids` - also optimized the query in `_get_account_holder_employees_data` method. reasoning: we do not need bank account data from all the versions, because all the versions share same bank account data. task-5407494 Forward-Port-Of: odoo/enterprise#101678
This update resolves an issue where manual deletion of WhatsApp templates during production upgrades caused database migration blocks. By modifying the configuration to allow missing templates without errors, the upgrade process is now more robust and reliable. This ensures smoother and faster updates for our users.
Original PR description
Issue: ------ The database migration was blocked during the `config_parameter` [loading](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/config_parameter_whatsapp_template.xml#L6)…
Issue:
------
The database migration was blocked during the `config_parameter` [loading](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/config_parameter_whatsapp_template.xml#L6) phase. This occurred because several `ir.config_parameter` records used `ref()` to point to [whatsapp templates](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/sign_request_whatsapp_templates.xml) that were manually deleted in the production environment.
ValueError is raised:
```py
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: whatsapp_sign.sign_request_whatsapp_template
```
Cause:
-------
Since these whatsapp templates are defined with [`forcecreate="0"`](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/sign_request_whatsapp_templates.xml#L3), Odoo does not recreate them automatically during migration. This left the External IDs (IMD) pointing to non-existent records, causing a `ValueError: External ID not found in the system` that blocked the migration.
Solution:
-----------
Updated the `ref()` calls in the XML for these configuration parameters to include `raise_if_not_found=False`. This allows the registry to initialize successfully by returning None instead of crashing if a template is missing.
tgb: [2448](https://upgrade.odoo.com/odoo/tbg/2448?debug=1)
upg: [3895200](https://upgrade.odoo.com/odoo/upgrade.request/3895200?debug=1)
opw: [5931388](https://www.odoo.com/odoo/project/70/tasks/5931388?debug=1)
Forward-Port-Of: odoo/enterprise#107477This update ensures that DateV identifiers are unique across all partners, including those that have been archived. Previously, the system allowed duplicate identifiers to be assigned, causing issues when partners were reactivated. This change corrects a technical detail to maintain data integrity.
Original PR description
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later…
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived. ### **Steps to reproduce:** 1) Install **l10n_de_reports, Contacts** App with Demo Data. 2) Switch to a **DE company**. 3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 4) Archive 'Test-A'. 5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 6) Unarchive 'Test-A'. ### **Observed Behavior:** 'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier. ### **Expected Behavior:** A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined. ### **Root Cause:** Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint. However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions. Fix: Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones. opw-5474106 Forward-Port-Of: odoo/enterprise#106146
This update resolves an issue where the journal filter wasn't correctly applied when viewing journal items within the general ledger report. Now, when you select a journal in the report, the list of related transactions will include that journal, providing more accurate reporting. This enhancement improves the clarity and reliability of financial data analysis.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry. Forward-Port-Of: odoo/enterprise#106836
This update corrects a technical issue in the account reports module that was causing errors related to falsy IDs. The fix ensures that reports accurately reflect data by filtering out invalid IDs, preventing errors and improving report reliability. This change was triggered by a recent update to Odoo's browsing functionality.
Original PR description
Previously, get_unknown_partner_aml_ids collected AML IDs and included falsy IDs from the total lines. For a while, this had no side effects. However, in commit 4290724, the odoo/orm/models.py browse method was changed to disallow browsing for falsy IDs. get_unknown_partner_aml_ids has been caught by this and needs to not include total lines to prevent adding lines with no res_id. A simple option to ignore total lines fixes this issue. Steps to replicate: Create and post a journal entry with a line for accounts receivable Open Accounting > Tax Returns > Error (Invalid falsy real id) task: 5919319 Browse Change PR: 227477
This update corrects a problem where payment reference data from a third-party system (Codabox) was incorrectly formatted, often with extra spaces. The change ensures payment references are clean and accurate, preventing potential errors in financial processing. This improves data reliability and reduces the risk of manual intervention.
Original PR description
Before this commit, when we do the creation of the automatic reco models, it was possible that the payment ref ended with a lot of empty spaces. To avoid that, we now strip the payment ref before the creation of the reco model. Data coming from codabox where wrongly formatted since the payment ref could have space at the end or the start and even in the middle. By using a split join we solve that issue. task-5926548 Forward-Port-Of: odoo/enterprise#107421
4 changes
Resolved issues and error corrections
This update fixes an issue where duplicate DateV identifiers could be assigned to partners, even after archiving. The change ensures that a unique DateV ID is always required, regardless of a partner's active status, preventing data inconsistencies. This improves data accuracy for German reporting.
Original PR description
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later…
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived. ### **Steps to reproduce:** 1) Install **l10n_de_reports, Contacts** App with Demo Data. 2) Switch to a **DE company**. 3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 4) Archive 'Test-A'. 5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 6) Unarchive 'Test-A'. ### **Observed Behavior:** 'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier. ### **Expected Behavior:** A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined. ### **Root Cause:** Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint. However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions. Fix: Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones. opw-5474106 Forward-Port-Of: odoo/enterprise#106146
This update resolves a technical error that prevented users from removing a date filter within the booking management interface. The fix ensures the booking kanban view functions correctly, improving the user experience for scheduling appointments. This change focuses on a minor, internal technical issue.
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#106684
This update resolves an issue where the journal filter wasn't correctly applied when viewing journal items within the general ledger report. Now, when you select a journal in the report, the 'Journal Items' view accurately displays both the related invoices and the corresponding journal entry. This ensures accurate reporting and analysis of financial data.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry. Forward-Port-Of: odoo/enterprise#106836
This update corrects a problem where payment reference data from a financial system (Codabox) was incorrectly formatted, often with extra spaces. The change automatically removes these spaces before creating reco models, ensuring data accuracy and preventing potential errors in financial reporting. This improves the reliability of bank statement imports.
Original PR description
Before this commit, when we do the creation of the automatic reco models, it was possible that the payment ref ended with a lot of empty spaces. To avoid that, we now strip the payment ref before the creation of the reco model. Data coming from codabox where wrongly formatted since the payment ref could have space at the end or the start and even in the middle. By using a split join we solve that issue. task-5926548 Forward-Port-Of: odoo/enterprise#107421
12 changes
Resolved issues and error corrections
This update enhances accounting reports by allowing users to filter data across multiple journals simultaneously. Previously, filtering was limited to a single journal. This change provides greater flexibility and control for users analyzing financial data.
Original PR description
In accounting reports, we want to be able to filter on multiples journals if needed. This filter will allow us to do this. Using `context['search_default_journal_id'] = journal_ids` doesn't work as only the first id is passed to the filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247731
A recurring timeout issue during automated testing of the l10n_ke_edi_oscu_pos module was identified. This issue occurred when the system refreshed the page after adding products to the cart, triggering a database transaction. This PR increases the timeout duration and adds debugging information to address the problem.
Original PR description
There is an issue that seems to only happen on l10n_ke runbot that times out on tests that try to add a product to the cart in pos and then refresh the page. The l10n_ke_edi_oscu_pos module has a…
There is an issue that seems to only happen on l10n_ke runbot that times out on tests that try to add a product to the cart in pos and then refresh the page. The l10n_ke_edi_oscu_pos module has a listener added on the order component which tries to automatically add the taxes to the products in the order. This triggers a transaction on indexed db. Since the tour test executes the refresh immediately after adding the product to the cart, it causes a timeout. I could not reproduce the issue locally, but it's been happening consistently on almost every nightly run, always on the l10n_ke run. This PR will increase the timeout and add some extra info to the timeout message to help with debugging in the future. Runbot error: [233525](https://runbot.odoo.com/odoo/runbot.build.error/233525) Task: [5897379](https://www.odoo.com/odoo/project/1737/tasks/5897379) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248257
This update resolves an issue where the 'Contact Us' button on product pages wasn't correctly redirecting users to snippets created through drag-and-drop. The fix ensures that anchors in the button URL are properly handled, allowing for seamless redirection to the intended snippets, particularly when dealing with zero-priced products.
Original PR description
Issue: ------- When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work…
Issue: ------- When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work as intended meaning it doesn't redirects to the desired snippet even after putting the correct anchor. for ex: `#snippet-anchor` in the `Button URL` field in the settings. Cause: -------- This works fine for the pages having '/contactus' or '/'. Issues raise only when we try to redirect to a snippet. Now, if the we try to redirect to any snippet on click of the button(Contact Us) by placing the corresponding anchor, it will not redirect/work as intended. This is because of the appending`?subject=product_name` that took place. Solution: ------------ To concatenate the `subject=product_name` conditionally if the url has '#' in it If yes, we just use the `url` in the URL so that it redirects as intended else concatenate the subject & so on. This is because for redirecting to snippets we use anchors such as '#Let's-Connect'. So, In an anchor the '#' will definitely reside. Steps to reproduce: ----------------------- 1. Create a db in version 18.3 with website_sale installed. 2. Enable the `Prevent Sale of Zero Priced Product` checkbox in the settings. 3. Create a zero price product and few snippets under it and copy the anchor of one of the snippets to redirect when clicked on the 'Contact Us' button. 4. Use the Anchor(for ex: '#Let's-Connect') in the 'Button URL' field of settings. 5. Navigate to the created product and click on the 'Contact Us' button. Nothing happens & no intended redirection to the desired snippet. Ref PR: ---------- https://github.com/odoo/odoo/pull/189049/changes#diff-39e02d03a8b765b4e3afc68627aeb33f11b587163638fedfb92ed5657c3336e7R398-R399 Attachments: ----------------- **Before Fix:** [vokoscreenNG-2026-02-06_17-36-37.webm](https://github.com/user-attachments/assets/a09101d4-13df-415d-a902-420a28aedef0) **After Fix**: [vokoscreenNG-2026-02-06_17-38-37.webm](https://github.com/user-attachments/assets/a6256d0f-d8cb-4146-b95e-33452a0a79c5) - OPW - [5494517](https://www.odoo.com/odoo/project/70/tasks/5494517) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent test report for MRP was failing because the administrator user lacked the necessary permissions to select product variants. This update adds the required user rights, allowing the test to pass and ensuring accurate reporting of product variants within the system. This resolves a critical issue impacting test report accuracy.
Original PR description
The _/mrp:TestReportBom.test_mrp_report_bom_variant_selection_ test was failling because administrator user couldn't use the product variants. The needed dropdown menu to switch variant wasn't displayed and the test failed. We add the "product.group_product_variant" rights to the user. Runbot error: 238917 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where customers could still redeem expired ewallet points. The change prevents users from claiming points after their expiration date, ensuring accurate point balances and a better customer experience. This resolves an issue reported in opw-5476686.
Original PR description
### Issue: Due to this issue, ewallet points are claimable after expiry. #### Steps to reproduce: 1- Create a ewallet program, and generate an ewallet for a partner. 2- Set the expiration date in the past. 3- Create a SO with the same partner. 4- Click on reward. Expected: The ewallet shouldn't be claimable. Current outcome: The ewallet is claimable. opw-5476686 Forward-Port-Of: odoo/odoo#248528 Forward-Port-Of: odoo/odoo#247740
This update prevents an infinite page reload cycle when applying multiple gift cards from the same program. The fix addresses a discrepancy in how discount lines are handled, specifically related to multi-gift card applications. This ensures a smoother checkout experience for customers using gift cards.
Original PR description
### Issue: Applying multi gift card from the same program results in an infinite reload cycle. #### Steps to reproduce: 1- Create a gift card program and generate two gift cards. 2- In eCommerce add…
### Issue: Applying multi gift card from the same program results in an infinite reload cycle. #### Steps to reproduce: 1- Create a gift card program and generate two gift cards. 2- In eCommerce add a deliverable product to cart. 3- Open cart and add both gift card codes. 4- Click on checkout to navigate to delivery step. The page is going to keep refreshing. ### Cause: The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.: https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24 After the fix #191132, discount lines are grouped by `reward_id`. This is done because in the back-end, by applying a single percent discount, separate lines are created per product lines with different taxes, while in front-end there is still single line. However, that fix doesn't consider that a SO might have multiple lines of the same reward: ewallet, gift_card ### Fix: This can be fixed by separating logic of groupable lines which are the lines with `percent` mode, with `per-point` mode lines. Discount is the only mode that might be added to multiple lines separately, keeping #191132 fix, and `per-point` is the only mode that might be applied multiple times per reward (in ewallet and gift_card). opw-5485912 Forward-Port-Of: odoo/odoo#248215
This update fixes an issue where the table editor lost focus after deleting rows or columns, disrupting the editing workflow and causing confusion. Now, the editor automatically refocuses, ensuring a smoother and more intuitive experience when modifying table data.
Original PR description
**Current behavior before PR:** When a user deletes a row or column from table menu, the editor loses focus. As a result, actions like Undo do not behave as expected and require multiple attempts to restore the original table state. This breaks the editing flow, causes confusion when performing table-related actions. **Desired behavior after PR:** This PR ensures that editable is focused after deleting row or column from table menu. This commit also makes sure that selection is set properly and hint is visible on empty cell after deleting the column. task-5725593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248496 Forward-Port-Of: odoo/odoo#245433
This update resolves an issue where attendance managers couldn't edit their team members' records. The change ensures both managers and officers can now modify attendance data, improving workflow efficiency. Thorough testing has been added to ensure this fix is reliable.
Original PR description
The commit https://github.com/odoo/odoo/commit/d115cca1296c0bd20a2875bdaadf2a9136c33dda introduced the opportunity for attendance managers to edit their subordinates attendances, but the condition was lacking parenthesis, leading to an unexpected behaviour. This commit changes the condition so that it is possible both for a manager and an officer to do the edition. It also rewrite the tests in order to be more thorough. No related task Forward-Port-Of: odoo/odoo#248580 Forward-Port-Of: odoo/odoo#248471
This update fixes an issue where the system incorrectly treated re-deliveries as returns, leading to a single shipping label being generated. Now, when returning multiple packages, the system accurately processes all incoming shipments as returns, ensuring correct label generation and tracking.
Original PR description
Issue ----- When doing delivery -> return -> re-delivery, only one label is received even when there are mutliple packages to be "re-delivered". Steps to reproduce ----- - Create a UPS delivery -…
Issue ----- When doing delivery -> return -> re-delivery, only one label is received even when there are mutliple packages to be "re-delivered". Steps to reproduce ----- - Create a UPS delivery - Multiple packages - Validate transfer - Return - Validate IN - Return again - Add the UPS under the "additional info" tab - Ensure still multiple packages - Validate OUT Cause ----- When preparing the shipping data, we go through https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/delivery_ups_rest/models/delivery_ups.py#L120-L121 which leads us to do https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/delivery_carrier.py#L142-L155 so we end up with a single package to send to the delivery service. The reason `is_return_picking` is true is because the compute method only checks for an existing move with an `origin_returned_move_id`. https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/stock_picking.py#L53-L58 From a delivery flow perspective, it doesn't make much sense to consider outgoing shipments as returns. ----- Ticket: opw-5866100 Forward-Port-Of: odoo/odoo#246946
A recent issue with a specific POS printer (POS80D) was causing Odoo to crash. This pull request fixes a technical error related to USB communication, preventing the crash and ensuring reliable printer functionality. This resolves a reported problem impacting printer connectivity.
Original PR description
Seen on https://laloux-j.odoo.com/ 12/2 with a POS80D printer the printer triggers a core.USBError. This PR catches the corresponding exception 2026-02-12 04:21:12,496 1117 ERROR ? odoo.addons.iot_drivers.exception_logger: usb.core.USBError: [Errno None] Invalid descriptor task-5932720
This update corrects a bug preventing loyalty rewards from applying correctly when products are purchased in non-unit quantities (e.g., dozens). The fix ensures that rewards are accurately calculated based on the actual quantity purchased, regardless of the unit of measure. This improves the accuracy of loyalty program discounts.
Original PR description
### Issue: Due to this issue, applying a different uom than unit one, will not apply the reward regarding to quantities. #### Steps to reproduce: 1- Create a program: buy 12 get 6 free. 2- Create a SO, add a dozen of product to SOL. 3- Click on reward. Expect: 6 free unit is added. Current outcome: Nothing is added. Unless you add 12 dozens which is going to add 6 units. ### Cause: In checking rules, `product_uom_qty` is directly used without conversion to quantity. Note: `test_different_uom_to_hours_on_sale_order_confirmation` is failing due to this fix, because the uom_id unit/dozens and hours/days are not compatible. As this is not possible in UI, IMO we can delete the breaking SOL in that test. opw-5913638 Forward-Port-Of: odoo/odoo#248527 Forward-Port-Of: odoo/odoo#247743
This update resolves an issue where the journal filter selected in the general ledger report wasn't carried over when viewing journal items. Now, when you select a journal in the report, the 'Journal Items' view correctly displays both the related invoices and the corresponding journal entry, providing a more complete financial overview.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry. Forward-Port-Of: odoo/enterprise#106836
1 change
Resolved issues and error corrections
This update resolves a bug where journal filters weren't correctly reflected when viewing journal items within the general ledger report. Now, when selecting a journal in the report, the corresponding journal entries are accurately displayed alongside the related invoices, providing a more complete financial overview. The update also includes support for multiple journals, though a refresh is required.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry. Forward-Port-Of: odoo/enterprise#106836
12 changes
Resolved issues and error corrections
A recent change in how salary rules are defined in Odoo Enterprise caused issues with generating payroll reports, specifically PDFs. This update corrects the underlying logic to properly handle the new salary rule category structure, ensuring reports like the Yearly Salary by Employee and Salary Statements are generated without errors.
Original PR description
Issue: - Payroll reports were crashing or failing to generate PDFs. - This started after salary rule category was changed from `category_id` to `category_ids`. Fix: - Updated report queries and salary statement logic to use the new salary rule category relation (`category_ids`). - Fixed grouping and deduction checks to match the new structure. Impact: - Yearly Salary by Employee report now prints without errors. - Salary Statement PDFs are generated correctly. Task: 5886956
This update ensures accurate reporting of work accidents for employees on PFI (IVT) and Apprenticeship (ALT) contracts. It now issues a warning when 'Paid Work Accident' entries are used, prompting the correct selection of 'Unpaid Work Accident' entries, aligning with Belgian payroll regulations.
Original PR description
For PFI (IVT) and Apprenticeship (ALT) contracts, work accidents are not paid by the employer. If an employee with Dimona category **ALT** or **IVT** has work entries of type "Work Accident (Paid)" (LEAVE115), a warning issue is raised to inform the user that "Work Accident (Unpaid)" (LEAVE117) should be used instead. task: 5484866
This update resolves a potential issue with salary rule configurations. By clearing category IDs from salary rules, the system becomes more stable and easier to update without causing conflicts. This ensures smoother future maintenance and avoids disruptions to payroll processing.
Original PR description
We should clear category_ids on salary rules to avoid any issues if an update is required. task-5942496
This update restores the anonymization of journal entries within the HR Payroll module. Previously, certain financial records were not properly masked, which is now corrected. This ensures compliance with accounting regulations and improves data privacy.
Original PR description
Task: 5852493
This update resolves a problem where test environments were using the incorrect timezone. The fix was identified through automated build errors and ensures that test results accurately reflect the intended timezones. This improves the reliability of our testing process.
Original PR description
* = appointment, project_enterprise_hr This commit fixes a timezone wrongly setup in a test. Related Runbot Build Errors: - https://runbot.odoo.com/odoo/runbot.build.error/238019 - https://runbot.odoo.com/odoo/runbot.build.error/238021 task-5890477
This update adjusts the timeframe considered a 'relapse' for sick leave calculations, aligning with new Belgian tax regulations. Starting January 1, 2026, the period between sick leave occurrences will be 56 days instead of 14, ensuring accurate payroll reporting. The change includes updated logic and testing to reflect this new standard.
Original PR description
Spec :- Since 01/01/2026, the period between two sick time off to consider it as a relapse has been increased from 14 days to 56 days. Implementation :- . Update sickness relapse period from 14 to 56 days if the leave starts from 2026 . Add leave work_entry type where work_entry use date_start . Add corresponding tests task-5476174 Forward-Port-Of: odoo/enterprise#107294 Forward-Port-Of: odoo/enterprise#104782
This update resolves a bug that prevented invoices with lines having a product price of zero from being saved correctly. The fix ensures that required tax object fields are properly populated, allowing invoices with zero-priced items to be saved without errors. This improves invoice creation functionality for Mexican clients.
Original PR description
**PROBLEM** If you create an invoice, and add a line with a product with a price of 0, you cannot save the invoice. **STEP TO REPRODUCE** 1. On a mx company, create an invoice for a mx client. 2. Add a line with a product with a price of 0. 3. Try saving the invoice, it will fails. **CAUSE** Field `l10n_mx_edi_tax_object` is required on invoice line with mx company. However, for lines with a price of 0, it is not set by `_compute_l10n_mx_edi_tax_object` because `_l10n_mx_edi_cfdi_invoice_line_ids()` filters them. opw-5402045 Forward-Port-Of: odoo/enterprise#103981
This update resolves an issue where feedback wasn't properly recorded when approving approvals through activities. Recent changes inadvertently broke the feature, preventing feedback from being posted. Now, feedback is correctly attached as a message when an approval is completed.
Original PR description
Approving an approval via an activity with feedback did not work properly as the feedback was never posted. This was due to the consecutive refactoring that broke the feature. After this commit, the feedback is posted as a message opw-5782803 Forward-Port-Of: odoo/enterprise#106185
This update corrects an issue where payslip calculations were sometimes inaccurate, particularly after updates to payroll data. The fix ensures that net pay is computed correctly, resolving a technical problem identified through automated testing. This improves the reliability of payroll reporting for our Chinese clients.
Original PR description
Related runbot issue: https://runbot.odoo.com/odoo/runbot.build.error/237852 Task-5881260 Forward-Port-Of: odoo/enterprise#106341
This update fixes an issue with how withholding taxes are reported in Spanish accounting. Specifically, the 'type for 347' field in certain accounting moves has been corrected to be blank, aligning with Spanish tax regulations. This ensures accurate reporting and compliance.
Original PR description
- Moves that use withholding taxes should have the `type for 347` unselected and left blank. Related PR : https://github.com/odoo/odoo/pull/245828 task-5732679 Forward-Port-Of: odoo/enterprise#106889 Forward-Port-Of: odoo/enterprise#105597
This update fixes an issue where invoices generated for Ecuador (l10n_ec) were incorrectly creating discount lines due to rounding differences during tax calculations. The change aligns the XML generation process with Mexico (l10n_mx) to ensure accurate negative line handling and proper discount application, improving invoice accuracy.
Original PR description
In **l10n_ec**, negative lines are not accepted in the XML. They must be dispatched as discounts on positive lines. The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can…
In **l10n_ec**, negative lines are not accepted in the XML. They must be dispatched as discounts on positive lines. The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can cause rounding issues when the decimal accuracy for `price_unit` is increased. ## Steps to reproduce With **l10n_ec**: 1. Change the decimal accuracy to 6 digits. 2. Set the rounding method to *global rounding*. 3. Create an invoice with the following lines: | Quantity | Price | Taxes | |-----------|----------|-----------| | 20 | 1.4235 | VAT 0% G | | 20 | 1.6425 | VAT 0% G | | 20 | 1.2337 | VAT 0% G | | 20 | 1.2337 | VAT 0% G | | 20 | 1.4235 | VAT 0% G | | 6 | 3.747768 | VAT 15% G | | 6 | 3.747768 | VAT 15% G | In the generated XML, some product lines show a `descuento` of `0.01` or `-0.01`. This happens due to rounding differences in how the `descuento` is computed in the `common_details_info_template` from **l10n_ec_edi**: format_num_2(line_edi_values['price_discount'] + abs(line.balance) - line_items[1]['base_amount']) where `line.balance` and `line_items[1]['base_amount']` can differ by 0.01 due to global rounding applied during tax aggregation, and that difference must be redistributed somewhere. This commit changes how negative lines are dispatched onto positive ones, aligning the behavior with **l10n_mx**. Instead of using `tax_details_per_record` to build the XML, we now use `base_lines`, where the negative lines have already been distributed. opw-5128612 Forward-Port-Of: odoo/enterprise#104659 Forward-Port-Of: odoo/enterprise#97337
A minor bug in the knowledge calendar tour was preventing it from finishing correctly. This PR corrects a reference to a button, ensuring the tour completes as intended. This resolves a test failure and improves the overall user experience for the knowledge calendar feature.
Original PR description
In test_knowledge_calendar_command_tour there was a miss-referenced button towards the end. This caused the tour to fail because it didn't find the button to click. With this PR we correctly reference the button and allow the tour to finish. Runbot Error: 234898 Forward-Port-Of: odoo/enterprise#105354
5 changes
Resolved issues and error corrections
This update resolves several issues impacting the accuracy of Single Touch Payroll reporting in Australia. Specifically, it corrects problems with opening balance imports, excessive decimal places in year-to-date calculations, and date discrepancies for prior fiscal years. The changes ensure more reliable payroll data for compliance.
Original PR description
- Unable to import opening balances when zeroed out. This should not require Previous Payroll and BMS IDs - Float creates an overflow while computing the YTD sums, which results in too many digits in decimal places. Round all monetary amounts reported to the rounding precision of the currency. - Issues with run date and submit dates for the prior fiscal year. - Fix payslips computation on update actions post finalisation Task - 5685790
This update fixes an issue where duplicate DateV identifiers could be assigned to partners, even after archiving. The change ensures that a unique DateV ID is always required, regardless of a partner's active status, preventing data inconsistencies. This improves the accuracy of financial reporting.
Original PR description
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later…
Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived. ### **Steps to reproduce:** 1) Install **l10n_de_reports, Contacts** App with Demo Data. 2) Switch to a **DE company**. 3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 4) Archive 'Test-A'. 5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 6) Unarchive 'Test-A'. ### **Observed Behavior:** 'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier. ### **Expected Behavior:** A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined. ### **Root Cause:** Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint. However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions. Fix: Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones. opw-5474106 Forward-Port-Of: odoo/enterprise#106146
This update resolves an issue where journal filters weren't correctly reflected when viewing journal items within the general ledger report. Now, when selecting a journal filter, the corresponding journal entry details are accurately displayed alongside the related invoices. This ensures users can easily analyze financial data by journal.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry. Forward-Port-Of: odoo/enterprise#106836
This update corrects a problem where payment reference data from Codabox was incorrectly formatted, often with extra spaces. The change automatically removes these spaces before creating reco models, ensuring data accuracy and preventing potential errors in financial reporting. This improves the reliability of bank statement imports.
Original PR description
Before this commit, when we do the creation of the automatic reco models, it was possible that the payment ref ended with a lot of empty spaces. To avoid that, we now strip the payment ref before the creation of the reco model. Data coming from codabox where wrongly formatted since the payment ref could have space at the end or the start and even in the middle. By using a split join we solve that issue. task-5926548 Forward-Port-Of: odoo/enterprise#107421
This update ensures that essential products like 'Settle Due' and 'Deposit' are automatically configured for all Point of Sale (POS) settings within the Odoo Enterprise system. Previously, these products were only added when a POS session wasn't active, causing potential issues. Now, all POS configurations will have these products available, streamlining the user experience.
Original PR description
Before this commit, when the module pos_settle_due was installed, the special products (settle due, deposit, settle invoice) were only set on the POS configurations that did not have any open session. This could lead to issues when trying to use these products in a POS session of a configuration that did not have them set. Now, the special products are set on all POS configurations when installing the module. Community PR: https://github.com/odoo/odoo/pull/229074 Forward-Port-Of: odoo/enterprise#95789
18 changes
Resolved issues and error corrections
This update ensures that new leads in the CRM system always start in the 'New' stage. This is a necessary step for accurate lead tracking and reporting, aligning with the initial prospecting process. The change corrects a data issue in demo records, ensuring consistent data flow.
Original PR description
This PR corrects the stage_id of some crm.lead demo data. It must be "New" for crm.lead records of lead type as they are the first step of the prospecting. When the leads have chance of succeeding, they are converted in opportunity and then the stage can change. Task-5380531
This update enhances accounting reports by allowing users to filter data across multiple journals simultaneously. Previously, filtering was limited to a single journal. This change provides greater flexibility and accuracy when analyzing financial information.
Original PR description
In accounting reports, we want to be able to filter on multiples journals if needed. This filter will allow us to do this. Using `context['search_default_journal_id'] = journal_ids` doesn't work as only the first id is passed to the filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247731
This update fixes an issue where order data wasn't being created correctly when orders were placed through mobile self-ordering devices. The change ensures that all order information is accurately recorded within Odoo, improving the reliability of self-order transactions. This resolves a potential data discrepancy and enhances the overall ordering experience.
Original PR description
Ensure correct creation of records when sending data from a mobile self ordering device.
This update ensures that when creating expenses or sales orders, the associated account is always linked to the correct company. Previously, accounts were incorrectly pulled from a default company, leading to potential errors. This fix guarantees accurate financial reporting and simplifies the process for users managing multiple companies.
Original PR description
The aim of this commit is to ensure the account select through product is related to the correct company. (ie. the one related to the processed model) Before this commit: If a user has company_a selected as the main company in the company switcher and create an expense for company_b, the account selected from the product will be an account from company_a. (because product is shared between company but the account properties on those are company dependent) This could also happens in other places so we fixed it. After this commit: The account selected from the product will be from the company set on the model. task-4699717
This update resolves a technical issue preventing the signature field from sending notifications. The problem was a missing declaration in the notification service, which previously caused an error. This ensures that signature field updates are correctly communicated to users.
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
This update addresses a potential issue where test methods were inadvertently left attached to models, leading to unpredictable behavior in other tests. The change enforces the use of patchers for adding test-specific methods, ensuring greater test stability and reliability. This prevents conflicts and improves the overall quality of our automated tests.
Original PR description
Setting methods on models during tests and not removing them afterwards can cause misbehaviour of other tests. Setting mock or test-specific methods is not an issue but it should be done via patchers. https://runbot.odoo.com/odoo/error/237983
This update resolves an issue where users could trigger website errors when entering invalid domain names in the website settings. The fix ensures that the system gracefully handles incorrectly formatted domain names, preventing errors and improving website stability. This change focuses on data validation to ensure correct website configuration.
Original PR description
Currently an error is generated when the user tries to open the website after adding the invalid domain like `https://.com` Steps to produce an error: - Go to website settings and set the domain as `https://.com` - Open the website page >>> Error occurs Error: `UnicodeError: label empty or too long` This error occurs during IDNA encoding/decoding because the domain contains an empty second-level label, as seen in the above-mentioned domain. The error is triggered in the `_idna_url` method during IDNA encoding when the extracted base domain includes an empty second-level domain in the above-mentioned URL. This commit fixes the above issue by handling the existing `ValueError` (`since UnicodeError is a subclass of ValueError`) in the constraint, where a `ValidationError is raised when an error occurs during execution of the `_idna_url` method. sentry-7265749008
This update enhances the Point of Sale (POS) system by automatically loading product price lists when a product is selected. This ensures accurate pricing is displayed to customers and streamlines the sales process. Additionally, the team addressed a bug related to customer screen closing and connectivity checks, improving overall system stability.
This update corrects a bug where duplicate activities were created on purchase orders when a sale order was cancelled, specifically within the dropshipping workflow. The fix ensures that a key template is only triggered when appropriate, preventing this duplication and streamlining the process. This improves order management efficiency.
Original PR description
**Steps to Reproduce** * Install `sale_management`, `purchase`, and `stock` with demo data. * In Inventory → Settings, enable `Dropshipping`. * Create a product: * Set a vendor under the Purchase…
**Steps to Reproduce**
* Install `sale_management`, `purchase`, and `stock` with demo data.
* In Inventory → Settings, enable `Dropshipping`.
* Create a product:
* Set a vendor under the Purchase tab.
* Set routes to `Dropshipping` and `Buy`
* Create and confirm a sale order for this product.
* Confirm the generated purchase order.
* Cancel the originating sale order.
* Go back to the linked purchase order.
**Observed behavior**
* Two activities are created on the purchase order when the sale order is cancelled.
**Cause**
* Both templates — `exception_on_so` (from sale_stock) and
`exception_purchase_on_sale_cancellation` (from sale_purchase)
are triggered during sale order cancellation.
* Each module overrides `_action_cancel` and triggers its corresponding exception template.
* When both modules are installed, both templates run.
https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/sale_purchase/models/sale_order.py#L26-L32
https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/sale_stock/models/sale_order.py#L206-L208
* The template `exception_purchase_on_sale_cancellation` should only be triggered
when the PO originates from an SO and the product is a service, but
the domain lacks the required product-type condition.
**Fix**
* Add the missing condition to ensure that `exception_purchase_on_sale_cancellation`
is not triggered for dropshipped products, preventing duplicate activities.
---
`NOTE` - This issue is resolved from version 19.0 in this [commit](https://github.com/odoo/odoo/pull/212679/changes/ede2898278220a3ba4d8910ef268fe59f1587c72)
---
opw-5153488
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where grouped tax reports were generating incorrect results when invoices included both positive and negative tax lines. The fix ensures that all tax line balances are considered, regardless of their sign, preventing report errors. This improves the accuracy of tax reporting within the system.
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
This update fixes a visual bug in the HTML editor where the cursor placement was incorrect after using backspace after a button. Now, the cursor correctly appears inside the button as expected, ensuring a smoother and more intuitive editing experience. This resolves a minor usability issue.
Original PR description
When using backspace after a button, the cursor is visually displayed as being inside the button, but it a character is typed, it is inserted after the button, while it should be inside. What actually happens is that after backspace after a button, the selection is set around the FEFF that follows the button. This commit fixes this by putting the selection before the FEFF inside the button instead. Steps to reproduce: - Go to a "To do" note - Insert a button - Insert text after the button - Put cursor before text after button - Press backspace: the cursor is displayed inside the button - Type a letter => The letter was inserted after the button. task-5928806
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
This update optimizes how Odoo handles image processing, specifically addressing a potential memory issue that could cause slowdowns during upgrades. By preventing redundant image processing in certain scenarios, this change reduces the strain on system resources and improves overall performance.
Original PR description
Description of the issue/feature this PR addresses: Because of the way `Pillow` manages memory, excessive image processing quickly leads to MemoryError, e.g. during upgrades. Current behavior before PR: When a readonly Image field with definied dimensions relates to another Image field of the same dimensions, there is no need to ever process the former one, since the processing will already have happened on the latter one. Still, the current code will process the image superfluously in these cases. Desired behavior after PR is merged: Extending the condition for skipping superfluous image processing to cover these cases will lead to reduced compute time and memory use. Forward-Port-Of: odoo/odoo#248877 Forward-Port-Of: odoo/odoo#248834
This update fixes an issue where global discounts on sales orders weren't rounding correctly, leading to inaccurate total amounts. The change ensures that discounts are applied and rounded to the correct currency value, resulting in accurate order totals. This improves the reliability of sales pricing.
Original PR description
Issue: --- Global discount is not rounded as SOLs amounts, resulting non-zero total amount when price 100% global discount is applied. Steps to reproduce: --- 1- Create a SO. 2- Add two lines: - qty:4, price_unit:2.8207, tax:15% - qty:5, price_unit:2.8207, tax:15% 3- Using Discount action button, apply 100% global discount. As you see the total amount is not zero. Cause: --- Sol's `price_total`, `price_subtotal` are rounded to currency decimals `_add_tax_details_in_base_line`: https://github.com/odoo/odoo/blob/ef3c443837b02badc9e20bdec7544c34ed402ef3/addons/account/models/account_tax.py#L1551-L1560 However, the same rounding is not applied in discount calculation, leading to this mismatch. opw-5886749
This update resolves an issue where imported vendor bills with a product price of $0.00 incorrectly increased the product price by including allowance charges. The fix ensures that the product price remains accurate, preventing discrepancies between the original XML invoice total and the Odoo invoice total. This improves data accuracy for financial reporting.
Original PR description
Whenever a line with price `0.0` with `AllowanceCharge`s got imported, Odoo used to update the `price_unit` to the sum of price, allowance and charges, because of a wrong float comparison condition between this sum and the XML total. So the product price was increased, but the allowances were maintained. The total imported in Odoo became double the one in the XML. Step to reproduce: - Import vendor bill from XML with a product: - price: `0.00` - quantity: `1` - an AllowanceCharge, amount: `0.2` - an AllowanceCharge, amount: `0.1` - `0.0 + 0.2 + 0.1 (sum of price and allowances) != 0.3 (subtotal)` (but `float_compare(0.1 + 0.2, 0.3, precision_digits=4) == 0`) - `price_unit` is updated to `0.3` - Total in Odoo is `0.6` Ticket [link](https://www.odoo.com/odoo/project.task/5499525) opw-5499525
This update resolves an issue where accrual plans were incorrectly blocking the ability to take future leave, even with remaining balances below the cap. The fix ensures accrual plans continue to allocate leave days as expected, preventing disruptions to employee leave scheduling. This improves the accuracy of leave balance calculations.
Original PR description
Accrual plan for leave days gets blocked, even when the remaining leave balance is below the cap. As a result, no additional leaves are accrued beyond a certain point, even though they should be. #…
Accrual plan for leave days gets blocked, even when the remaining leave balance is below the cap. As a result, no additional leaves are accrued beyond a certain point, even though they should be.
# Steps to reproduce:
Go to time off app
* Create a new leave type.
* Create a new accrual plan with:
- one milestone :
- 2 days accrued per month
- Cap: 10 days
- start accruing 1 days after
- No expiration
- Carry over: All
* Create and validate a leave allocation
- 1 year ago
- new leave type
- new accrual plan
* Take the maximum number of leaves available.
* Advance the computer calendar by 1 year.
* Again, take the maximum number of leaves.
* Advance the computer calendar by another year.
* Try to take a future leave.
-> Issue: It’s not possible to take a future leave, the number of accrued days has stopped increasing. The accrual plan appears blocked.
Objective : The accrual plan should continue to allocate leave days even if leaves have been consumed regularly, as long as the remaining leaves are under the cap.
## Issue
Before going further: the property `leaves_taken` of the `hr.leave.allocation` is supposed to contain the number of leaves this allocation cover until "today".
In the `_test_get_allocation_future_leaves1` added test, in the last line of the test :
`assert_virtual_leaves_equal(self, leave_type_day, 2, self.employee_emp, date='2023-02-01')`
When calling `get_allocation_data` with a `target_date` set in the future, the result is wrong. Here is how it works :
`get_allocation_data`
...
.....`_get_consumed_leaves` (1)
...........`_get_future_leaves_on` (2)
...............`_process_accrual_plans` (3)
....................`_compute_leaves` (4)
.........................`_get_consumed_leaves` (5)
..............................`get_future_leaves_on` (6)
...................................`process_accrual_plans` (7)
**A)** The method **(2)** try to calculate the added number of days each allocation will have on `target_date`. So it creates a copy of the allocation in memory using the 'new' method:
`fake_allocation = self.env['hr.leave.allocation'].with_context(default_date_from=accrual_date).new(origin=self)`
It will then update it to `target_date` using `_process_accrual_plans` and will return the difference of days between the
updated `fake_allocation` and the current allocation (`self`)
**B)** Before iterating over each accrual date, the `_process_accrual_plans` **(3)** will get the `leaves_taken` property which is a computed field. It will trigger `_compute_leaves`.
**C)** The method **(4)** will call `_get_consumed_leaves`, and so the nightmare begins.
**D)** The method **(6)** will create a second `fake_allocation` based on the origin of the first `fake_allocation` (see **A)**).
**E)** This time, `_process_accrual_plans` **(7)** will also look at the `leaves_taken`, but won't trigger the `_compute_leaves` probably because the current allocation is a `fake_allocation` of a `fake_allocation`, and one property of the `new` method is that `Two new records with the same origin record are considered equal.`. Therefore, the `leaves_taken` is considered to be already computed (but it's not).
So `_process_accrual_plans` read the `leaves_taken` which is 0 (probably the default value of `leaves_taken`), but it should be 20 !
**F)** As the value of `leaves_taken` is wrong, the fake_allocation n°2 is also wrong, and its `number_of_day` is 10 but the `number_of_days` of the origin allocation is 20. So `get_future_leaves_on` **(6)** will return -10 which makes no sense, and all the previous calls computations will be wrong. And the final `virtual_remaining_leaves` value will be 0 instead of 2.
## Source of the issue
In the `_process_accrual_plans` method, for each allocation, `leaves_taken` is only computed once at the start of the loop over the allocation "important" dates (see `nextcall` property of `hr.leave.allocation`). At this moment, the method calculates the `leaves_taken` the allocation will have on the `accrual_date` parameter. Yet, this property can change depending on the date the allocation is on (`nextcall` property) which leads to some issues in the computation of the `allocation.number_of_days`.
## Solution
For each allocation, compute the `leaves_taken` at every iteration trough the values of `nextcall`. BUT, this can trigger an infinite loop as computing `leaves_taken` calls `_get_consumed_leaves` which calls `_get_future_leaves_on`, which calls `_process_accrual_plans` ... To avoid this, this PR add the context variable `precomputed_allocations` (will be converted into a function parameter in master) which will prevent `_get_consumed_leaves` from calling `_get_future_leaves_on` for the allocations already up to date (contained by this very `precomputed_allocations` context variable).
opw-4934391
opw-5226806
Forward-Port-Of: odoo/odoo#239836This update resolves an issue impacting the integration of Universal Business Language (UBL) with various localization modules (ANZ, Japan, My, and Singapore). Specifically, a correction was made to how customization IDs are handled, ensuring consistent and accurate UBL processing across these regional versions of Odoo. This improves the reliability of financial transactions and reporting for users utilizing these localized UBL functionalities.
Original PR description
no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the selected journal wasn't reflected when viewing journal items within the general ledger report. Now, when you filter by journal, the report accurately displays both the invoice and the associated journal entry, providing a more complete view of financial data. This enhancement improves reporting accuracy and usability.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry. Forward-Port-Of: odoo/enterprise#106836
10 changes
Resolved issues and error corrections
This update optimizes how Odoo handles image processing, specifically addressing a potential memory issue that could cause slowdowns during upgrades. By preventing redundant image processing in certain scenarios, this change reduces computing time and memory usage, leading to a smoother and more reliable experience.
Original PR description
Description of the issue/feature this PR addresses: Because of the way `Pillow` manages memory, excessive image processing quickly leads to MemoryError, e.g. during upgrades. Current behavior before PR: When a readonly Image field with definied dimensions relates to another Image field of the same dimensions, there is no need to ever process the former one, since the processing will already have happened on the latter one. Still, the current code will process the image superfluously in these cases. Desired behavior after PR is merged: Extending the condition for skipping superfluous image processing to cover these cases will lead to reduced compute time and memory use. Forward-Port-Of: odoo/odoo#248834
This update fixes a performance issue in the Odoo editor that caused slow response times and occasional freezes when editing large documents. The change simplifies the process of tracking document changes, resulting in a significantly faster and more responsive editing experience. This improves user productivity and overall editor stability.
Original PR description
Problem: When editing heavy content, each interaction can take up to 600 ms, sometimes freezing the editor completely. Cause: The `_isDirty` check is computationally expensive and is executed on…
Problem: When editing heavy content, each interaction can take up to 600 ms, sometimes freezing the editor completely. Cause: The `_isDirty` check is computationally expensive and is executed on every history step. This is unnecessary and leads to poor performance when handling large documents. Solution: Instead of recomputing `_isDirty` on each history step, directly mark the field as dirty whenever a history step is triggered. This provides a simpler and more efficient approach. Before fix: Each keyboard interaction to next paint takes around 200ms. <img width="596" height="272" alt="image" src="https://github.com/user-attachments/assets/6145a532-3148-46fd-ac5a-cd3f4c726067" /> After fix: Each keyboard interaction to next paint takes around 40ms. <img width="610" height="178" alt="image" src="https://github.com/user-attachments/assets/1ff9ca36-457b-4015-9f30-4fed990c2ba3" /> opw-5892291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where Peppol invoices were incorrectly using the wrong company context, leading to data inconsistencies and errors. The fix ensures that invoices are processed with the correct company details, preventing problems with cross-company data and improving data accuracy.
Original PR description
Currently, the created move does not always use the company context of the related move/proxy user. As a result, default values may be taken from another company, which can lead to cross-company inconsistencies and access errors. Steps to reproduce: - Set up two companies, A and B - In company A, configure a default value for the partner.company_id field, applicable only to company A - When a Peppol invoice arrives for company B but is processed using the context of company A, and a new partner must be created, the partner is created with company A as the default value - This results in an incompatible companies on record error This fix ensures that the company context of the move or EDI user is used when creating the move, preventing cross-company issues. opw-5473233
This update resolves an issue where tasks remained linked to sales orders even after sales order items were removed. Now, users can properly unlink tasks from sales orders, preventing billing issues and allowing tasks to be reassigned. This ensures accurate task management and billing within the project and sales workflows.
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
This update resolves an issue where consumption warnings appeared when receiving quantities for subcontracted products. The change avoids triggering the warning by skipping consumption checks during quantity updates, ensuring orders are processed correctly. This prevents inconsistencies between picking and subcontracting orders.
Original PR description
**Problem:** When recording the received quantity of a subcontracted product on the move_ids, if it is higher than the original demand, Odoo will update the consumed quantities. Since the new…
**Problem:** When recording the received quantity of a subcontracted product on the move_ids, if it is higher than the original demand, Odoo will update the consumed quantities. Since the new consumption is not based on the BoM, a consumption warning can happen due to UoM rounding. However, wizards and other actions can't trigger in this context, so instead of blocking the action, it partially completes, putting both the picking and the subcontracting order in an inconsistent state. If the picking is validated, this causes the subcontracting order to only process for the original demand and create a backorder, but the move_ids report the full demand, and its move_line_ids report the original demand. **Steps to Reproduce:** - Create a product (default settings) - Create a BoM for it via smart button, set the quantity to 12 - Add a component (new product w/default settings), 1 Unit - Set the BoM Type to Subcontracting, set Azure Interior as the subcontractor - Create a PO for Azure Interior, ordering 5 units of the product, and confirm it - Go to the delivery, set the received QTY to 6, and validate -> Check "Moves" smart button to see only 5 units of product were produced **Solution:** Since the consumption wizard can't be called in the context of _set_quantity(), we skip the consumption warning. The picking and subcontracting order will be processed correctly, but this comes with the limitation that the user will not receive a consumption warning when recording the consumption this way. opw-5168417
This update resolves an issue where the 'Expenses Report' feature in the HR module would fail when attached to encrypted PDF receipts. The fix skips these encrypted files, logging a note in the report instead of causing an error. This ensures reports can be generated successfully.
Original PR description
**Steps to reproduce:** - Install hr_expense - Create an expense - Attach several receipts with at least one encrypted PDF - Create Report - From cog menu, print "Expenses Report" **Issue:** A traceback is raised while trying to add the attachments to the report: "File has not been decrypted". **Cause:** The encrypted file cannot be appended to the report PDF. **Solution:** Skip encrypted files and log a note with the reason in the report. opw-5194501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previous issue where leave days weren't being allocated correctly, potentially leading to over-allocation or incorrect accrual. The fix prioritizes using accrual plan allocations first, ensuring leave days are managed effectively and don't exceed their limits. This was previously resolved in version 18.0.
Original PR description
Fixing a typo introduced in commit 211330e083baaf16279d938a2b485a8fa20083a2. Also, leave days should first use accrual plan allocation (as they can expires or will be likely to reach their maximum number of days). **This bug has already been fixed in 18.0, see community#240282.** runbot-build-error-234921 task-5449396
This update fixes an issue where input fields weren't resizing correctly in Safari and Firefox, leading to overflow. The change dynamically calculates border widths and adjusts sizing without relying on outdated browser detection methods, ensuring consistent and accurate input field behavior across different browsers.
Original PR description
Before this PR, `autoresizeInput` used a fixed buffer of `5px` to compensate for input borders. This caused incorrect sizing when inputs had thicker borders, leading to overflow issues. Safari 16 and earlier versions did not include padding and border in `scrollWidth`. To work around this, browser detection via regex was used to add a hardcoded extra value. A similar issue appeared in Firefox 145, where scrollWidth also excluded padding and border, causing inputs to overflow again. After this PR, The buffer is no longer hardcoded. The border width is now calculated dynamically and applied correctly to the final width. Browser sniffing has been removed entirely. Instead, the logic detects at runtime whether scrollWidth includes padding; if not, the missing padding is added to the computed width. This makes the behavior consistent across browsers and prevents overflow without relying on user agent checks. task-[5412025](https://www.odoo.com/odoo/project/1519/tasks/5412025)
This update fixes an issue where pasting XML into email templates didn't always work correctly, leading to malformed content. The change ensures that pasted XML, including self-closing tags, is properly parsed and handled by the editor, improving the overall email template editing experience.
Original PR description
Problem: Pasted HTML in email templates is not properly parsed. Cause: The pasted content can be valid XML. In that case, some self-closing elements (e.g. self-closing `t` tags) are not correctly parsed by the editor, leading to malformed content. Solution: Call the `fixInvalidHTML` utility when starting the edition to normalize the content and properly handle self-closing tags. Steps to reproduce: - Open an email template. - Add some content. - Toggle to code view. - Paste XML containing a self-closing `t` tag. - Observe that the content is not properly parsed. opw-5089487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the delivery charge was being incorrectly duplicated during Stripe Express checkout, particularly with Apple Pay and Google Pay. The fix ensures accurate delivery calculations by excluding delivery lines from the tax computation. This prevents overcharging customers and improves the checkout experience.
Original PR description
Versions: --- - 17.0+ Issue: --- Delivery amount is doubled in stripe express payment checkout. Steps to reproduce: --- 1- Setup a stripe payment express checkout. (In my client case it is apple pay…
Versions: --- - 17.0+ Issue: --- Delivery amount is doubled in stripe express payment checkout. Steps to reproduce: --- 1- Setup a stripe payment express checkout. (In my client case it is apple pay express checkout but we also reproduced it in google pay) 2- Set fixed price on standard delivery: 10 3- Navigate to website: add a product to cart. Use express checkout. Outcome: The delivery price is calculated twice which is wrong. Cause: --- This regression is due to #238574. Once `/compute_taxes` is called, there is delivery lines included in SO. As a result returning `amount_total` will cause `this.paymentContext['minorAmount']` to include delivery amount. Then we add delivery carrier `minorAmount`: https://github.com/odoo/odoo/blob/469220cde82ecebf4a59451cc1325add6bfc3e69/addons/payment_stripe/static/src/js/express_checkout_form.js#L188-L196 Which cause delivery amount be added twice. Fix: --- We could exclude delivery amount from total amount in `express_checkout_shipping_address_compute_taxes`, which is going to calculate the tax for lines excluding delivery lines. opw-5424398