Daily updates from Odoo
Tuesday, March 17, 2026
252 changes
45 changes
Resolved issues and error corrections
This update resolves an issue where manufacturing orders created through the barcode app incorrectly used product UoMs instead of the specified BoM UoMs. The fix ensures that stock moves accurately reflect the BoM's requirements, preventing errors and improving the reliability of the manufacturing process. This improves data accuracy for inventory management.
Original PR description
Previous behaviour: * Traceback if MO created with a BoM whose lines have UoMs that don't correspond to those of the products, then UoM setting disabled and MO viewed in the barcode app. * BoM line UoMs ignored in favour of product UoMs when creating MO in the barcode app. New behaviour: * No traceback. * Stock moves in MOs properly created with the corresponding BoM line UoMs. Task ID: [4674196](https://www.odoo.com/odoo/my-tasks/4674196) Forward-Port-Of: odoo/enterprise#110540 Forward-Port-Of: odoo/enterprise#90408
This update fixes an issue where refund calculations for orders with multiple line items in the Mexican VAT (l10n_mx_edi_pos) module were inaccurate due to incorrect summing of line amounts. The change ensures accurate comparisons against the original order total, preventing refund errors and improving the reliability of the refund process.
Original PR description
Before this commit, the some of individual line amounts were being summed to compare against the original order total when processing a refund. This could lead to incorrect comparisons due to rounding issues, resulting in errors when attempting to refund orders with multiple lines. <img width="626" height="288" alt="image" src="https://github.com/user-attachments/assets/e1bdc126-64d9-4b9a-bd16-2b97ac75e40c" /> opw-5433201 Forward-Port-Of: odoo/enterprise#109124 Forward-Port-Of: odoo/enterprise#105301
This update resolves an issue where 'View more' and 'View less' labels within the eCommerce product filters were not being translated correctly when browsing in languages other than English. The fix ensures that all filter labels are properly localized, providing a consistent user experience across all supported languages. This improves the usability of the eCommerce platform for international customers.
Original PR description
When browsing an eCommerce in any language but English and trying to filter on an attribute with more than 8 values and at most 20, the "View more" and "View less" options are not translated Steps to…
When browsing an eCommerce in any language but English and trying to filter on an attribute with more than 8 values and at most 20, the "View more" and "View less" options are not translated Steps to reproduce: 1. Install eCommerce 2. Create a product with one attribute that has 9 to 20 values and publish the product to the eCommerce (the attribute should have radio display type and should be visible in the eCommerce) 3. Add a language (e.g. French) and translate the eCommerce's website 4. Open the website and set the language to French 5. In the left column, open the filter for the attribute previously created 6. Click on "Voir plus" 7. "View less" is not translated, if you click on it, "View more" is not translated anymore Issue: The translation for "View more" is generated because it is present in the template `filter_radio_and_multi_attributes` but when we update the text in website_sale.js, the terms are not translated anymore Solution: Use `_t` to translate the "View more" and "View less" terms opw-5985712 Forward-Port-Of: odoo/odoo#253684 Forward-Port-Of: odoo/odoo#252828
This update resolves recent performance issues experienced when using the Point of Sale (POS) and self-ordering systems on iOS devices. The team optimized the user interface by adding styling to improve responsiveness and reduce delays when interacting with elements, resulting in a smoother user experience.
Original PR description
There was some issues when touching elements in the POS and self. We added the parameter role="button" to the elements that were not already and a pe-none to the images. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253686 Forward-Port-Of: odoo/odoo#253583
This update ensures that quality checks are only performed on tracked products with assigned lot or serial numbers. Previously, users could initiate quality checks without this information, now a user error is displayed, preventing incorrect data entry. Additionally, the quality check display now intelligently filters based on whether move lines have been picked, improving the user experience.
Original PR description
This commit fixes the behavior when the user tries to do quality checks for tracked products without setting their lot/sn on the picking. Before this commit: Nothing happens if the user tries to do quality checks if lots are not set on the tracked products. After this commit: A User Error is raised telling the user to assign lots/sn to the tracked products. Additional improvement: Before this commit, when having quality checks and user click on `Quality Checks` button, all quality checks appear regardless of whether all moves are picked or only some of them are picked. After this commit, clicking on `Quality Checks` button will only show quality checks related to picked move lines if at least one move line is picked, otherwise it will show all quality checks. Task-5730239 Forward-Port-Of: odoo/enterprise#104945
This update incorporates translations from Odoo 19.0 into the Enterprise version, specifically for Uzbek (uz). The process focused on directly matching translations between modules, ensuring consistency. A key consideration was verifying the accuracy of these translations within their respective contexts to avoid errors.
Original PR description
Copying translations from 19.0, only direct module matches. I.e. Missing translations were not filled in + moved terms were not matched across modules (i.e. no translation context to ensure correctness) Forward-Port-Of: odoo/enterprise#110497
A technical issue prevented the installation of the 'planning_holidays' module due to a mismatch in XML view definitions. This update reverts a recent change to ensure compatibility and allows the module to install correctly, preventing installation errors.
Original PR description
**Steps to Reproduce:** - Revert the commit 2ff35d598346798bd00fd40687e0e214c0190c1f. - Install the Planning module. - Restore the original commit - Install 'planning_holidays' module. **Error:** ```…
**Steps to Reproduce:**
- Revert the commit 2ff35d598346798bd00fd40687e0e214c0190c1f.
- Install the Planning module.
- Restore the original commit
- Install 'planning_holidays' module.
**Error:**
```
ParseError: while parsing /home/odoo/src/enterprise/saas-19.2/planning_holidays/views/planning_slot_views.xml:26, somewhere inside <record id="planning_view_kanban_inherit_planning_holidays" model="ir.ui.view">
<field name="name">planning.slot.kanban</field>
<field name="model">planning.slot</field>
<field name="inherit_id" ref="planning.planning_view_kanban_inherit"/>
<field name="arch" type="xml">
<xpath expr="//span[@t-if='record.overlap_slot_count.raw_value']" position="after">
<field name="leave_warning" class="text-danger mb-2"/>
</xpath>
</field>
</record>
```
**Cause:**
The `planning_holidays` module targets a `<span>` element in its XPath, while the `overlap_slot_count` element is located in a `<p>` in the planning module. Since view changes in stable do not update already-installed databases, the old XPath cannot be found, and a ParseError is raised during module installation.
**Fix:**
Revert the changes in stable to restore the original view.
sentry-7338367664This update resolves an issue where deleting timesheets from the system tray was unreliable. The fix ensures timesheets are properly and asynchronously removed, and that deletion confirmations are correctly handled. This improves the overall stability and usability of the timesheet management feature.
Original PR description
The onDelete method was not properly made async in the systray, plus the `delete` method promise from `record.js` actually doesn't return anything when the deletion is successful
This update fixes errors in the Dutch SBR reports by ensuring VAT numbers are correctly formatted and standardizing date formats within the exported XML files. A cleanup process has been added to improve the readability of the generated reports, making them easier for users to understand and work with.
Original PR description
Descriptions of the issues this commit addresses: The xbrli:identifier tags in the exported sbr and sbr icp files are wrong. They should always contain the company's vat without country code . The DateTimeCreation tag currently shows a date in a wrong format. It it YYYYMMDDhhmm but should be YYYY-MM-DDThh:mm:ss. Also the outputted xml is weirdly indented with many whitespaces and it makes it hard to read for no reason. --- Desired behavior after the commit is merged: This commit changes the values in the exported file to address those issues and adds the use of a cleanup helper to make the file human readable. --- task-5998939 Forward-Port-Of: odoo/enterprise#109359
This update simplifies the scatter plot chart by removing the unnecessary zoom feature. This change aligns with upcoming plans to allow users to manually adjust axis minimum and maximum values, ensuring a more consistent and controllable charting experience. This improves the chart's usability and prepares it for future enhancements.
Original PR description
## Task Description This PR aims to remove the zoomable feature for the scatter plot, as it's kind of non-sense to be able to zoom on an axis and not on the other for this type of chart. Moreover, we will soon be able to manually set the min/max of each axis manually (in master). ## Related Task/PR - Task: 5388389 - [https://github.com/odoo/enterprise/pull/106189](https://github.com/odoo/enterprise/pull/106189) 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#246954
This update removes a confusing zoom feature from the scatter plot chart in the Enterprise edition. This change simplifies the chart's functionality and aligns with upcoming plans to allow users to manually adjust axis ranges. This improves the user experience and prepares for future customization options.
Original PR description
## Task Description This PR aims to remove the zoomable feature for the scatter plot, as it's kind of non-sense to be able to zoom on an axis and not on the other for this type of chart. Moreover, we will soon be able to manually set the min/max of each axis manually (in master). ## Related Task - Task: 5388389 Forward-Port-Of: odoo/enterprise#106189
This update ensures that stock availability emails sent during testing and nightly runs use the correct partner email address associated with the website. Previously, a test error occurred because the website's partner lacked an email. The fix now provides a default email and prevents sending emails with the current user's email, resulting in more reliable email notifications.
Original PR description
This commit (https://github.com/odoo/odoo/pull/249299/changes) backported some changes concerning stock availability mails. The mail is now sent from the partner associated to the website. However, in nightly runbots, the partner associated to the website does not have any email, so an error is thrown This fix does two things : - Make sure the website's partner has an email when running the tests - Prevent the mails being sent with the current user's email as a last ressort, and let an error be thrown instead runbot-102934954 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253172 Forward-Port-Of: odoo/odoo#251951
This update fixes an issue where the lower portion of the barcode editing page was hidden by buttons. The change ensures all fields are always visible, regardless of button display, improving the user experience when adding or modifying barcode items. This prevents frustration and ensures accurate data entry.
Original PR description
# How to reproduce - Set the barcode of a product - Go to Barcode > Operations > (Select any operation) > New - Click on the cog in the top right and type in the barcode you set for the product - Apply and then edit the item you added - Add options to the page (like Expiration Date) or increase the browser's zoom until the list of fields take the whole page # The problem The fields at the bottom of the page are hidden behind the buttons at the bottom # Why The controls at the bottom are positioned absolutely and with a high z-index, so they hide anything behind them. The form css class fixes this issue by adding a margin-bottom roughly the size of the controls. But this fix does not take into account the fact that the controls can grow in size when the DELETE button is displayed opw-5907564 Forward-Port-Of: odoo/enterprise#107496
This update fixes a visual inconsistency in the calendar view of timesheets. Previously, negative time entries were displayed as '-1h 15m', which was confusing. Now, the calendar view accurately reflects negative durations like '-45 minutes', aligning with how they're shown in the list view for clarity.
Original PR description
The calendar view used Python's `divmod` for time calculations, which renders -45 minutes as -1h 15m. This representation is misleading for timesheet entries, while the list view already displays the values correctly. Adjust the calendar view logic to ensure consistent and accurate handling of negative durations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247925
This update resolves a failing test within the Odoo Enterprise POS platform. The issue stemmed from a recent change requiring a kitchen printer, which wasn't configured in the test environment. This fix ensures the test now runs correctly, maintaining the stability of the order processing flow.
Original PR description
This commit fixes the failing `test_platform_order_flow` test, specifically within the `test_platform_order_reject_flow` tour at the `.ticket-screen` step. Explanation: The root cause of this issue is that the system is now expecting a kitchen printer to be present to process the order flow. However, the unit test environment does not have a kitchen printer configured, which causes the flow to halt or behave unexpectedly when the system tries to interact with it. Reference: Breaking PR: odoo/odoo#226447 build_error-241246 Forward-Port-Of: odoo/enterprise#110249
This update resolves a technical error that prevented users from placing lunch orders with vendors when a 'Until Date' was set. The fix ensures the system correctly handles date comparisons, allowing users to consistently add items to their lunch orders. This improves the reliability of the Lunch module.
Original PR description
Steps to reproduce: ------------------------------ 1. Install Lunch module 2. Lunch > configurations > Vendors 3. Open any vendor and set Until date to any near future date 4. Go to My Lunch > New Order 5. Click on Any product with above vendor > Add to Cart 6. Click on Order Now Observation: ------------------------------ Traceback Occurs: ``` return not (self.recurrency_end_date and date.date() >= self.recurrency_end_date) and self[fieldname] ^^^^^^^^^ AttributeError: 'datetime.date' object has no attribute 'date' ``` Issue: ------------------------------ `_available_on_date` calls `date.date()` unconditionally, which fails when passed a `datetime.date` object (from `lunch.order`) since date objects lack the `date()` method. Solution: ------------------------------ Check instance type before calling `date()` to handle both `datetime.datetime` and `datetime.date` objects correctly. opw-5948688 Forward-Port-Of: odoo/odoo#249449
This update fixes a bug where employee skills weren't automatically added to appraisals created by the system's automated scheduling process. The fix ensures that skills are correctly copied to all appraisals, regardless of how they're initially created, improving appraisal accuracy and data consistency. This impacts users relying on the automated appraisal system.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date…
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date to today 4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually 5. Open the newly created appraisal for the employee Observation: ------------------------------------- In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage Issue: ------------------------------------- When the cron `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via `create()`. The skill-copying logic only lived in the `write()` override, which triggers on state transitions from 'new' to 'pending'. Since `create()` bypasses `write()`, Employee skills were never copied to cron-created appraisals https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15 Solution: ------------------------------------- Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied. opw-5491433 Forward-Port-Of: odoo/enterprise#110601 Forward-Port-Of: odoo/enterprise#107760
This update fixes a bug where journal entries could be posted even when referencing inactive analytic accounts. The fix adds a validation step during posting to ensure all referenced accounts are active, preventing incorrect financial postings. This improves data accuracy and reliability within the accounting system.
Original PR description
**Steps to produce:** - Install the `Accounting` module. - Enable analytic accounting in settings. - Create an analytic account (e.g., "test"). - Create a journal entry and assign the analytic…
**Steps to produce:** - Install the `Accounting` module. - Enable analytic accounting in settings. - Create an analytic account (e.g., "test"). - Create a journal entry and assign the analytic account in the analytic distribution. - Post the entry and export it(Make sure `journal items/account` and `journal items/analytic distribution` are also included). - `Archive` the analytic account. - Import the exported entry `OR` Duplicate the previous created entry. - Try to post the imported entry. **Issue:** - The entry is posted even if the analytic account used in the analytic distribution is inactive. **Root cause:** - The `analytic_distribution` field is stored as JSON. - At [1], the `_str_to_json` method only attempts `json.loads(value)`, and if parsing fails, it raises an error. **Solution:** - Add a validation when posting journal entries to ensure that all analytic accounts referenced in the analytic distribution are active. [1]: https://github.com/odoo/odoo/blob/13e8b462e74f144e085492857bfaa7b0d1f88f93/odoo/addons/base/models/ir_fields.py#L196-L202 opw-5350980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253752 Forward-Port-Of: odoo/odoo#239988
This update removes birthday events from automatic synchronization with Google Calendar. These events presented a confusing and unnecessary feature due to their unique handling and separate calendar display. This simplifies the calendar sync process and improves user experience.
Original PR description
Birthday events are a special kind of yearly-recurrent event that notably cannot be simply deleted like other events. They also appear as a separate calendar in the google UI to an extent, similar to tasks. As they require special handling, have little functional value and can be confusing due to that "fake calendar" behavior. We will now always filter them out of broad calendar sync. task-5966907 Forward-Port-Of: odoo/odoo#250916
This update fixes an issue where the MPS wasn't accurately reflecting demand for dependent components. Previously, the system defaulted to the oldest BoM, regardless of the user's selection. Now, the MPS correctly uses the chosen BoM to calculate and update component demand, ensuring accurate forecasting and production planning.
Original PR description
## Issue: When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which…
## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.
---
## How to reproduce:
https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8
- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10
- => Indirect Demand Qty for CMP is not shown (because it's 0)
---
## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ...
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ======================================================================
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
```
---
OPW-5979738
Forward-Port-Of: odoo/enterprise#110526
Forward-Port-Of: odoo/enterprise#109693This update fixes a performance issue in our testing process. Previously, asset bundles were repeatedly regenerated during test runs, slowing things down. Now, bundles are pregenerated once and reused, significantly improving test execution speed and stability.
Original PR description
The commit [^1] introducing binary asset bundle support overlooked the pregeneration of said bundles for the tests runs. This leads to hot-regeneration of those bundles during tests runs on the runbot (multiple hundreds of times) instead of only once and reusing them. This commit adds support for those binary bundles during pregeneration. [^1]: odoo/odoo@a5c02da5c24bfc85b3bbb7d1410d489d3c7185b8 Forward-Port-Of: odoo/odoo#248014
This update fixes a performance issue in the Web Studio module by ensuring binary asset bundles are pregenerated during testing. Previously, tests repeatedly regenerated these bundles, slowing down the testing process. Now, bundles are created once and reused, significantly improving test run times.
Original PR description
The commit odoo/odoo@a5c02da5c24bfc85b3bbb7d1410d489d3c7185b8 introducing binary asset bundle support overlooked the pregeneration of said bundles for the tests runs. This leads to hot-regeneration of those bundles during tests runs on the runbot (multiple hundreds of times) instead of only once and reusing them. This commit adds support for those binary bundles during pregeneration. Forward-Port-Of: odoo/enterprise#110555
This update fixes an issue where the auto-focus feature for the VoIP country selector dropdown was broken in saas-19.2. The fix ensures the country selector automatically receives focus when opened, improving user experience and streamlining VoIP setup.
Original PR description
Commit [1] introduced the country selector on the VoIP keypad, for saas-19.1. However, for saas-19.2, the auto-focus of the country search input once the country selector dropdown is opened was…
Commit [1] introduced the country selector on the VoIP keypad, for saas-19.1. However, for saas-19.2, the auto-focus of the country search input once the country selector dropdown is opened was broken. This is because of [2] which trapped the focus inside the softphone to improve various keyboard behaviors... but the country selector is considered to be outside of the country selector as it is a dropdown, which broke the auto-focus. We now trap the focus inside the country selector once it opens, the same way [2] traps the focus inside the softphone once it opens. Doing that, using `useAutofocus` becomes actually useless as the input is the first focusable element of the dropdown and will thus automatically be focused when the menu becomes the active element. Also, the auto-focus introduced by [1] was not working on mobile. This commit changes that but does not consider that to be a bug so this still target 19.2+. Note: a tour already existed and wanted to check that feature works but it was not properly written. This commit adds a unit test about this only too, and for the mobile usecase. [1]: https://github.com/odoo/enterprise/commit/708aea78760392207f9148c31c67212dacaf3294 [2]: https://github.com/odoo/enterprise/commit/df1772e877a508150fd3f549526dec9d867354be task-5999452
This update corrects a previous error in the Indian payroll configuration, ensuring the default basic salary percentage is set to 50% instead of 60%. Now, benefit adjustments only affect gross salary and employer costs, without altering employee wages or the underlying payroll structure. This provides a more accurate and stable payroll calculation for Indian businesses.
Original PR description
- Fix the default Indian basic salary percentage to 50% instead of 60%. - Ensure benefit amounts are treated as additional employer payments and do not rebalance the employee’s wage or basic salary in the salary configurator. After this change, benefit updates only impact gross salary and employer cost, while the wage remain unchanged. task-[5501683](https://www.odoo.com/odoo/project/1251/tasks/5501683)
This update resolves an issue where a tour feature wasn't working correctly for all shift planning scenarios. The fix removed an unnecessary check, allowing the 'Edit' button to function as intended and redirect users to the correct form view. This ensures all tour functionalities are consistently available.
Original PR description
The tour was working with `planning_field_service_sale_timesheet` but not `planning_field_service` only. The reason is that 'newButtons' did not contains any element, so the 'Edit' button logic was not altered to redirect to the form view on click as wanted. We do not need to do the check on 'newButtons' to allow that. runbot-error: https://runbot.odoo.com/odoo/runbot.build.error/241950
This update corrects a warning related to outdated cryptography libraries used in our Redsys payment processing system. The change ensures compatibility with newer versions of the cryptography library, preventing potential issues and maintaining system stability. This resolves a technical detail that could have impacted payment processing.
Original PR description
In cryptography 43.0.0 (present in Debian Trixie), ARC4 and TripleDES were migrated to decrepit [^1], leaving a deprecation warning in the old path. This commit handles both previous pre/post 43.0.0 import path. runbot-233267 [^1]: pyca/cryptography@722a6393e61b3acb569f404218f213fe08478a96 Forward-Port-Of: odoo/odoo#253957
This update corrects a naming error in the ZUGFeRD eInvoice XML file, resolving validation issues with several key e-invoice validators. Previously, the incorrect filename prevented proper processing. Now, the ZUGFeRD file passes validation across multiple platforms, ensuring accurate e-invoice handling.
Original PR description
Fix the name of the embedded xml for zugferd eInvoice format. Before this PR: For the validator https://www.portinvoice.com/en/, the error > No, the file is called zugferd.xml. The following naming conventions are > permitted: “factur-x.xml”, “xrechnung.xml”, “zugferd-invoice.xml”, > “ZUGFeRD-invoice.xml”, “order-x.xml”, “cida.xml” And also: > The XML has a valid profile? No This corresponds to the document_context, as the french factur-x and the german ZUGFeRD are a common standard, we can put the same context. After this PR: The ZUGFeRD file passes on different validators. Validators: * https://erechnungs-validator.de/ * https://easyfirma.net/e-rechnung/validieren * https://www.portinvoice.com/en/ * https://demo.verapdf.org/ task-6010416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253704 Forward-Port-Of: odoo/odoo#252681
This update fixes an issue where selecting an office on the Jobs page would remove the previously selected country filter. The fix ensures that country filters remain active when selecting offices, improving the user experience for filtering job postings by location. This change was made to enhance usability and accuracy in job searches.
Original PR description
Steps to reproduce: =================== 1. Navigate to the Jobs page. 2. Filter a specific country 3. Select all offices -> The country filter will be removed Cause: ====== the "All Offices" link inside job_filter_by_offices, the href uses 'all_countries=1' if is_remote else current_country_path but current_country_path is not defined anywhere Solution: ========= Switch to current_country_param Note: ===== The fix will be adapted in later versions opw-5947819 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252909 Forward-Port-Of: odoo/odoo#252477
This update resolves an issue where clicking on 'reply' links within Odoo's email inboxes didn't function correctly. Now, clicking on a reply link will seamlessly jump to the original email thread, improving the user experience and ensuring efficient email management. This change enhances the usability of Odoo's communication features.
Original PR description
Before this change, clicking on a `message in reply` in mailboxes had no effect. The expected behavior is for it to jump to the message in its origin thread. To fix it, this commit ensures that `useMessageHighlight` hook receives the correct thread which in this case is the origin thread of the message in reply. task-5343804 Forward-Port-Of: odoo/odoo#253990 Forward-Port-Of: odoo/odoo#253334
This update automatically groups vendor bills during UBL/CII import based on the vendor's previous bill history. By checking the last posted bill, the system ensures consistent tax grouping for improved accuracy and efficiency in invoice processing. This simplifies reconciliation and reduces manual effort.
Original PR description
[FIX] account_edi_ubl_cii: automate bill line grouping
This commit automates vendor bill line grouping during import based on the vendor's most recent posted bill.
- Logic: Added `_has_lines_grouped()` to `account.move` to detect if lines follow the grouping pattern.
- Heuristic: During UBL/CII import, the system now checks the last posted bill from the same vendor; if it was grouped, the new bill is automatically grouped by tax.
task-5979667
Forward-Port-Of: odoo/odoo#253322
Forward-Port-Of: odoo/odoo#251419This update fixes an issue where refund payments in Point of Sale were incorrectly created as inbound payments. When a refund is processed using the Card payment method with Identify Customer enabled, the system now correctly identifies these payments as outbound, ensuring accurate financial reporting. This change improves the reliability of our accounting processes.
Original PR description
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS…
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS session - Go to Invoicing → Customers → Payments Observation: - Two payment records are created - Both payments have payment_type = inbound - The refund payment should be outbound Cause: - When Identify Customer is enabled, `_create_split_account_payment` is used to create payment records - The method does not adjust payment_type for refund transactions Fix: - Add helpers to swap destination and outstanding accounts - Set `force_outstanding_account_id` instead of `outstanding_account_id`, as the former has priority - Ensure refund payments are created as `outbound` few related fix: https://github.com/odoo/odoo/commit/303a9061da85048f14a3ca7b1e13df0ab34da99e https://github.com/odoo/odoo/commit/718fac6832ecd343bf26d41fa5ae5b1ab74f4228 https://github.com/odoo/odoo/commit/684415b9ff2e151506da561016dbfa991bfa8dc8 opw-5437456 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254079 Forward-Port-Of: odoo/odoo#247760
This update corrects a previous issue where event ticket prices were incorrectly locked to the event's price in the Point of Sale system. Now, event tickets will recalculate their price based on either the event's price or a relevant pricelist, ensuring accurate pricing at the POS. This improves the overall POS experience and pricing accuracy for event tickets.
Original PR description
Event tickets in POS would have their price locked to the price defined in the event itself. They would be filtered out of any price recalculation inside the POS to keep the POS from recalculating the price based on the `product_template` and to keep the price defined in the event itself. This PR will add event tickets back into price recalculation. It will set the price to the price defined inside the event if no pricelist is applicable, or use the pricelist to calculate the price if there is one applicable. Task-[5092613](https://www.odoo.com/odoo/project/1737/tasks/5092613) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248454
This update fixes a potential error in how Odoo handles session records. Previously, if a session lacked device information due to a log being removed, it could cause a system error. Now, the system automatically populates session records with device details like IP address and user agent, ensuring consistent data and preventing these errors.
Original PR description
This commit ensures that there is always information linked to a `res.session` record. This causes an error, for example, if `user_agent` is `False`: ```py ... =…
This commit ensures that there is always information linked to a `res.session` record. This causes an error, for example, if `user_agent` is `False`: ```py ... = self.__user_agent_parser(device.user_agent) ``` We ensure that if we have a `is_current` `res.session` record which does not have a `is_current` `res.device`, we have information (`ip_address`, `user_agent`, `country`, `city`). Scenario: - device A detected at time T0: info A in session + new log A - device B detected at time T1: info B in session + new log B - log B is unlink (or marked as revoked) - device B detected at time T2: nothing ==> `web_read` on `res_users` ==> error T2 < T1 + `DEVICE_ACTIVITY_UPDATE_FREQUENCY` - device B detected at time T3: info B updated in session + new log B T3 > T1 + `DEVICE_ACTIVITY_UPDATE_FREQUENCY` Explanation: At this moment, T2, because log A exists, a `res.session` record exists. When we compute information for the `res.session` record, as this record is the current session, we must get the current device. To retrieve the current device, we use the `res.device` model. Unfortunately, no current device is present (because log B has been deleted) and `DEVICE_ACTIVITY_UPDATE_FREQUENCY` has not been exceeded. In this case, we have a current session without current device. Note: However, we are certain that there is at least one device for this session record because session records are built with device records. Task-6023651 Forward-Port-Of: odoo/odoo#253058
This update optimizes the Point of Sale system to use less memory, particularly when handling large product catalogs. The changes result in a significant reduction in memory consumption across browsers (Chrome, Safari, Firefox) when loading more than 20,000 products, leading to a smoother user experience.
Original PR description
This commit reduces memory consumption in the POS, especially when loading a large number of products. Reactivity usage has been optimized, particularly for product data. Additional optimizations were implemented to handle large product sets more efficiently. Metrics 5,000 products • Chrome: 440 MB → 75 MB • Safari / Firefox: 1 GB → 250 MB 20,000 products • Chrome: 1.5 GB → 135 MB • Safari / Firefox: 4 GB → 300 MB Enterprise PR: https://github.com/odoo/enterprise/pull/107978 Forward-Port-Of: odoo/odoo#250480 Forward-Port-Of: odoo/odoo#249542
This update optimizes the Point of Sale (POS) system to use less memory, particularly when handling large product catalogs. The changes result in significantly reduced memory consumption across Chrome, Safari, and Firefox, leading to a smoother and more responsive user experience for sales teams.
Original PR description
This commit reduces memory consumption in the POS, especially when loading a large number of products. Reactivity usage has been optimized, particularly for product data. Additional optimizations were implemented to handle large product sets more efficiently. Metrics 5,000 products • Chrome: 440 MB → 75 MB • Safari / Firefox: 1 GB → 250 MB 20,000 products • Chrome: 1.5 GB → 135 MB • Safari / Firefox: 4 GB → 300 MB Community PR: https://github.com/odoo/odoo/pull/249542 Forward-Port-Of: odoo/enterprise#108586 Forward-Port-Of: odoo/enterprise#107978
This update fixes a bug in product imports that was causing redundant records to be created. By using a 'set' instead of a 'list' to store attribute values, the system now ensures unique values are used, preventing errors and maintaining data consistency. This improves import reliability and avoids wasted resources.
Original PR description
Product imports were creating redundant `product.attribute.value` records because batch values were stored in a list without uniqueness checks. This fix ensures that: - Unique values are identified before creation. - Product variants remain usable and consistent. Issue: 5918366 Fixes the issue where importing 200 products with the same attribute value created 200 identical records. Forward-Port-Of: odoo/odoo#249086
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees associated with companies outside of India, ensuring accurate data presentation.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 Forward-Port-Of: odoo/enterprise#109775
This update resolves an issue where certain Non-Resident (NRI) GSTINs were not recognized during the partner autocomplete process. The fix updates the validation logic to accept a wider range of valid NRI GSTIN formats, ensuring accurate data entry for NRI customers. This improves the user experience and data integrity.
Original PR description
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete`…
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete` modules. - Navigate to Settings > Users & Companies > Companies. - Click `New` and set `Tax ID` to `9922JPN29001OSU`. - Wait for 5–10 seconds. **Observation:** The partner autocomplete does not trigger, although it is valid and verifiable on the official GST portal: https://services.gst.gov.in/services/searchtp **Root Cause:** The issue was already fixed in core validation by PR [1], but the GSTIN validation logic used in partner autocomplete was not updated. At [2], the GSTIN validation regex for NRI taxpayers only supports formats ending with `NRX` (X = any alphanumeric character). However, certain valid GSTINs follow a revised structure and therefore are not matched by the existing regex. **Fix**: This commit ensures that valid NRI GSTIN formats are accepted during validation by applying a fix similar to [1] to the partner autocomplete GSTIN validation at [2]. Related IAP PR: https://github.com/odoo/iap-apps/pull/1491 [1]: https://github.com/odoo/odoo/pull/251760 [2]: https://github.com/odoo/odoo/blob/3016c08a7aa8701ec9b0092b5aafc282b16dd9f3/addons/partner_autocomplete/static/src/js/partner_autocomplete_core.js#L36-L52 Forward-Port-Of: odoo/odoo#253799
This update resolves a technical error preventing the burndown chart in the Project app from loading correctly when no project is selected. The change ensures the necessary context is set, preventing errors that occur in sample mode. This improves the stability and usability of the burndown chart feature.
Original PR description
The burndown chart embedded actions use action_id which bypasses the Python method that sets required context (stage_name_and_sequence_per_id). Without this context, the JS model makes RPC calls that fail in sample mode when no project record is selected. This change replaces action_id with python_method, following the same pattern used by hr_timesheet for similar embedded actions. Steps to reproduce: 1. Open Project app 2. Access burndown chart via embedded action without records 3. Sample mode triggers the crash Current behavior: TypeError reading undefined field type Expected behavior: Burndown chart loads with proper context task-5347524 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239000
This update resolves a technical issue preventing the display of videos associated with product images. Recent changes to the Odoo system caused a problem with loading video URLs, leading to errors when creating new product images. This fix ensures that videos are correctly displayed for product images.
Original PR description
Since the view cleaning done in #230098, the `video_url` field infos were not automatically loaded by the JS ORM anymore. Therefore a traceback was raise when trying to create a new `product.image` record with a video_url field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253637
This update resolves a sporadic test failure related to scrolling to notifications within the email system. The fix ensures messages are fully loaded before the scroll action, preventing conflicts with other UI elements and improving test reliability. This enhances the overall stability of the email functionality.
Original PR description
Before this commit, test 'Can scroll to notification' may fail non-deterministically with the following error: ``` [toBe] expected values to be strictly equal (Element…
Before this commit, test 'Can scroll to notification' may fail non-deterministically with the following error: ``` [toBe] expected values to be strictly equal (Element .o-mail-NotificationMessage:contains(notification 0) not found in viewport of .o-mail-Thread) ``` This happens because while the test is awaiting the scrolling to unread, this is made with just an `await tick()` after opening discuss app. This is not enough: messages need to be loaded and then there's a tick with scroll to unread message. The awaiting of messages being loaded was missing in the test, which this error is fixing. This is important because the opening of pinned panel and click on jump may be triggered before the auto-scroll to unread message, and this is a problem because the jump to pinned message would be cancelled by the scroll to bottom. Also instead of awaiting the tick for scroll to unread message, this commit replaces it by assertion of message list being at the bottom. This asserts precisely the scroll has happen, and its ok to have it scroll at bottom as the last message is short and is necessarily smaller than viewport, thus the auto-scroll to this unread message implies this scrolls to the bottom of message list. Fixes runbot-error-238427 Forward-Port-Of: odoo/odoo#253928
This pull request reverses a previous change that was causing issues with email notifications related to HR contracts. The fix addresses a technical problem that was preventing correct email delivery, ensuring reliable communication for HR contract updates. This reverts a previous bug fix to maintain stable operations.
Original PR description
Revert https://github.com/odoo/enterprise/pull/106974 Forward-Port-Of: odoo/enterprise#110767
The planned removal of the older RPC service (xmlrpc) has been delayed until Odoo 21.1 or 22. This change ensures continued support for Odoo 20, 21, and 22 under the standard support policy, maintaining access to the JSON-2 replacement.
Original PR description
The "rpc service" API (xmlrpc/jsonrpc) have been deprecated in 19.0, JSON-2 acting as replacement. It was at first planned to be removed in 19.1/20 but we succeeded in convicing the management It Was…
The "rpc service" API (xmlrpc/jsonrpc) have been deprecated in 19.0, JSON-2 acting as replacement. It was at first planned to be removed in 19.1/20 but we succeeded in convicing the management It Was A Bad Idea. The removal is postponed to Odoo 21.1/22. This makes so that if the [Standard and extended support] policy remains the same until the release of Odoo 22, all versions supported with no additional fees (20, 21, 22) at that time will have JSON-2: | version | supported at 22 release | rpc services | JSON-2 | | ------- | ----------------------- | --------------------- | ------ | | 18.0 | no[^1] | active | absent | | 19.0 | no[^1] | active but deprecated | active | | 20.0 | yes | active but deprecated | active | | 21.0 | yes | active but deprecated | active | | 22.0 | yes | absent | active | [Standard and extended support]: https://www.odoo.com/documentation/19.0/administration/standard_extended_support.html [^1]: with no additionnal fees. Forward-Port-Of: odoo/odoo#252721
This update resolves an issue where changing a company's VAT information on Peppol would cause invoices to be rejected by accounting partners. The fix prevents automatic recalculation of EAS/Endpoint values, ensuring accurate synchronization between invoice data and accounting systems. This eliminates the need for users to un-register and re-register their companies.
Original PR description
To reproduce: - Register your company on Peppol (even sender). - Change the VAT on your company (will be done if you choose your document layout). - Send an invoice on the network - => The invoice…
To reproduce: - Register your company on Peppol (even sender). - Change the VAT on your company (will be done if you choose your document layout). - Send an invoice on the network - => The invoice will be refused by the AP. The issue is that the EAS and Endpoint are automatically re-computed when you write on the VAT. It causes issues as the UBL will be filled with the values on the partner, resulting in a non-synchronised SBD and UBL, which will result in all new invoices to be in error. Their only solution would be to revert back the EAS/Endpoint on the partner, which will sometimes be blocked meaning they have to un-register->re-register Also adapt the query count, as we need to do a search in each compute. opw-5923552 opw-5924552 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#254057 Forward-Port-Of: odoo/odoo#249017
This update corrects a performance issue in the budget report, ensuring it runs efficiently when the account_budget_purchase module is enabled. Previously, a workaround bypassed a key optimization, leading to slower report generation times. This change restores the expected performance improvement.
Original PR description
The performance optimization introduced in account_budget (see PR #99096) pushes the budget_line_ids filter down to the underlying SQL queries of budget.report to avoid building the full UNION result before applying the filter. account_budget_purchase fully overrides budget.report._compute_all() and its table_query, thereby bypassing the optimized implementation introduced in PR #99096. As a result, the budget_line_ids filter was not pushed down to the SQL level, causing large UNION queries to be executed without filtering and leading to degraded performance. Apply the same optimization in this module to restore the expected performance improvement when account_budget_purchase is installed. | Scenario | Execution Time | | :--- | :--- | | **Before this Commit** | **passed virtual time limit** | **After this Commit** | **1.25 seconds** opw-5930127 Forward-Port-Of: odoo/enterprise#109322
4 changes
Resolved issues and error corrections
This update resolves an issue where mass email sorting failed due to inconsistent date information in emails. The fix adds a default date of midnight to emails without a defined date, ensuring consistent sorting and preventing errors during email processing. This improves the reliability of email sending operations.
Original PR description
Background: In odoo.com, due to some migration scripts, there are messages without neither a date nor create_date Issue: When sending mass emails to applicants, when determining the parent email, emails are sorted using their date, but since some emails have a date and some don't, comparing them results in an exception (comparing datetime with bool). Fix: Add datetime.min as a fallback for the email's date if neither date nor create_date are set. Task-6041584
A previous change caused an error when starting a new pay run if the date field was left blank. This fix ensures the system validates the date field before processing, preventing the 'value.toFormat is not a function' error. This ensures users can consistently initiate pay runs.
Original PR description
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` >…
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` > `Payslips` > `Pay Runs`. - Click `New`, remove the `period value`, and click `Continue`. `TypeError: value.toFormat is not a function` After this recent [commit] that changed the required field validation behavior, when the date field is empty and it attempts to serialize the date [1], which raises the error here [2]. Although the start and end date field is required, the ORM call is executed without the value for the date field. This commit ensures that, similar to the base PayslipBatchFormController [3], the fields are validated before making the ORM call. [commit]: https://github.com/odoo/enterprise/commit/cd0f5f31e9427cb96092671bbcbb52dfbb3c03f8 [1]- https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/l10n_hk_hr_payroll_empf/static/src/views/payslip_run_form/hr_payslip_run_form.js#L13-L14 [2]: https://github.com/odoo/odoo/blob/3263a7f54948d57f13176cf0416b1419150e9d87/addons/web/static/src/core/l10n/dates.js#L536 [3]: https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/hr_payroll/static/src/views/payslip_run_form/hr_payslip_run_form.js#L16-L20 sentry-7207509338
This update resolves a display issue in the 'By Employee' time off reporting feature. Previously, users only saw record IDs in the list view; now, the report correctly shows relevant employee data. This ensures accurate reporting and simplifies data analysis for HR teams.
Original PR description
**Steps to reproduce** - Go to Time Off > Reporting > By Employee - Switch to graph view - Click on one of the columns Issue: only the id of the records is displayed in the list view **Cause** There's no list view defined for the `hr.leave.employee.report` Issue present since the rework in 1c3f5633ef87f6d9c5a6169eefd51cd42ef442d5 opw-5977793
This update resolves a mobile UX issue where incorrect time off balances were displayed and leave types without maximum limits lacked the 'Available' label. This ensures employees see accurate time off information when using the mobile app, improving usability and reducing potential confusion.
Original PR description
This change fixes 2 problems in the mobile UX side panel: - Time off types with zero allocations were shown. - Leave types without a max leave amount didn't show the "Available” label. task-6030539 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
5 changes
Resolved issues and error corrections
This update fixes a usability issue on mobile devices where a key button was hidden within a dropdown, requiring extra scrolling. The change ensures the loan creation process is smoother and more intuitive on smaller screens, allowing users to easily access necessary features.
Original PR description
Forward-Port-Of: odoo/enterprise#110552 Forward-Port-Of: odoo/enterprise#110120
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees associated with non-Indian companies, ensuring data accuracy and a consistent user experience.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 Forward-Port-Of: odoo/enterprise#109775
This update ensures that NACHA payment files use the correct bank account holder's name instead of the customer's name in Odoo. Prioritizing the accurate account holder name improves payment processing accuracy and reduces potential errors with financial institutions. This change ensures compliance and avoids issues with bank reconciliation.
Original PR description
The NACHA entry detail was using the partner's name (res.partner.name) for the Individual Name field. This should instead prioritize the Account Holder Name (acc_holder_name) from the bank account, as this reflects the actual name on the bank account which may differ from the partner's name in Odoo. The code now uses bank.acc_holder_name if set, and falls back to payment.partner_id.name if not set. Forward-Port-Of: odoo/enterprise#108414 Forward-Port-Of: odoo/enterprise#105582
This update resolves an issue where night shift slots (e.g., 20PM - 4AM) weren't visible in the weekly planning view. The fix adjusts how the system displays multi-day slots, ensuring all scheduled hours are accurately shown. This improves the planning experience for employees with flexible work arrangements.
Original PR description
**Steps to reproduce** 1. Have an employee using a flexible schedule 2. Create a slot from e.g. 20PM to 4AM for this employee. Make sure this is the only slot that week for the employee. 3. Publish…
**Steps to reproduce** 1. Have an employee using a flexible schedule 2. Create a slot from e.g. 20PM to 4AM for this employee. Make sure this is the only slot that week for the employee. 3. Publish the Schedule and send it to the employee. Open the outgoing mail to access the link to the planning view. Issue: the slot is not visible in the week view. **Cause** https://github.com/odoo/enterprise/blob/04a885dbb6eed96297cb5ce9a155ebf8e169427c/planning/controllers/main.py#L193-L194 The `event_hour_min` and `event_hour_max` returned by `planning_get` and used to control the min/max hours displayed in the week view, didn't account for slots over multiple days. For a slot between 20pm and 4am, the `event_hour_max` should be the end of the day, and the `event_hour_min` should be the start of the day. **Solution** - we change the `event_hour_min` and `event_hour_max` for multi-day slots to display the full days in the week view - the previous point has the drawback of displaying the full days for non-flexible employees even when not necessary. This is because `slots_start_datetime` and `slots_end_datetime` contained the `planning.slot` start and end. Instead, we can look at the actual slot values displayed (by `_get_slots_vals`). For example, a 5 day slot for a non-flexible employee may contain actual slot values corresponding to a typical 8-17 working day. opw-5245985 Forward-Port-Of: odoo/enterprise#99784
This update resolves an issue where the batch view in the Enterprise module incorrectly displayed multiple 'Validate' buttons. The fix ensures that only one 'Validate' button is visible, streamlining the quality check process for users. This improves usability and prevents confusion.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/enterprise#107993
16 changes
Resolved issues and error corrections
This update fixes an issue where creating users for employees with identical email addresses would cause an error. The change now displays a warning instead, improving the user experience and preventing data entry disruptions. This ensures smoother employee onboarding processes.
Original PR description
Creating users for multiple employees sharing the same email address raises a traceback.
Stpes to reproduce the error:
- Install the ``hr`` module
- Create two employees with the same email
- Go to List view of employees > Select both employees > Actions > Create user
Traceback:
```py
ValueError: UniqueViolation('duplicate key value violates unique constraint "res_users_login_key"
```
https://github.com/odoo/odoo/blob/0bfd2a253781e43b0e0d16b3fd9d1df485f4fa6b/addons/hr/models/hr_employee.py#L389
The error occurs because the same email is used as the login for multiple users.
This commit ensures that when multiple employees share the same email address,
a warning notification is displayed instead of raising an error.
sentry-7324335174
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects an issue where cancelled vendor bills were incorrectly included in the Sweden (l10n_se) SIE export file. The fix ensures that cancelled transactions are properly excluded, aligning the export data with the general ledger. This prevents discrepancies in reporting.
Original PR description
Steps to reproduce: - Install l10n_se (Sweden - Accounting). - Create a Vendor Bill with a line using Account 4000 (Cost of goods) for any amount (e.g., 10,000 SEK). - Confirm/Post the bill. - Cancel the bill. - Go to Accounting > Reporting > SIE Export and generate the export for the current year. - Open the downloaded .se file and locate the #RES line for Account 4000. Expected: The balance should be 0.00 (cancelled entries must be ignored, matching the GL). Actual: The cancelled amount (10,000) is incorrectly summed into the exported balance. opw-5901999 Forward-Port-Of: odoo/enterprise#108767
This update resolves an issue where employees were incorrectly appearing in payslip generation reports due to a misinterpretation of contract status. The fix ensures that employees are only included if they have an active contract matching the selected salary structure type, improving the accuracy of payslip calculations. This ensures correct payroll processing.
Original PR description
**Steps to reproduce** - Create an employee - Have a first contract in "New" state covering some period of the month with "Salary Structure Type" A. - Have a second contract in "Running" state…
**Steps to reproduce** - Create an employee - Have a first contract in "New" state covering some period of the month with "Salary Structure Type" A. - Have a second contract in "Running" state covering some other period of the month with "Salary Structure Type" B. - Go to the payslip batch for the current month and click on "Generate payslips". - In the wizard, select "Salary Structure Type" B: employee appears in the list as expected. - In the wizard, select "Salary Structure Type" A. - Unexpected: employee appears in the list, although the contract using that structure type is not in an open or closed state. **Cause** Employees were displayed if they had a contract in open/close state AND a contract with the matching structure type, but we need to check if there's some contract matching both conditions (correct state AND matching structure type). A new function is added to be able to inject an extra domain. opw-5443624 Forward-Port-Of: odoo/enterprise#110027 Forward-Port-Of: odoo/enterprise#104016
This update resolves an issue where the batch view in the stock picking module incorrectly displayed multiple 'Validate' buttons. The fix ensures that only one 'Validate' button is visible, streamlining the batch creation process and preventing user confusion. This improves the user experience for creating and managing batches.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/odoo#249581
This update resolves an issue where the batch view in the Odoo Enterprise system incorrectly displayed multiple "Validate" buttons. The fix ensures that only one "Validate" button is visible, streamlining the quality check process for users. This improves usability and prevents confusion.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/enterprise#107993
This update corrects a test failure within the Odoo Enterprise system. The issue occurred when the 'accountant' module was not present, leading to an incorrect expected account value. This fix ensures the test runs successfully, improving the stability and reliability of the payment processing functionality.
Original PR description
Currently test_bank_rec_widget_batch_foreign_currency_journal_without_entries fails when `accountant` module is not installed because the expected account differs opw-5887218
This update corrects a display issue where the 'Relationship' field was incorrectly shown for employees outside of Indian companies. The fix ensures this field is only visible for employees associated with Indian businesses, aligning with localization requirements. This improves data accuracy and user experience.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country . ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254162
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees associated with non-Indian companies, ensuring data accuracy and a better user experience.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 Forward-Port-Of: odoo/enterprise#109775
This update corrects a bug preventing the partner autocomplete feature from recognizing valid Non-Resident (NRI) GSTINs. The fix updates the validation logic to accommodate newer GSTIN formats, ensuring accurate tax ID input for NRI customers. This improves data accuracy and streamlines the company setup process.
Original PR description
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete`…
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete` modules. - Navigate to Settings > Users & Companies > Companies. - Click `New` and set `Tax ID` to `9922JPN29001OSU`. - Wait for 5–10 seconds. **Observation:** The partner autocomplete does not trigger, although it is valid and verifiable on the official GST portal: https://services.gst.gov.in/services/searchtp **Root Cause:** The issue was already fixed in core validation by PR [1], but the GSTIN validation logic used in partner autocomplete was not updated. At [2], the GSTIN validation regex for NRI taxpayers only supports formats ending with `NRX` (X = any alphanumeric character). However, certain valid GSTINs follow a revised structure and therefore are not matched by the existing regex. **Fix**: This commit ensures that valid NRI GSTIN formats are accepted during validation by applying a fix similar to [1] to the partner autocomplete GSTIN validation at [2]. Related IAP PR: https://github.com/odoo/iap-apps/pull/1491 [1]: https://github.com/odoo/odoo/pull/251760 [2]: https://github.com/odoo/odoo/blob/3016c08a7aa8701ec9b0092b5aafc282b16dd9f3/addons/partner_autocomplete/static/src/js/partner_autocomplete_core.js#L36-L52 Forward-Port-Of: odoo/odoo#253799
This update resolves an issue where popups wouldn't close when the Escape key was pressed. The fix ensures the Escape key event is correctly routed to Bootstrap's modal handler, regardless of whether the popup contains interactive elements. This improves the user experience by allowing users to easily close popups.
Original PR description
Steps to reproduce: =================== - Add a Popup snippet to a page - Remove all links/buttons inside the popup - Save and wait for the popup to appear - Press ESC -> Nothing happens. Cause:…
Steps to reproduce:
===================
- Add a Popup snippet to a page
- Remove all links/buttons inside the popup
- Save and wait for the popup to appear
- Press ESC
-> Nothing happens.
Cause:
======
https://github.com/odoo/odoo/blob/a922c31fa7ccd1107b31287ab1f75697fae874f8/addons/website/static/src/snippets/s_popup/000.js#L219-L226 when the popup contains no tabbable elements, `this.el.focus()` was called. `this.el` refers to the `.s_popup` div, not the `.modal` element that Bootstrap monitors for keyboard events. As a result, the ESC keydown event never reached Bootstrap's handler and the modal stayed open.
When focusable elements (links, buttons) were present, `tabableEls[0].focus()` correctly focused an element inside `.modal`, so ESC worked fine in that case.
Solution:
=========
Replace `this.el.focus()` with `this.el.querySelector(".modal").focus()` so focus lands on the `.modal` element allowing Bootstrap's built-in ESC handler to fire correctly in all cases
opw-5891054
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#253694
Forward-Port-Of: odoo/odoo#250050This update resolves an issue where downpayment products weren't correctly linked to sales order lines. The fix ensures that downpayment products are properly associated with downpayment lines during the sales order creation process, allowing for accurate downpayment tracking and settlement. This improves the functionality of the POS system.
Original PR description
Step to reproduce - install pos_sale - create a SO (make sure it is in draft) - open pos, make sure it has downpayment product - do a downpayment for that SO - go to backend, open SO Observation: - The downpayment product is not linked to downpayment line Cause: - After refactor [1], downpayment product is not added in sale line [1] https://github.com/odoo/odoo/commit/175daa5db6a3f16be6b636a36e2b8462306b2eb4 Fix: - Added the product when creating downpayment line **Note:** - Actual issue reported was different, and was side effect of this issue - there, the downpayment was not considered when trying to settle SO from pos opw-5934461 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a technical issue where archived partner data was incorrectly included during bank statement retrieval. Now, the system only considers active partners when matching bank statements, ensuring accurate data and preventing potential errors in financial reporting. This improves data integrity.
Original PR description
Description of the issue this commit addresses: Partner auto-detection on statement lines could match archived partners via SQL causing unexpected partner_id assignment. Desired behavior after this commit is merged: Partner retrieval from bank account, partner name, and previous statement lines only considers active partners, preventing archived matches. runbot-238918
This update ensures that NACHA payment files accurately reflect the actual account holder's name, rather than the customer's name in Odoo. Prioritizing the bank account holder's name improves payment processing accuracy and compliance with NACHA regulations.
Original PR description
The NACHA entry detail was using the partner's name (res.partner.name) for the Individual Name field. This should instead prioritize the Account Holder Name (acc_holder_name) from the bank account, as this reflects the actual name on the bank account which may differ from the partner's name in Odoo. The code now uses bank.acc_holder_name if set, and falls back to payment.partner_id.name if not set. Forward-Port-Of: odoo/enterprise#108414 Forward-Port-Of: odoo/enterprise#105582
This update fixes a problem where large image uploads would cause errors and disrupt the user experience. Now, uploads can be safely aborted, preventing unexpected behavior and ensuring a cleaner, more reliable image upload process. Users will no longer encounter broken states after attempting to discard an upload.
Original PR description
Steps to Reproduce: 1. Open the website module. 2. Open the media upload dialog to upload an image by either double-clicking the logo or replacing the existing image. 3. Upload a large file. 4. Abort…
Steps to Reproduce: 1. Open the website module. 2. Open the media upload dialog to upload an image by either double-clicking the logo or replacing the existing image. 3. Upload a large file. 4. Abort the upload before it finishes by clicking the 'Discard' button in the media dialog box. After performing these steps, a traceback is observed. Before this commit: - Image upload failures would throw uncaught exceptions. - These exceptions would interrupt the flow and result in a poor user experience with no clear feedback. - Even after clicking the discard button the image was still getting uploaded. After this commit: - Uploads can be safely aborted when the media dialog is discarded. - Ongoing XHR requests and RPC calls are properly cancelled. - The upload loop stops immediately when an abort is triggered with no traceback. - Users get a predictable and clean exit instead of a broken state. - Files are no longer uploaded after clicking Discard. ### task-4752497 Forward-Port-Of: odoo/odoo#249245 Forward-Port-Of: odoo/odoo#219081
This update fixes a minor typographical error in the Odoo documentation related to the 'Departement' field within the country state help string. This ensures consistent and accurate information for users selecting their location. The change was made based on previous feedback and has been reviewed and approved.
Original PR description
Fixes #202198 Split from #249963 per reviewer feedback. **CLA sign-off:** Individual CLA signed (doc/cla/individual/vedantmadane.md) Forward-Port-Of: odoo/odoo#253224
This update corrects a display issue where the CLABE field was appearing twice on the bank account form for Mexican companies. This change ensures accurate data entry and reporting for Mexican businesses using the Odoo system. The fix removes a redundant view that caused the duplication.
Original PR description
Currently, the CLABE field appears twice in the bank account form for mexican companies. **Steps to reproduce:** - Install the `l10n_mx` module and switch to the `ESCUELA KEMPER URGATE` company. - Go…
Currently, the CLABE field appears twice in the bank account form for mexican companies. **Steps to reproduce:** - Install the `l10n_mx` module and switch to the `ESCUELA KEMPER URGATE` company. - Go to Invoicing > Customers > Customers and open any company partner. - Open the `Invoicing` tab. - For `Banks`, enter any number and click `Create and edit...`. **Observation:** The `CLABE` field is displayed twice in the bank account form. **Root Cause:** In previous versions, Banks were displayed as `lines` in the contact form. However, starting from `saas-18.2`, Banks are displayed as a `regular field with an internal link` that opens the bank form view. After commit [1], the view at [2] indirectly inherits from `base.view_partner_bank_form`, while the view at [3] directly inherits from the same base view. Both views add the field `l10n_mx_edi_clabe`, resulting in the `CLABE` field being displayed twice for Mexican companies. **Fix:** Since removing an XML view is not considered a stable solution, in the stable versions, so we make this field invisible. In the master, removes the redundant inherited view [2]. [1]: https://github.com/odoo/odoo/pull/187357/commits/05575b10d90cedb1ca9910aaa9f1293c3fafdd26 [2]: https://github.com/odoo/odoo/blob/6c0baa2a976eace1f414731d66674243e90664f2/addons/l10n_mx/views/partner_view.xml#L1-L13 [3]: https://github.com/odoo/odoo/blob/6c0baa2a976eace1f414731d66674243e90664f2/addons/l10n_mx/views/res_bank_view.xml#L15-L25 opw-6014799 Forward-Port-Of: odoo/odoo#252963
2 changes
Resolved issues and error corrections
This update fixes a problem where users were receiving duplicate push notifications from Social Marketing. The fix ensures notifications are displayed only once by adjusting how Firebase and the service worker interact. It also resolves a subscription error, improving push notification functionality across browsers.
Original PR description
When the user sends a push notification through Social Marketing, the application displays two notification popups because: 1. The Firebase SDK automatically displays a notification popup if the…
When the user sends a push notification through Social Marketing, the application displays two notification popups because: 1. The Firebase SDK automatically displays a notification popup if the request made to Firebase includes a `notification` field. 2. Our service worker displays a notification popup when receiving a background message from Firebase. To prevent duplicate notifications, we will remove the custom event listeners in the service worker and update the request made to Firebase so that the Firebase SDK opens a notification for us. Furthermore, this PR fixes the error `Failed to execute 'subscribe' on 'PushManager': Subscription failed - no active Service Worker` occurring when the user accepts the push notifications. To fix that issue, we will: 1. Ensure that the service worker reaches the `ready` state before communicating with it. 2. Set the service worker's scope to `/` so it controls all pages on the origin, ensuring push subscriptions succeed and the worker can communicate with any page. Finally, we will use the legacy `importScripts` syntax to load Firebase dependencies because the ECMAScript module syntax is not supported for service workers in Firefox. This approach improves push notification compatibility across browsers. Task-5124645 Forward-Port-Of: odoo/enterprise#96029
This update resolves an issue where long tax amounts on invoices were causing display problems. The fix ensures that tax totals are correctly rendered, regardless of the number of digits, improving the clarity and accuracy of revenue reports for Kenyan businesses using the Odoo Enterprise system. This enhancement focuses on a user experience improvement.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#110649 Forward-Port-Of: odoo/enterprise#100319
2 changes
Resolved issues and error corrections
This update ensures that follow-up emails for invoices now send the actual invoice PDF attachment, rather than relying on the main attachment. This prevents issues where users might have uploaded alternative PDF files, ensuring accurate and complete invoice information is sent to customers. This resolves a previous bug related to attachment selection.
Original PR description
Before, the followup emails used the Invoice's main attachment. This is not correct because a user might have uploaded an arb PDF. Only the actual PDF should be sent. Use `invoice_pdf_report_id` instead of `message_main_attachment_id`. opw-5126420 Forward-Port-Of: odoo/enterprise#110753 Forward-Port-Of: odoo/enterprise#98820
This update fixes an issue where multiple email addresses associated with a contact were being overwritten when creating a helpdesk ticket. The change ensures that only the primary email address is used, resolving a potential data inconsistency. This improves the reliability of ticket assignments and communication.
Original PR description
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce:…
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce: ------------------------------ 1. Install Helpdesk module 2. Open Helpdesk Team > Settings 3. Inside Channels, Set the mail used for the incoming server and the alias created 4. Set Accept Emails From to Everyone 5. Create a new contact with multiple emails (eg: `a@b.com`, `c@d.com`) 6. From Fiest mail (eg: `a@b.com`), Send one mail to mail set in the helpdesk team alias mail. 7. Open Incoming mail sever > Click on Fetch Now 8. Open Created Contact Observation: ------------------------------ The contact's email field is overwritten. The second email address (e.g. `c@d.com`) is lost Issue: ------------------------------ After `create`, since `partner_email` was stored with a value that differs from `partner_id.email`, the inverse method `_inverse_partner_email` kicks in. This is where `_get_partner_email_update()` is called. In `_get_partner_email_update()` `tools.email_normalize()` only handles a single email. When the partner has multiple email, the normalization keeps both, while the ticket email normalizes to just have one mail. The strict `!=` comparison fails, triggering the unwanted update. https://github.com/odoo/enterprise/blob/7c23efafe368787c858db31cec075f642ae6715b/helpdesk/models/helpdesk_ticket.py#L363-L369 Solution: ------------------------------ Instead of comparing the full normalized strings, we should check whether the ticket's normalized email is contained within the set of the partner's normalized emails Note for reviewer ----------------------------- After discussion with the PO (LNA), his opinion is that having multiple email addresses in a single field is not a good practice. This use case is only semi-supported in Odoo, it may work in some cases, but it is not reliable. The recommended approach is to create separate contacts for each email address. That said, we should also avoid automatically clearing or altering the existing value in the field. Based on this, I have implemented a minimal fix that prevents altering the existing value in the field. I am leaving it up to the review to decide whether this fix is worth keeping from a technical standpoint. opw-5478067 Forward-Port-Of: odoo/enterprise#107808
18 changes
Resolved issues and error corrections
This update corrects a technical error in the l10n_cl module for Odoo versions 18.0 and later. The fix prevents a broken view from causing issues during upgrades, ensuring smoother rolling releases and reducing manual database checks for developers. This improves the stability and reliability of invoice generation for Chilean businesses.
Original PR description
There is a broken xpath in l10n_cl.report_invoice_document When the l10n_cl module is installed, it results in the faulty view being applied to v18 and later versions. This is particularly annoying because some rolling releases fail because a view with invalid locator is found. The view won't be disabled after a rolling release upgrade and many developers will be spared from checking the databases manually.
This update resolves a technical issue where the delivery process would fail if Sendcloud didn't respond to shipping price requests. The fix prevents an error from occurring, ensuring more reliable delivery calculations and reducing potential disruptions to order processing. This improves the overall stability of the delivery module.
Original PR description
Sendcloud sometimes doesn't respod when asking for `shipping-price`. So when we try to retrieve the first element of the response, we raise an `IndexError`. ----- Ticket: opw-5951749
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees associated with non-Indian companies, ensuring accurate data presentation.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country . ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254162
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees associated with non-Indian companies, ensuring data accuracy and a consistent user experience.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 Forward-Port-Of: odoo/enterprise#109775
This update fixes an issue where imported invoices incorrectly matched purchase orders when only part of the ordered quantity had been received. The change adds a crucial check to ensure invoice quantities align with the actual delivered quantities, preventing mismatched records and improving data accuracy. This ensures consistent reporting and avoids discrepancies between invoices and purchase orders.
Original PR description
## Issue: When a Purchase Order is created for a quantity of 2 and only 1 unit is received, importing a vendor bill with quantity 2 and the same unit price incorrectly results in a full match The PO…
## Issue: When a Purchase Order is created for a quantity of 2 and only 1 unit is received, importing a vendor bill with quantity 2 and the same unit price incorrectly results in a full match The PO is linked, but the bill line quantity is overwritten to 1 (the received quantity), leading to an inconsistency between the imported bill and the original document ## Cause: In `_match_purchase_orders()`, a match is performed based on `partner_id` and `amount_total`: https://github.com/odoo/odoo/blob/92a3fe87c711f18d955ddf454ce1f4194dfcda20/addons/purchase/models/account_invoice.py#L429-L439 However, the previous safeguard logic related to `total_match` is missing: https://github.com/odoo/odoo/blob/92a3fe87c711f18d955ddf454ce1f4194dfcda20/addons/purchase/models/account_invoice.py#L388-L400 This check is not only meant to compare total amounts; it should also ensure that the `amount_to_invoice` is consistent When the purchase method is based on received quantities, the full ordered quantity should not be considered a full match if part of it has not yet been delivered ## Steps to reproduce: We'll use the default company as vendor, choose depending on your setup - Install `purchase` - Create a Product (invoicing policy: ordered qty, and control policy: delivered qty) - Create and confirm a PO (Vendor: Default Company, Product: Created Product, Quantity: 2, Unit Price: 100) - Set the received quantity to 1 - Create and post an Invoice (Customer: Default Company, Product: Created Product, Quantity: 2, Unit Price: 100) - Download the PDF - Go in Bills and import the PDF Before the fix, the match should be done and there is a quantity mismatch opw-5043054
This update resolves an issue where the Public Administration (PA) invoice status wasn't correctly updated after SDI validation, leading to potential rejection errors. The fix ensures that the PA status accurately reflects the invoice's real-time state, improving data consistency and reducing processing delays. This change impacts Italian VAT compliance.
Original PR description
### Issue: After the SDI validation, the state was never updated to match the PA state, resulting in a mismatch with the actual status ### Cause: When `l10n_it_edi_state` is set to `forwarded`, the cron `cron_l10n_it_edi_download_and_update` doesn't consider that a new state could occur However, invoices sent to Public Administration can still be rejected after being forwarded It is not possible to reproduce the issue with the demo system, as it only sets the state to `forwarded` Ticket [link](https://www.odoo.com/odoo/project.task/5391891) opw-5391891
This update corrects a recent change that removed the ability to click on component lots within the traceability report. The initial removal was a poor workaround to limit breadcrumb size, and this fix restores the intended functionality. This ensures users can fully trace components within the traceability report.
Original PR description
commit d7f81c25555c800bf296da2507d010257292aa55 It was removed in order to limit the breadcrump size. However it was a stupid solution and it's better to let the feature rather than limiting the breadcrump size.
This update simplifies invoice processing by automatically enabling self-billing functionality within the core Odoo account module. Previously, this required a separate module. Additionally, the xRechung integration has been removed, ensuring invoices are only sent to government entities as intended.
Original PR description
Everybody is now able to receive self billing invoices even without the additional module. So the service should be added to the base module. Also remove xRechung because users are not supposed to receive it, only government. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where certain valid Non-Resident (NRI) GSTINs were not recognized during the partner auto-complete process. The fix updates the validation logic to accommodate newer GSTIN formats, ensuring accurate identification of NRI tax IDs. This improves the usability of the company creation feature for users with NRI tax registrations.
Original PR description
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete`…
Currently, certain `valid GSTINs` for Non-Resident taxpayers are not recognized by the partner `autocomplete` feature. **Steps to reproduce:** - Install the `l10n_in` and `partner_autocomplete` modules. - Navigate to Settings > Users & Companies > Companies. - Click `New` and set `Tax ID` to `9922JPN29001OSU`. - Wait for 5–10 seconds. **Observation:** The partner autocomplete does not trigger, although it is valid and verifiable on the official GST portal: https://services.gst.gov.in/services/searchtp **Root Cause:** The issue was already fixed in core validation by PR [1], but the GSTIN validation logic used in partner autocomplete was not updated. At [2], the GSTIN validation regex for NRI taxpayers only supports formats ending with `NRX` (X = any alphanumeric character). However, certain valid GSTINs follow a revised structure and therefore are not matched by the existing regex. **Fix**: This commit ensures that valid NRI GSTIN formats are accepted during validation by applying a fix similar to [1] to the partner autocomplete GSTIN validation at [2]. Related IAP PR: https://github.com/odoo/iap-apps/pull/1491 [1]: https://github.com/odoo/odoo/pull/251760 [2]: https://github.com/odoo/odoo/blob/3016c08a7aa8701ec9b0092b5aafc282b16dd9f3/addons/partner_autocomplete/static/src/js/partner_autocomplete_core.js#L36-L52 Forward-Port-Of: odoo/odoo#253799
This update resolves a problem where tours on the website weren't loading translations correctly, particularly in newer Chrome versions. The change introduces a temporary step to ensure translations load before the tour begins, preventing delays and ensuring a smoother user experience.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/odoo#253896
This update resolves a problem where the website's tour process was experiencing delays loading translations, particularly with recent Chrome versions. The fix adds a temporary step to ensure translations load before the tour begins, improving the overall user experience and preventing tour interruptions.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/enterprise#110648
This update corrects a bug that caused incorrect hour calculations in the Gantt view for flexible work schedules. The issue stemmed from timezone discrepancies between employee calendars and the system, leading to inflated hour displays. The fix ensures accurate hour calculations regardless of timezone differences.
Original PR description
Description: ------------------ When viewing attendance in Gantt view with flexible working schedules, expected hours displayed incorrectly when device, company, and employee calendar timezones differ (e.g., 1 day shows 16h instead of 8h). Root cause: ------------------ Two related timezone handling issues: 1. Gantt passes UTC boundaries that span multiple calendar days when converted to calendar timezone 2. Resource calendar creates flexible intervals using wrong timezone (employee timezone instead of calendar timezone) Solution: -------------- - hr_attendance_gantt: Normalize date boundaries to full calendar days in calendar timezone before passing to interval calculation - resource: Force flexible hours block to consistently use calendar timezone for date extraction and interval creation opw-5241330
This update fixes an issue where attendance hours were incorrectly calculated when employees and companies had different time zones. The change ensures accurate hour calculations for flexible work schedules by consistently using the company calendar timezone. This improves the reliability of attendance tracking.
Original PR description
Description: ------------------ When viewing attendance in Gantt view with flexible working schedules, expected hours displayed incorrectly when device, company, and employee calendar timezones…
Description: ------------------ When viewing attendance in Gantt view with flexible working schedules, expected hours displayed incorrectly when device, company, and employee calendar timezones differ (e.g., 1 day shows 16h instead of 8h). Root cause: ------------------ Two related timezone handling issues: 1. Gantt passes UTC boundaries that span multiple calendar days when converted to calendar timezone 2. Resource calendar creates flexible intervals using wrong timezone (employee timezone instead of calendar timezone) Test update: ------------------- Updated test_no_carried_over_leaves_for_flexible_resource to reflect correct flexible calendar behavior. For flexible calendars, the duration between dates counts inclusive calendar days. Changed the calculation from `days * 24 / hours_per_day` to `(end_date - start_date).days + 1` to properly account for inclusive date counting (e.g., Dec 30 to Dec 31 includes both days = 2 days). Solution: -------------- - hr_attendance_gantt: Normalize date boundaries to full calendar days in calendar timezone before passing to interval calculation - resource: Force flexible hours block to consistently use calendar timezone for date extraction and interval creation opw-5241330
This update corrects a technical issue where the Avatax settings within the accounting module were not correctly identifying the company type. This ensures accurate tax calculations and reporting by properly associating Avatax data with the correct company information. It's a minor fix that improves the reliability of financial data.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. task-none Forward-Port-Of: odoo/odoo#254242
This update resolves a test failure caused by an overly sensitive check for a spinning icon. The change removes the problematic trigger, ensuring tests run reliably even with minor delays in the restaurant preparation process. This improves the stability of the restaurant preparation display feature.
Original PR description
In this commit: = - Removed the trigger that checks for `fa-spin` as it was causing test failures when minor delays occurred between steps. - Checks for `fa-spin(Sync)` is alredy handled by the `isSynced` or `waitRequest`. Runbot-error: [198580](https://runbot.odoo.com/odoo/error/198580), [234025](https://runbot.odoo.com/odoo/error/234025)
This update fixes a bug that prevented users from creating backorders when using batch transfers with specific picking configurations. The issue stemmed from an 'incompatible types' error during batch validation. Now, users can successfully create backorders without encountering this error.
Original PR description
Scenario: - Create two pickings with same partner with at least two moves each, the picking type should have auto_group and auto_confirm - Add to a batch transfer - Change the quantity on a move line, unlink the other - Validate the batch ### Before this PR - Clicking "create backorder" the "incompatible types" error appear because tries to assign the batch currently validating to the backorder picking ### After this PR - No error appear --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A test was failing due to inconsistencies in how the system recorded time. This update ensures a consistent and reliable measurement of the 120-second delay required for bill retry attempts, preventing future test failures and improving the stability of the l10n_pl_edi module.
Original PR description
The test `TestL10nPlEdi.test_l10n_pl_edi_download_bill_retry_after` was failing with a stack like following, because the `now()` time was taken after the cron was executed, making the time diff sometimes shorter than the required 120s.
```
FAIL: TestL10nPlEdi.test_l10n_pl_edi_download_bill_retry_after
Traceback (most recent call last):
File "/data/build/odoo/addons/l10n_pl_edi/tests/test_l10n_pl_edi.py", line 619, in test_l10n_pl_edi_download_bill_retry_after
self.assertGreaterEqual(capt.records[-1].call_at, fields.Datetime.now() + timedelta(seconds=120))
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: datetime.datetime(2026, 2, 21, 4, 20, 7) not greater than or equal to datetime.datetime(2026, 2, 21, 4, 20, 8)
```
runbot-241016This update fixes a minor typo in the Odoo system's help text for selecting country states. The previous error ('Departement') has been corrected to the accurate term ('State'). This ensures users receive correct guidance when configuring location settings, improving data accuracy and usability.
Original PR description
Fixes #202198 Split from #249963 per reviewer feedback. **CLA sign-off:** Individual CLA signed (doc/cla/individual/vedantmadane.md) Forward-Port-Of: odoo/odoo#253224
8 changes
Resolved issues and error corrections
This update corrects a display issue where the 'Relationship' field was incorrectly shown to employees outside of India. The fix ensures that this field is only visible for employees associated with Indian companies, aligning with local tax regulations and improving data accuracy.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country . ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees linked to non-Indian companies, ensuring accurate data presentation.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country. ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888
This update corrects a bug where public time off end dates were incorrectly calculated when start dates were set to midnight. The fix ensures the end date accurately reflects the intended duration, resolving a validation error and preventing incorrect scheduling. This improves the reliability of time off management.
Original PR description
## Short functional explanation of the error When creating a public Time off for a Working Schedule, the end date will automatically set to a moment earlier than the set start date if the start date…
## Short functional explanation of the error When creating a public Time off for a Working Schedule, the end date will automatically set to a moment earlier than the set start date if the start date hour is set to midnight sharp. ## Reproduction Steps 1. Go to Employees. 2. Click on Configuration tab > Working Schedules. 3. Select a Working Schedule. 4. A smart button Public Time Off should appear. Click on it. 5. Click New and select a Start Date with a random date but 00:00:00 as hours:minutes:seconds. ### Expected behavior The End date should automatically set 23 hours 59 minutes and 59 seconds later. ### Unexpected behavior A Validation error occurs and the end date is set 1 second before the start date. ## Origin of the issue When setting automatically the end date of a leave, it is set to 23:59:59. With our timezone, if we select midnight, this time will be converted to 23:00:00, the day before: https://github.com/odoo/odoo/blob/e85f1a182ee60a25905369c84ced05480c5a3360/addons/resource/models/resource_calendar_leaves.py#L69-L70 Thus, the resulting end date will be set to the day before, at 23:59:59. Additionally, we have to take into account the timezone of the user to set a consistent end date, and not the generic utc one. __ opw-5187977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a memory issue that occurred when propagating deliveries across multiple lots in the stock module. The fix addresses a situation where processing large delivery sets (containing thousands of picking IDs) caused the system to run out of memory, particularly when dealing with complex lot relationships. This ensures smoother and more reliable delivery processing for large inventory operations.
Original PR description
- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents. - Updating parent sets in a single operation caused a MemoryError for large datasets. ```sql…
- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents.
- Updating parent sets in a single operation caused a MemoryError for large datasets.
```sql
Traceback (most recent call last):
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 539, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3858, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4089, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7078, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1311, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1493, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 442, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5297, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 149, in _compute_delivery_ids
delivery_ids_by_lot = self._find_delivery_ids_by_lot_iterative()
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 385, in _find_delivery_ids_by_lot_iterative
delivery_by_lot[parent_id].update(delivery_by_lot[lot_id])
MemoryError
(Pdb)len(all_lot_ids)
22166
(Pdb)len(barren_lines)
9682
(Pdb)len(lots_to_propagate)
9682
Lot_id 11412: delivery_by_lot size = 7420, parents = 3
Lot_id 11753: delivery_by_lot size = 0, parents = 7
Lot_id 12845: delivery_by_lot size = 11, parents = 5
Lot_id 14646: delivery_by_lot size = 12, parents = 2
Lot_id 15801: delivery_by_lot size = 1700, parents = 3
Lot_id 19817: delivery_by_lot size = 0, parents = 4
Lot_id 22370: delivery_by_lot size = 0, parents = 1
Lot_id 25072: delivery_by_lot size = 6827, parents = 2
Lot_id 25134: delivery_by_lot size = 3, parents = 2
Lot_id 25135: delivery_by_lot size = 1, parents = 2
```
- Previous fix adds all child deliveries, even if some already exist, but this new patch adds only the missing ones
UPG - 3869661
OPW - 5900313
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update enhances the security and performance of the calendar module by adding a required CSRF token to form submissions and streamlining data handling. The changes optimize how calendar actions are processed, improving overall system efficiency. This resolves a previous vulnerability and ensures smoother operation.
Original PR description
Add a csrf token in the form which is required for post requests. Additionally, post requests form values are stored on the form attribute of the request rather than args which makes the keep_query implementation janky, as the form is only filled if coming from a get url. Instead just keep using keep_query in the action, only including csrf in post values. Finally a couple action urls were missed in mail templates. related: 0e57ff9cbc87c83276bdb823c5fb08cd4d2806f9 task-4555579
This update strengthens the security of our appointment booking system by adding a required CSRF token to form submissions. It also aligns with standard Odoo practices by using 'keep_query' in the form URLs, which helps prevent unauthorized access. This ensures a more secure and reliable appointment booking experience.
Original PR description
Add a csrf token in the form which is required for post requests. To align with calendar, add the arguments back in the action url of forms and use keep_query which is the more standard approach in the code base and should work for the purpose of detering bots from following the url related: odoo/odoo@0e57ff9cbc87c83276bdb823c5fb08cd4d2806f9 task-4555579
This update resolves an issue where header border widths were inconsistently applied, leading to unexpected full borders. The change standardizes border width input to a single value for typical headers, while still allowing full borders for specific templates. This ensures a consistent and predictable appearance across the website.
Original PR description
Previously, the border width input for headers allowed multiple values. This was required for specific header templates (e.g. rounded box) that use a full border. However, most headers only apply a border on the bottom. When the input had multiple values, the scss would break, resulting in full border. This change ensures that, for headers without the .o_full_border class, only the first value of the saved border width is used. As a result, the input behaves like a single-value field (similar to font size inputs) for standard headers, while still supporting multiple values for templates that require a full border. Steps to reproduce the issue: - Go to Edit mode - Click on the Header - In the Border option, enter "1 2" and leave the input to validate => The input display "3" and the header has a full border. task-5500516
This update corrects a validation error in the ZATCA XML generation for Saudi Arabia companies. The change ensures that invoice cash rounding is included in the payable amount calculation, resolving a mismatch that was causing validation failures. This ensures accurate tax reporting and compliance.
Original PR description
Currently the generated ZATCA XML is not accounting for invoice cash rounding, leading to an invoice validation issue due to a mismatch in the calculation of PayableAmount. Steps to reproduce: - Have a SA Company setup - Create a [cash rounding] with strategy 'Add invoice line' and rounding 1.00 (UP) - Create an invoice for 99.55 + 15% Tax - Set Cash Rounding Method to [cash rounding] - Confirm and send xml for validation Issue: Validation will issue the following warning `[202] BR-CO-16 : Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Pre-Paid amount (BT-113) + Rounding amount (BT-114).` Analysis: The ZATCA implementation was calculating the payable amount strictly as (TaxInclusiveAmount - PrepaidAmount). This change ensures the rounding amount is fetched and added to the total payable calculation opw-5939550