Daily updates from Odoo
Tuesday, January 6, 2026
132 changes · master
New functionality added to Odoo
This update adds key features to the Turkish localization of Odoo's HR payroll module. Specifically, new leave types like maternity, paternity, and bereavement leave have been introduced, along with updated salary rules for annual leave provision and food allowance. These changes align with Turkish labor laws and provide greater flexibility for Turkish businesses.
Original PR description
-Salary rules for Annual leave provision and Food Allowance haven been added. -The following leave types has been added to the Turkish localization: - Maternity leave - Paternity leave - Bereavement leave - Excuse leave. Task #4868680
This update adds a button to the version list view in the HR module, allowing users to quickly access the detailed form for each version. Previously, users could only view versions in a list format, making it difficult to review specific version details. This enhancement streamlines the process of managing versions within the HR system.
Original PR description
In version list view there is no way to access the form of the version. Add a button to open the form view of the version in the list view. task-4992852
This update adds a new button to contract template forms, allowing HR professionals to easily incorporate salary information directly from employee records. This streamlines the contract creation process by eliminating the need to manually enter salary details for employees when using a template, improving efficiency and accuracy.
Original PR description
Add a button in the contract template form view so salary inputs applicable on employees can also be added to a contract template. [task-5156839](https://www.odoo.com/odoo/project/1251/tasks/5156839) Forward-Port-Of: odoo/enterprise#98151
Enhancements to existing features
This update streamlines the calculation of sick leave payments for Saudi Arabia. It consolidates all sick leave rules into a single, simplified process: the first 30 days are fully paid, the next 60 are paid at 75%, and any remaining days are unpaid. This change improves clarity and consistency in payroll processing.
Original PR description
Group all SA sick-leave rules into a single rule. According to the specification: 1. The first 30 days are fully paid. 2. The next 60 days are paid at 75%. 3. Any remaining sick-leave days are unpaid. task-5256311 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update streamlines the calculation of sick leave payments for employees in Saudi Arabia, consolidating previous rules into a single, more straightforward system. The changes ensure accurate deductions or additions based on the type of work entry (calendar or attendance), aligning with labor law requirements. This simplifies payroll processing and improves compliance.
Original PR description
Group all SA sick-leave rules into a single rule. According to the specification: 1. The first 30 days are fully paid. 2. The next 60 days are paid at 75%. 3. Any remaining sick-leave days are…
Group all SA sick-leave rules into a single rule. According to the specification: 1. The first 30 days are fully paid. 2. The next 60 days are paid at 75%. 3. Any remaining sick-leave days are unpaid. Whether the monetary value of the leaves is considered a deduction or an addition depends on the work entry source. If it is a calendar entry, it is treated as a subtraction; if it is an attendance/planning entry, it is treated as an addition. One salary rule was created for the deduction case, and another for the subtraction. According to Article 117 of the applicable labor law, the counting year does not follow the calendar year. Instead, it starts on the anniversary of the employee’s first recorded sick leave. Sick leaves included in a payslip are associated only with their counting year(s). Additionally, they are linked according to the timeline of when the sick leaves were created, not the order in which payslips are generated. This means that creating a payslip in October and then another in November is treated the same as creating one in November and then another in October. Payslip computation considers only the sick leave taken within the payslip period and calculates the deduction/addition amount based on the sick leave’s chronological order. Therefore, taking sick leave in future months before taking leave in the current month will not affect the computation of the current month’s payslip. task-5256311
This update enhances the readability of the salary statement report by redesigning the layout. The changes include improved spacing, simplified table styling, and a summary of total deductions, making the report easier for employees and HR staff to understand.
Original PR description
Purpose: - Redesigned the Salary Statement Report for a cleaner and more readable layout. This PR includes: - Better spacing and alignment - Simplified table styling with light horizontal lines - Added total deduction summary - Improved section headers task-5216143
This update introduces a new salary rule to accurately calculate employee contributions for DEWSEMP in the UAE. The rule has been renamed and hidden from payslips, and a new parameter has been added for configuration. This ensures compliance with local regulations regarding employee deductions.
Original PR description
### changes - Added new salary rule for DEWS employee contribution(DEWSEMP). - Renamed DEWS salary rule to DEWSCOMP with category company contribution. - Hide DEWSCOMP to appear on payslip. - New rule parameter for DWESCOMP. task: 4922217
Resolved issues and error corrections
This update resolves a significant number of lint warnings within the Odoo server code. Addressing these warnings improves the stability and reliability of the server, reducing potential issues and enhancing the overall performance of the Odoo platform. This is an internal improvement focused on code quality.
Original PR description
It is very hard to work with that file due to all the lint warnings. Fix all of them once for all.
This update improves the clarity of our gratuity reports. Now, the report will display how the gratuity amount is calculated, providing greater transparency and accuracy for financial reporting. This change ensures compliance and better understanding of payroll calculations.
Original PR description
Before: - We were not printing any information about how gratuity is being calculated. After: - We are going to print information about how gratuity is being calculated. task-5454700 Forward-Port-Of: odoo/enterprise#103131
This update restricts access to key employee form features like user creation and sensitive data views based on user roles. Previously, HR Officers could perform actions they weren't authorized for, leading to errors. Now, access is correctly controlled, ensuring HR Managers have the necessary permissions and preventing unauthorized actions.
Original PR description
* = hr_work_entry
Steps to reproduce:
- Install 'hr' and 'hr_work_entry'.
- Log in as an HR Officer.
- Open an employee form and click:
- 'Create User'
- 'Work Entries' smart button
- 'History' smart button
Cause:
- 'Create User' was visible to HR Officers, but only users with Settings rights
('base.group_erp_manager') can create 'res.users', causing an AccessError.
- The 'Work Entries' and 'History buttons were visible to HR Officers, but
fields as 'contract_date_start' which only HR Managers can read when
payroll is not installed.
Fix:
- Restricted 'Create User' to 'base.group_erp_manager'.
- Limited the 'History' smart button to 'hr.group_hr_manager'.
- Limited the 'Work Entries' smart button to 'hr.group_hr_manager'.
Task - 5188997
Forward-Port-Of: odoo/odoo#242099
Forward-Port-Of: odoo/odoo#235923This update corrects a previous issue where HR Officers without payroll access could still view and modify salary adjustments data. The changes restrict access to sensitive payroll information and ensure that HR Officers only see data relevant to their role, enhancing data security and user experience. This resolves a potential data access vulnerability.
Original PR description
* = hr_contract_salary Steps to reproduce: - Install 'hr', 'hr_payroll', 'hr_work_entry', and/or 'hr_contract_salary'. - Log in as an HR Officer without payroll access. - On an employee form: -…
* = hr_contract_salary
Steps to reproduce:
- Install 'hr', 'hr_payroll', 'hr_work_entry', and/or 'hr_contract_salary'.
- Log in as an HR Officer without payroll access.
- On an employee form:
- Switch to the 'Salary Adjustments' tab.
- Edit/save a record (tracking reads 'salary_offer_ids').
- Click the 'Work Entries', 'History', or 'Offers' smart buttons.
Cause:
- HR Officers could still reach payroll-only data:
- 'salary_offer_ids' (one2many to 'hr.contract.salary.offer') triggered
tracking reads on a model restricted to HR Managers/Recuriters.
- The 'Salary Adjustments' tab and offer buttons remained visible even when
the user lacked payroll rights.
- The payroll overrides changed 'contract_date_start' to
'hr_payroll.group_hr_payroll_user', so the 'Work Entries'/'History' buttons
show AccessErrors while the buttons stayed visible.
Fix:
- Restricted 'salary_offer_ids' to 'hr.group_hr_manager'.
- Made the 'Salary Adjustments' tab visible only to
'hr_payroll.group_hr_payroll_user' and existing 'Offers' buttons stay for
HR Managers.
- Added dedicated overrides giving 'Work Entries' and 'History' buttons the
'hr_payroll.group_hr_payroll_user' group when payroll is installed.
Task - 5188997
Forward-Port-Of: odoo/enterprise#103276
Forward-Port-Of: odoo/enterprise#99234This update fixes an issue where imported DTE invoices in a multi-company Odoo environment incorrectly assigned tax to the wrong company. The fix ensures that the recipient company's default purchase tax is used, resolving inconsistencies and improving invoice accuracy. This impacts financial reporting and compliance with Chilean tax regulations.
Original PR description
**PROBLEM**
When importing a DTE from mail (using fetchmail) in a multicompany setting, there can be company inconsistencies during the import, i.e. the product created during the import belong to the right company, but the tax on a move line belong to another company.
**STEP TO REPRODUCE**
1. Create 2 CL companies with those VAT number: 22060449-7, 77697621-0
2. Set an incoming mail server for bills
3. Send XML to the mailbox (see in the ticket for the xml, one of them should trigger the bug, it depends on the order you created the companies).
4. Run a fetchmail scheduled action.
**CAUSE**
On the creation of the move line for the DTE bill, we retrieve the default purchase tax using `self.env['account.chart.template'].ref('OTAX_19')`. There is no guarantee this tax belong to the recipient company. We should use the default purchase tax of the recipient company instead.
opw-5378068
Forward-Port-Of: odoo/enterprise#103279
Forward-Port-Of: odoo/enterprise#102274This update resolves a memory error that occurred when processing recurring invoices with a large number of subscriptions. By optimizing how the system retrieves data, the change significantly reduces memory consumption, preventing crashes and improving overall system stability. This results in faster invoice processing and a more reliable system.
Original PR description
A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the…
A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the compute method overwrite `_get_invoiced` in the sale_subscription module can consume a lot of memory. The issue is mostly coming from the search on account.move.line. In case a lot of account.move.lines have a subscription_id, the search to get `all_subscription_ids` is going to return a lot of records. Then, accessing any field on this recordset will prefetch all the prefetchable fields, leading to a MemoryError. This commit fixes that by manually fetching the fields we need on account_move_line. Since `subscription_move_lines` is not used anywhere else and `move_by_origin` only contains ids, the number of queries stays the same while the memory consumption plummets. #### Benchmark In a database with 236 000 account.move.line with a non-null subscription_id, running the schedule action with 5 subscriptions to invoice consumes at least 1.7GB (MemoryError raised). After this commit it consumes 191MB. <img width="1918" height="943" alt="sale_subscription_before" src="https://github.com/user-attachments/assets/e868921f-e691-47c3-8474-edb9a1d22d0b" /> <img width="1920" height="949" alt="sale_subscription_after" src="https://github.com/user-attachments/assets/78e9fc31-4c5f-4369-8bd0-494ca2c693fd" /> Forward-Port-Of: odoo/enterprise#102364
This update resolves a technical issue that prevented accurate reporting of invoice reconciliation data when multiple bank transactions were used. The fix ensures the system correctly handles invoices reconciled with multiple bank statements, preventing a 'ValueError' that impacted reporting accuracy. This improves the reliability of financial reports.
Original PR description
### Issue description: The `_compute_full_amount_switch_html` method assumes that `reconciled_lines_excluding_exchange_diff_ids` contains at most one line (which is true only for move lines of bank statement lines). However, if an invoice is reconciled with multiple bank transactions, when accessing the `full_amount_switch_html` for any move line in the invoice, it triggers `ValueError: Expected singleton`, as the compute method uses the reconciled_lines as if they are a single line. ### Steps to reproduce: 1. Create an invoice 2. Reconcile the invoice with multiple bank transactions. 3. Perform a read on the `full_amount_switch_html` field on the invoice line from the invoice (using the web tool, or add the field to any view). 4. You will get `ValueError: Expected singleton: account.move(XX, XX)` opw-5224135 Forward-Port-Of: odoo/enterprise#103202 Forward-Port-Of: odoo/enterprise#102048
This update ensures our translations are current and optimized for Weblate, the tool we use to manage translations. We cleaned up outdated files and streamlined the translation process, improving the quality and efficiency of our internationalization efforts. This work is part of a larger effort to improve the user experience for our global customer base.
Original PR description
We did the following: - Update the PO files by taking the version from 19.0 and `msgmerge` them with the latest POT file. - Update the `.weblate.json` file to target the right project. - Update the `.weblate.json` file to add/remove modules that were changed. Related: https://github.com/odoo/enterprise/pull/102739 Related: https://github.com/odoo/design-themes/pull/1201 Related: https://github.com/odoo/industry/pull/1460 Related: https://github.com/odoo/documentation/pull/15825 Forward-Port-Of: odoo/odoo#241030
This pull request updates translations for Odoo, ensuring they're compatible with the Weblate translation tool. It cleans up outdated and unused translation files, streamlining the localization process and improving efficiency.
Original PR description
We did the following: - Update the PO files by taking the version from 19.0 and `msgmerge` them with the latest POT file. - Update the `.weblate.json` file to target the right project. - Update the `.weblate.json` file to add/remove modules that were changed. Related: https://github.com/odoo/odoo/pull/241030 Related: https://github.com/odoo/design-themes/pull/1201 Related: https://github.com/odoo/industry/pull/1460 Related: https://github.com/odoo/documentation/pull/15825 Forward-Port-Of: odoo/enterprise#102739
This update adjusts the timing of checks for video calls to prevent accidental disconnections when the Odoo server is temporarily slow. Increasing the check interval allows for a missed ping, ensuring calls continue to function smoothly. This enhances the overall reliability of video communication within Odoo.
Original PR description
Before this commit, the ping to keep rtc sessions alive was done every 30 seconds and had a 1 minute timeframe to successfully ping, which meant that missing a single ping would drop the rtc session. This commit increases the timeframe to 1 minutes and 15 seconds so that one ping can be missed. This can help preventing disconnections when the Odoo server is slow, as calls can work fine without a stable connection to the odoo server (since P2P and SFU connections are independent from Odoo once the connections are initialized). task-5177246 Forward-Port-Of: odoo/odoo#234553
This update resolves an issue that prevented the `website_sale_renting` module from installing correctly. The fix moves a key function to the `sale_renting` module, ensuring compatibility with the installation order and preventing a traceback during setup. This ensures rental pricing functionality works smoothly.
Original PR description
## Steps To reproduce: 1. On a local environment, install **`website_sale_renting`** using `-i website_sale_renting` 2. During installation, the process reaches **`website_sale`**. 3. A traceback is…
## Steps To reproduce: 1. On a local environment, install **`website_sale_renting`** using `-i website_sale_renting` 2. During installation, the process reaches **`website_sale`**. 3. A traceback is raised while loading `website_sale/data/mail_template_data.xml`. --- ## Issue * The installation fails during **`website_sale`** because the mail template calls `_get_rental_pricing_description()` on `sale.order.line`, but the method is not available at that stage. --- ## Cause: * `_get_rental_pricing_description()` existed previously but was defined in **`website_sale_renting`**. * A recent design PR- odoo/odoo#213186 introduced a `t-if="hasattr(combo_line, 'is_rental')"` guard in the `website_sale` mail template. * Since `mail.template`'s body_html data is parsed as HTML, the template cannot be safely extended via XPath in other modules. * Module installation order is: `sale → sale_renting → website_sale → website_sale_renting` * When **`website_sale`** is installed: * `sale.order.line` already has the `is_rental` field (from `sale_renting`) * but `_get_rental_pricing_description()` is not yet present, as it is only loaded with `website_sale_renting` This causes the guard to pass while the method call fails, leading to a traceback during installation. --- ## Solution: * Move `_get_rental_pricing_description()` to the **`sale_renting`** module, alongside the `is_rental` field. * This ensures the method is always available whenever rental logic is enabled and makes `website_sale` mail templates safe regardless of installation order. opw-5454946 Affected Version-saas~19.1 Forward-Port-Of: odoo/enterprise#103138
This update resolves an issue where the version timeline would disappear when zoomed out and introduce a scrollbar when zoomed in. Now, all versions appear correctly regardless of zoom level, providing a cleaner and more intuitive user experience for managing versions.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: . When you zoom-out below 100%, the other versions from the version bar disappear, leaving only the active one . Wen zoom-in, a side vertical scrollbar appear Desired behavior after PR is merged: . all versions on timeline appears normally without sides scrollbar task-5401380 Forward-Port-Of: odoo/odoo#239315
This update resolves an issue where filtering in Odoo's Kanban views would temporarily lose its settings after opening and closing records. The fix ensures that filtered views remain accurate, even after changes are made to related records, improving data consistency and user experience. It achieves this by more reliably trusting the data returned from filtering operations.
Original PR description
Have a kanban view with progressbar and some records. Click on a progressbar to filter a column. Then open a record and come back. From that point, the data of the filtered kanban is in cache. Now,…
Have a kanban view with progressbar and some records. Click on a progressbar to filter a column. Then open a record and come back. From that point, the data of the filtered kanban is in cache. Now, open a record again, and make a change in the form that will have an impact in the kanban (e.g. that will move a record from a column to another). Come back to the kanban view, which will instantly show the data from the cache, and that will be then updated once the rpc returns. At that point, the view is still correct, but the cache callback has already erased the groups information (in particular, the extraDomain of the filtered column). So, if you open a record and come back a last time, the view is no longer correct: the column that is supposed to be filtered displays all records. Introduced by [1] This commit basically reverts [1] and fixes the original issue differently. When we receive the result of a web_read_group, we can trust it and determine that a group for which we receive records (or groups) is open. [1] https://github.com/odoo/odoo/pull/226312 Task~5387553 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#240593
This update corrects a technical issue where pressing `shift+space` in the kanban view caused a system error. Now, users can reliably select kanban records using the keyboard, improving usability and preventing disruptions to workflow. This change ensures a smoother experience for all users navigating the kanban interface.
Original PR description
Before this commit: When navigating the kanban view using the keyboard, pressing `shift+space` for the first time to select a kanban record caused a traceback. After this commit: The traceback no longer occurs, and the kanban record is correctly selected. task-5410164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240389
This update fixes a problem where incorrect error messages were displayed when creating employees with negative fixed allowance values. The fix isolates error handling to payroll validation, ensuring users receive the precise error message needed to correct the issue. This improves data accuracy and simplifies the employee onboarding process.
Original PR description
Issue: * When creating an employee with negative fixed allowance values, the system should show a payroll validation error. * Instead, a leave-related error from hr_holidays always appeared because the module wrapped the entire create() method in a broad try/except, catching all ValidationError messages including those from payroll. Fix: * Restricted the try/except only to the part that actually creates a new leave entries. Impact: * Users now see the correct and relevant error message when the fixed allowance values are invalid. task-5383700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238984
This update fixes an issue where resizing images within website pages broke responsiveness on smaller screens (like mobile). The change ensures images adapt correctly to different display sizes by using percentage-based widths and automatic height adjustments, maintaining image quality across devices.
Original PR description
Problem: On website pages, resizing an image using the transform option breaks responsiveness across display sizes. After resizing on desktop, the image may overflow its container on smaller screens. Cause: The resize logic currently sets both width and height in `px`. Once fixed in pixels on a large screen, the image no longer adapts when the responsive container becomes smaller on mobile. Solution: Use a percentage value for `width` and set `height` to `auto`. This preserves responsiveness while keeping the aspect ratio correct. Using `height: auto` is required because setting both width and height in percentages would still ignore height in practice. Steps to reproduce: - Add a card snippet to a website page. - Resize the image. - Switch the display mode to mobile. - Observe that the image is no longer responsive. opw-5368040 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241416
This update resolves an issue where attachments weren't consistently displayed on leave request forms after saving. The fix addresses a technical limitation in how Odoo handles attachments linked to leave requests, ensuring that attachments are correctly shown when a new request is created or refreshed.
Original PR description
to reproduce: ============= - from form view, create a leave request with an attachment - save the leave request - the attachment is not displayed on the form (reloading the page shows it correctly)…
to reproduce:
=============
- from form view, create a leave request with an attachment
- save the leave request
- the attachment is not displayed on the form (reloading the page shows it correctly)
Problem:
========
- When sving the leave request, we call `web_save` which will handle the creation, then calls `web_read` to read the updated data back from the server.
- Even though `web_read` and `web_save` are called in the same transaction, but `web_read` doesn't see `attachment_ids` because of the limited implementation of Many2oneReference (ir.attachment.res_id):
- Its `_update_inverses` won't be called when the value is changed when `field.write`
- when `record.attachment_ids = attachment`, the ORM won't automatically set `attachment.res_model = record._name`
Solution:
=========
as work arround, we can call `invalidate_recordset` for leave requests after setting `attachment_ids` in `_inverse_supported_attachment_ids` so that `web_read` will read the correct value from database.
opw-5157790
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#233003This update resolves a sporadic test failure related to how partner suggestions are sorted. The fix ensures the test accurately reflects the system's data by waiting for the necessary updates to be processed before verification. This improves the stability and reliability of the suggestion sorting functionality.
Original PR description
Before this commit, the test "Sort partner suggestions by recent chats" fails non-deterministically due to a race condition. This failure occurs because the test relies on the `last_interest_dt` timestamp being updated after sending a message to "User 2". Although the message post triggers a bus notification to update the store, the UI displays the message optimistically. As a result, the assertion for the message's existence occasionally passes before the bus notification was processed, leaving the sorting logic to run with stale data (where "User 2" was still ranked behind "User 3"). This commit fixes the issue by waiting for the sidebar to reorder "User 2" to the top. Since the sidebar ordering relies on the same server data (last_interest_dt) as the suggestion sorting, this ensures the store has processed the bus event before the test verifies the suggestion order. runbot-237553 Forward-Port-Of: odoo/odoo#241690 Forward-Port-Of: odoo/odoo#241619
A recent issue preventing users from correctly navigating the website's carousel tour has been resolved. The fix prevents a technical glitch where pressing 'Enter' caused the tour to fail to load properly. Users can now reliably use the 'Tab' key to move through the carousel steps.
Original PR description
__Before this commit:__ The tour `snippet_carousel_clickable_slides` sometimes fails because the URL anchor does not get removed when Enter is pressed. __Reason:__ When inputting in an `Autocomplete`, the `loadingPromise` is set and it's only resolved after the sources are loaded. If Enter is pressed before it is resolved, the `onchange` event is not fired because [`preventDefault` is called inside `onInputKeydown`][1]. __Fix:__ Use Tab in `snippet_carousel_clickable_slides` instead of Enter because Tab doesn't have this behavior. [1]: https://github.com/odoo/odoo/blob/6c07ba93171eb25be64ef990d047915fac2f3381/addons/web/static/src/core/autocomplete/autocomplete.js#L401 runbot-234687 Forward-Port-Of: odoo/odoo#241914
This update ensures that the bill date is always required when creating invoices. Previously, users could skip this field, leading to potential data inconsistencies. Now, a clear notification will appear if the bill date isn't provided, helping ensure accurate record-keeping and financial reporting.
Original PR description
Make bill date required on form view to display a 'Missing required field' notification when not set. task-5361931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238911
This update fixes an issue where updating the quantity of a parent manufacturing order incorrectly affected the quantity of related child manufacturing orders. The change ensures that quantities are consistently converted to the same UoM (product’s UoM) during calculations, leading to accurate updates for all dependent manufacturing orders. This improves the reliability of production planning.
Original PR description
Problem: When a manufactured product uses a component whose UoM is different from its reference UoM, for example the component’s UoM is dozens but units are used on the BoM line, updating the…
Problem: When a manufactured product uses a component whose UoM is different from its reference UoM, for example the component’s UoM is dozens but units are used on the BoM line, updating the quantity to produce on the parent MO causes the child MO’s quantity to roduce to update incorrectly. This is because the new quantity to produce on the child MO is calculated with quantities in different UoMs. Purpose: To ensure that the child MO’s quantity to produce updates correctly when the parent MO’s quantity to produce is updated. This is achieved by making sure the quantities that get added together are both the same UoM, in this case the product’s UoM. Steps to Reproduce on Runbot: 1. Create product_a with the MTO route and UoM set to pack of 6. 2. Create a BoM for product_a that creates 1 pack of 6 products. 3. Create product_b. 4. Create a BoM for product_b that creates 1 unit and uses 3 units of product_a. Make sure the component line shows 3 units instead of 0.5 pack of 6. 5. Create a manufacturing order for 1 unit of product_b and confirm it. 6. There should be a child MO for 0.5 pack of 6 of product_a. 7. On the parent MO update the production quantity to 2 units. 8. Observe that the child MO is now for 3.5 pack of 6 instead of 1 pack of 6. opw-5414085 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241692
This update fixes a bug that caused Odoo to crash when a user's session information (specifically, the ‘persona’ data) was missing. The change ensures Odoo gracefully handles this situation, improving stability and preventing disruptions to user workflows. This resolves a potential point of failure for users.
Original PR description
<img width="889" height="290" alt="image" src="https://github.com/user-attachments/assets/c2519e22-f7c4-4d53-885d-01674b248260" /> Forward-Port-Of: odoo/odoo#242060
This update fixes inaccuracies in the VAT report formulas used by the l10n_lt module. The changes ensure the report accurately calculates VAT amounts, improving the reliability of financial reporting for Lithuanian businesses using Odoo.
Original PR description
With this PR, some wrong formulas in VAT report will be updated. task-5447677 Forward-Port-Of: odoo/odoo#241802
This update quietly resolves a warning message appearing during Odoo startup related to the `PyKCS11` library. While this warning didn't cause any functional issues, it was generating unnecessary log tracebacks. This change improves Odoo's stability and log clarity.
Original PR description
Importing `PyKCS11` was raising the following warning: ``` py.warnings: <frozen importlib._bootstrap>:488: DeprecationWarning: builtin type SwigPyObject has no __module__ attribute ``` It doesn't cause any issue, but adds two tracebacks in the logs on Odoo startup. This commit simply hides the warning. Forward-Port-Of: odoo/odoo#241740
Code cleanup and technical improvements
This update refactors how group memberships are handled within email channels in Odoo. By moving group IDs to the channel model, we've streamlined the process of managing email communications and ensuring more accurate targeting of recipients. This change enhances the overall efficiency and reliability of our email workflows.