Monday, February 16, 2026
48 changes · saas-19.1
New functionality added to Odoo
This update adds pre-built email snippets to the mass_mailing builder, making it faster and easier for users to create professional emails. Alongside this, UX improvements and bug fixes enhance the builder's usability and performance. These changes streamline the email creation process and improve the overall user experience.
Original PR description
## [IMP] mass_mailing: add new snippets This commit adds several ready-to-use snippets to the mail editor in `mass_mailing` to reduce the time and effort required to build emails. These snippets…
## [IMP] mass_mailing: add new snippets This commit adds several ready-to-use snippets to the mail editor in `mass_mailing` to reduce the time and effort required to build emails. These snippets provide immediate, usable building blocks and help users understand the editor's capabilities without needing to explore or fine-tune block options first. To further improve discoverability and relevance, the snippet categories are slightly reorganized and some existing snippets are revamped to better reflect common email use cases. Finally, this commit adds a new snippet tile in the main editor panel, allowing users to quickly drag and drop an icon into their email. ## [IMP] *: UX Fixes and improvements to mass_mailing builder This commit fixes some UX issues and improves upon the already in place options and snippets. These fixes allow for a better usage of the builder and user-friendlier options for some of the snippets. We reintroduced the PowerButtonsPlugin inside the mass_mailing builder which needed adjustments for the position computations and the calls to the position updates. The position computations didn't take into account that the editable can be inside an iframe. This means that the reference position between an editable in the proper document and an iframe's document could be different as the local overlay doesn't sit at the same position. In the case of the iframe, the local overlay sits right beside the iframe which means that we need to not take into account the buttons position when computing the style attribute. A compensation for the iframeElement's DOMRect was thus added to it when in this case. We also added the editable as permanent part of the scrollable elements inside the `PositionPlugin`. This enables the fullscreen mode to handle scrolling to update the position of the buttons. This commit also removes some usages of the d-flex class as the `display: flex` css property isn't well supported inside email client. Thus, we are starting the cleaning process so that the convert_inline can have an easier job converting the email to a client-friendly format. Task-5380615 Co-authored-by: Thomas Josse (THJO) <thjo@odoo.com> Co-authored-by: Julien Banken (JBN) <jbn@odoo.com> Forward-Port-Of: odoo/odoo#243331
This update ensures Odoo Enterprise complies with new Polish tax reporting requirements mandated by the KAS. Starting in 2025, businesses will need to generate a specific XML file (JPK KR PD) to meet legal accounting standards, avoiding potential penalties and ensuring continued software usability.
Original PR description
Ensure compliance with the new electronic reporting obligations imposed by the Polish National Revenue Administration (KAS). This takes effect starting in 2025 for large enterprises, followed by SMEs with a one-year delay. Local software providers (such as Comarch or InsERT) will natively integrate this standard; failing to do so would expose users to severe tax penalties, rendering the software de facto unusable for legal accounting in Poland Enable the generation of the JPK_KR_PD file in the strict XML format mandated by the Polish Ministry of Finance. task-5163281 Forward-Port-Of: odoo/enterprise#100345
Enhancements to existing features
This update ensures Odoo complies with new Polish tax reporting requirements mandated by the KAS. Starting in 2025, businesses will need to generate specific electronic reports, avoiding potential penalties and ensuring continued legal use of the software. This change is critical for Polish users to remain compliant with tax regulations.
Original PR description
Ensure compliance with the new electronic reporting obligations imposed by the Polish National Revenue Administration (KAS). This takes effect starting in 2025 for large enterprises, followed by SMEs with a one-year delay. Local software providers (such as Comarch or InsERT) will natively integrate this standard; failing to do so would expose users to severe tax penalties, rendering the software de facto unusable for legal accounting in Poland Enable the generation of the JPK_KR_PD file in the strict XML format mandated by the Polish Ministry of Finance. task-5163281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238374
Resolved issues and error corrections
This update ensures that pickings are automatically created when validating POS orders linked to sale orders. Previously, stock levels weren't updated correctly if pickings were scheduled for the end of a POS session. This fix provides more accurate stock management for point-of-sale transactions.
Original PR description
Before this commit, when validating a POS order linked to a sale order, if the Inventory Management was configured to create pickings at the end of the session, no picking was created for the order, and the sale order stock was not updated. This commit fixes this issue by ensuring that the picking is created for the imported sale orders in real time. opw-5423113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248424 Forward-Port-Of: odoo/odoo#244739
Features or functions removed from Odoo
This update streamlines the demo data for the Indian payroll module (l10n_in_hr_payroll) by removing redundant working schedules. The change consolidates to a standard 40-hour work week, improving data consistency and reducing complexity. This ensures a more accurate and manageable demo environment.
Original PR description
### AIM - In the demo data, there is no need to create multiple working schedules for Indian locations. - We can use a single working schedule of 40 hours per week. Task: 5899739
Documentation and clarification updates
This pull request updates the Adhoc Corporate Legal Agreement (CLA) membership list. This ensures Odoo's development team adheres to the required legal agreements for open-source contributions. The change is purely a formality and does not impact Odoo's functionality.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248286
This update enhances the handling of Romanian tax invoices from the ANAF. Now, the system automatically downloads and attaches the official PDF version of the invoice, providing accountants with a visual document for comparison and compliance. This eliminates the previous reliance solely on XML data.
Original PR description
### Before For bills from the Romanian ANAF we only downloaded an XML and imported the data. There is no visual aid for the accountant to see and compare the received document. ### Now We use the ANAF service to get the official "PDF" version of the invoice. This is requested for any new bill we get through ANAF that doesn't already contain a pdf from the vendor and it is set as the main attachment. task-5877171 Forward-Port-Of: odoo/odoo#248373 Forward-Port-Of: odoo/odoo#247382
This update enhances the payroll dashboard for Swiss users by tailoring warnings to specific Swiss requirements. It now displays warnings related to missing or incorrect data within Swiss employee and company records, ensuring accurate payroll processing. This improves data integrity and compliance for our Swiss customers.
Original PR description
This PR improves the payroll dashboard for Switzerland by: 1- Disabling the generic warnings as they are currently irrelevant to Switzerland. 2- Add new warnings for the missing/invalidity of some needed fields in swiss employees and companies. Task: 5856084 Forward-Port-Of: odoo/enterprise#105148
This update fixes an issue where the record count wasn't correctly displayed alongside group labels in list views. Previously, the count was appearing in unrelated columns, creating a confusing user experience. This change ensures the grouped record count is now consistently shown next to the group label, improving clarity and usability.
Original PR description
Currently, when applying a `Group By` filter in `list views`, the record count is displayed far from the group label. **Steps to reproduce:** - Open `Apps` and switch to the list view. - Apply a…
Currently, when applying a `Group By` filter in `list views`, the record count is displayed far from the group label. **Steps to reproduce:** - Open `Apps` and switch to the list view. - Apply a `Group By` filter (e.g., Author). - Observe where the grouped record count is displayed. **Observation:** The total number of records is rendered under unrelated columns rather than being displayed next to the group label. **Root Cause:** After commit [1], the `ms-auto` class at [2] causes the `group count` to be moved away from the group label. **Fix:** This commit ensures that the grouped record count is displayed next to the group label, consistent with previous versions. **Before:** <img width="1909" height="466" alt="5438766_before" src="https://github.com/user-attachments/assets/3ac44b19-2dad-4f01-ab78-8f456405e4d5" /> **After:** <img width="1905" height="453" alt="5438766_after" src="https://github.com/user-attachments/assets/ce0143e5-feeb-49ee-8d42-5235add669e4" /> [1]: https://github.com/odoo/odoo/pull/235250/commits/963696f4839b3043226ac118bf6a4ae8e8e92823 [2]: https://github.com/odoo/odoo/blob/25c372b254cec8635bb73b04c7729530f8a08e72/addons/web/static/src/views/list/list_renderer.xml#L247 opw-5438766
This update resolves a minor issue that prevented the application from functioning correctly when using the Ukrainian language. The fix addresses a problem with how the system retrieves language patterns, ensuring a more reliable experience for users in Ukrainian. This change improves overall application stability.
Original PR description
**Steps to Reproduce:** 1. Install `stock_fleet` module (with demo data). 2. Set the **Ukrainian** language for the user. 3. Open Fleet > Vehicle > Click Category Error: `KeyError: '2'` **Cause:** Babel's CLDR list patterns for some locales (e.g., Ukrainian 'unit-short') do not include the two-item pattern key, so when babel's `format_list` attempts to access patterns, it will raise an error. **Fix:** This commit wraps the call in a try/except that handles KeyError and retries formatting with the 'standard' style to avoid the crash. Forward-Port-Of: odoo/odoo#248519 Forward-Port-Of: odoo/odoo#248228
This update fixes a potential crash in the Italian EDI invoicing process when invoices are created with zero amounts in a foreign currency (like USD). The issue stemmed from a division-by-zero error during currency conversion. The fix ensures the system handles zero amounts gracefully, preventing errors and ensuring invoices can be generated correctly.
Original PR description
**Steps to reproduce:** 1. Install the `l10n_it_edi` and switch to IT company 2. Go to Accounting → Invoice. 3. Create an invoice add partner and change the currency to USD 4. Add a product and apply tax and discount of 100% and confirm 3. Click on Send **Issue:** A ZeroDivisionError is raised during the Italian EDI XML generation. `ZeroDivisionError: float division by zero` **Cause:** The conversion rate is computed by dividing `amount_total` by `amount_total_signed` without handling the case where `amount_total_signed` is `0.0`. **Solution:** Skip the conversion rate computation when the signed total amount is zero, preventing the division by zero **opw-5481821** Forward-Port-Of: odoo/odoo#245087 Forward-Port-Of: odoo/odoo#244423
This update corrects a previous issue where taxes related to GST, TDS, and TCS registration remained active even after the registration settings were disabled. Now, when a user removes these registrations, the associated taxes are automatically deactivated, ensuring accurate tax calculations and compliance. This simplifies tax management for users.
Original PR description
Before this PR: - When enabling TDS, TCS, or GST registration from settings, related taxes are activated, but when disabling these settings, the taxes remain active. After this PR: - When disabling TDS, TCS, or GST registration, all related taxes are deactivated. task-5456351 Forward-Port-Of: odoo/odoo#242030
This update corrects a flaw in the forecasting system that previously didn't account for materials used in production. Now, daily demand calculations accurately reflect the consumption of components within manufacturing orders, leading to more reliable inventory predictions. This ensures better production planning and reduces potential stockouts.
Original PR description
The daily demand in forecasting does not take into consideration the product that are used for production. Steps to reproduce: ------------------- * Install stock and mrp * Create a tracked Product…
The daily demand in forecasting does not take into consideration the product that are used for production. Steps to reproduce: ------------------- * Install stock and mrp * Create a tracked Product "Component" with RR * Add some "on hand quantity" * Create Product "Product" with a BOM that use "Component" * Create a manufacturing order for "Product" and confirm it * Go back on the RR of "Component" and use "resplenishment information" button (small i) -> Daily demand does not reflect the "Component" used for manufacturing. Observation: ------------- When Opening the resplenishment information, the daily_demand is calculated: https://github.com/odoo/odoo/blob/c38346ccc3e44670b76bfb010795bdfa7004b532/addons/stock/wizard/stock_replenishment_info.py#L177 For that calculation quantity_out is used, obtained just before: https://github.com/odoo/odoo/blob/c38346ccc3e44670b76bfb010795bdfa7004b532/addons/stock/wizard/stock_replenishment_info.py#L164-L167 Since it only consider moves that goes directly to the client, it will not take into consideration products that are used for production. opw-5497584 Forward-Port-Of: odoo/odoo#246125
This update fixes an issue where the total amount for invoice sections was incorrectly positioned in the PDF reports for the l10n_in tax module in Russia. The change adds the necessary column to align with product HSN/SAC reporting, ensuring accurate invoice summaries. This improves the clarity and accuracy of invoices generated for Russian businesses.
Original PR description
How to reproduce : - With l10n_in company - Create Invoice - Add section - Add product under section - Confirm invoice - Print to pdf The problem : The value for the total amount of the section is in the wrong column (the one to the left) Why : The l10n_in module adds a column in the report for the HSN/SAC of the products. It correctly did for the products and the table title but not for the sections. opw-5879828 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246768
This update fixes an issue where the HTML editor toolbar remained visible on mobile devices when the side menu or a popover was open. Now, the toolbar disappears automatically when these elements are active, providing a cleaner and more user-friendly mobile experience. This enhancement ensures a better workflow for users editing content on their phones.
Original PR description
In mobile, when the side menu or a popover is opened, the toolbar remains displayed above the keyboard. This commit hides the mobile toolbar while such elements are opened. Steps to reproduce: - In mobile, go to a "To do" note - Put cursor inside text to display the toolbar - Open the hamburger menu => The toolbar remained displayed on top of the side menu - Open the gear menu => The toolbar remained displayed while the menu was opened task-5222582 Forward-Port-Of: odoo/odoo#247389 Forward-Port-Of: odoo/odoo#241611
This update resolves an issue where users could incorrectly modify attendance records. The change now prevents unauthorized updates to attendance data, ensuring data integrity and accuracy. Added test coverage to confirm the fix.
Original PR description
Closes [odoo/odoo#226007](https://github.com/odoo/odoo/issues/226007). Description of the issue/feature this PR addresses: Prevents a user from updating their attendance record by changing the employee to the one whose attendance is not managed by the current user. Current behavior before PR: - Assign the Officer Group of Attendance group to a user. - Assign the user as the attendance manager of itself. - Login with that user. - Create an attendance record for the employee and save it. - Try to change the employee and save; an error will be thrown as expected. - Go to the Attendance menu; the record will still be saved. Desired behavior after PR is merged: This commit ensures that un-allowed write does not take place + test coverage added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243719 Forward-Port-Of: odoo/odoo#226335
This pull request fixes a problem where invoice descriptions were not consistently displayed when printing invoices, particularly with factur-x e-invoices. The update ensures that both the custom description and product names are correctly printed, improving invoice accuracy and compliance. This resolves issues reported by users importing factur-x invoices.
Original PR description
**Issue 1** Steps to reproduce: - Create a new invoice - Add an invoice line, with just a description - Save - On the same line, add any product - Print Issue: Only the custom description will be visible on the line opw-5471809 --- **Issue 2** Steps to reproduce: - Import factur-x e-invoice - Print pdf Issue: Only product name will be printed, even if the invoice record include the complete description opw-5471809 Forward-Port-Of: odoo/odoo#248010
This update resolves a memory issue that occurred when Odoo processed large amounts of email data. The fix optimizes how recordsets are handled, preventing excessive memory allocation and ensuring stable performance, particularly when dealing with many records. This improves the overall reliability of Odoo's email functionality.
Original PR description
**Issue Description :** In _mail_group_by_operation_for_mail_message_operation [function](https://github.com/odoo/odoo/blob/a1f4c98ec025cb36b218072f5557c93d5f329929/addons/mail/models/models.py#L77).…
**Issue Description :**
In _mail_group_by_operation_for_mail_message_operation [function](https://github.com/odoo/odoo/blob/a1f4c98ec025cb36b218072f5557c93d5f329929/addons/mail/models/models.py#L77).
The memory error occurred due to recordset concatenation triggered by: [operation_documents[record_operation] += record](https://github.com/odoo/odoo/blob/a1f4c98ec025cb36b218072f5557c93d5f329929/addons/mail/models/models.py#L83)
This resulted in repeated recordset concatenations inside a loop. Since recordsets are immutable, each concatenation [creates a new recordset](https://github.com/odoo/odoo/blob/a1f4c98ec025cb36b218072f5557c93d5f329929/odoo/orm/models.py#L5874) and reallocates the underlying tuple of IDs. When processing a large number of records this caused memory growth.
**Solution:**
Replace iterative recordset concatenation.
- Collect record IDs using Python sets (O(1) insertion).
- Build recordsets once per operation after the loop.
- Apply with_prefetch() only once per operation.
**Traceback:**
```
File "/home/odoo/src/odoo/saas-19.1/addons/mail/models/mail_message.py",
line 397, in _search
allowed_ids.update(self._find_allowed_doc_ids(model_ids))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/addons/mail/models/mail_message.py",
line 428, in _find_allowed_doc_ids
operation_res_ids =
records_all._mail_group_by_operation_for_mail_message_operation('read')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/addons/mail/models/models.py", line 83,
in _mail_group_by_operation_for_mail_message_operation
operation_documents[record_operation] += record
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5851, in
__add__
return self.concat(other)
^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5864, in concat
ids.extend(arg._ids)
MemoryError
```
opw-[5915534]
upg-[3878714]
tgb - 2445
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-prThis update resolves a visual bug where product arrows within snippets were incorrectly positioned, particularly when the snippet was set to full width. The fix ensures arrows appear correctly regardless of snippet size or scrolling mode, improving the overall presentation of product listings on the website. This enhances the user experience and consistency of product displays.
Original PR description
*: website_sale Since commit [1], the position of the arrows in the product snippet was broken when they were set to appear at the bottom. It also fixes the arrow positioning when the snippet is set…
*: website_sale Since commit [1], the position of the arrows in the product snippet was broken when they were set to appear at the bottom. It also fixes the arrow positioning when the snippet is set to full width, with the title displayed on the side and "Scrolling Mode" set to "All." This commit correctly adjusts the arrow positioning. [1]: https://github.com/odoo/odoo/commit/54fde5da6c229a7173c5b4c042b3330598db3904 task-5935743 | Before | After | |--------|--------| | <img width="1617" height="635" alt="Capture d’écran 2026-02-13 à 09 40 36" src="https://github.com/user-attachments/assets/21e3545c-e243-4ee7-9fd5-51ca06b8c496" /> | <img width="1620" height="664" alt="Capture d’écran 2026-02-13 à 09 39 14" src="https://github.com/user-attachments/assets/6dcdfc0f-6dc8-4293-9d23-ea36d19fc2b4" /> | | <img width="1921" height="719" alt="Capture d’écran 2026-02-13 à 11 12 22" src="https://github.com/user-attachments/assets/8916438c-8108-43ec-a70a-aba8c83ba881" /> | <img width="1918" height="654" alt="Capture d’écran 2026-02-13 à 11 17 21" src="https://github.com/user-attachments/assets/df872f4a-5674-4fff-a0de-b6c99f30acb2" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing users from correctly updating map addresses within the website. The fix eliminates an infinite loop that occurred when changing map locations, ensuring accurate map displays after address modifications. This improves the user experience when using the Google Maps integration.
Original PR description
When we add the google map block and try to change the address, we're unable to do so because of the infinite loop. The issue is due to the onPlaceChanged call inside the onPlaceChanged. We'll use commitPlace instead to commit place's coordinates, then re-render the map to reflect it. Steps to reproduce: 1. Add a google map block. 2. Try to change the address. It doesn't work due to the maximum call size exceeded due to infinite loop. opw-5386094 Forward-Port-Of: odoo/odoo#243679
This update fixes an issue where resetting dynamic colors in SVG illustrations would cause the images to disappear. Now, resetting the color palette restores the correct theme colors, ensuring SVG images remain visible and functional after color adjustments. This improves the user experience when customizing website visuals.
Original PR description
Steps to reproduce: - Insert a media library SVG illustration. - Change one of its Dynamic Colors. - Click the reset button in the colorpicker. => The SVG disappears. Before this commit, resetting a dynamic SVG color could send an empty color value and the image failed to render. After this commit, resetting restores the theme palette colors so the SVG stays visible. task-5868584 Forward-Port-Of: odoo/odoo#248092 Forward-Port-Of: odoo/odoo#245778
This update fixes an issue where the split screen in the restaurant POS module incorrectly showed discount information. The fix ensures that the correct discount value (as a percentage) is displayed, resolving a confusing user experience. This improves accuracy and clarity when splitting bills.
Original PR description
Steps: --- - Configure Restaurant with a global discount. - Open a session and add products. - Apply a global discount. - Open the control buttons and click Split. Issue: --- - The split screen displays the text `With [Object Object]% discount`. Cause: --- - The discount object was rendered directly instead of its value. Fix: --- - Display the correct discount value based on its type. task-5905885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent update prevented the accidental removal of content within HTML editor sections. Previously, pressing 'Delete' after selecting all content could unexpectedly clear the entire section, even when it was designed to be non-editable. This fix ensures that only intended content is removed, improving stability and user experience.
Original PR description
**Steps to reproduce:** - Drop a dynamic snippet, for example Recent Blogs → “Latest Stories”. - Click on the section title. - Press Ctrl + A. - Press Delete. **Description of the issue:** - The content part is removed even though it is inside a contenteditable false container. doing discard after it crash the page. **Cause:** - In `removeNode`, there is no check to prevent removal of children of a contenteditable false element. - As a result, if a contenteditable false element itself is unremovable, the parent node is preserved, but its children are still removed. **Solution:** - In `removeNode`, add a check to return false if node is not `isNodeEditable`. task-5858259 Forward-Port-Of: odoo/odoo#245463
This update fixes an issue where the code editor lost focus after changing the syntax highlighting language. Now, users can seamlessly switch languages without needing to manually re-enter the code. This improves the user experience and efficiency when working with code snippets.
Original PR description
**Description of the issue:** - When a user changes the language of a syntax-highlighted code block, the editor loses focus from the code input. As a result, the user must manually click back into…
**Description of the issue:** - When a user changes the language of a syntax-highlighted code block, the editor loses focus from the code input. As a result, the user must manually click back into the code block to continue typing **Steps to reproduce:** - Insert a syntax-highlighted code block. - Click the language dropdown to change the syntax highlighting language. - Select a different language from the dropdown. The language dropdown closes correctly after selection. Focus does not return to the code block input. Instead, focus remains on the dropdown button. **Cause:** - Although focus is explicitly set back to the code block input after selecting a language, closing the dropdown restores focus to the element that was active when the dropdown was opened . As a result, the input does not receive focus. **Solution:** - For the language selector dropdown, set focusToggleOnClosed = false so that closing the dropdown does not restore focus to the dropdown button. - For the copy button, prevent focus on pointerdown. task-5785595 Forward-Port-Of: odoo/odoo#245161
This update corrects a technical issue where website controllers could incorrectly link to irrelevant model types, leading to potential errors. By restricting controller bindings to concrete models, we’ve enhanced the stability and performance of the Odoo website. This change ensures data integrity and a smoother user experience.
Original PR description
Before this commit, a website_controller_page could be bound to any sort of model. For some of them this was irrelevant or plain wrong: - transient models: they are not pointing to anything relevant business wise - abstract: they cannot even have records, and most of them are mixin - _auto = False: Those are models with a table which is a custom one. The heuristics here is to say that records are not "real" ones. Also, most of these tables are sqlViews or something similar Business wise there were errors because of this, so this commit introduces a constraint that forbids the above use cases. sentry-6842596566 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#246115
This update significantly speeds up the inventory valuation report by optimizing how it calculates inventory values. Previously, the system was performing redundant calculations, leading to slow performance. This change eliminates unnecessary steps and batching processes, resulting in a faster and more efficient report generation.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247625
This update adds a system setting to automatically delete old device logs, helping to manage database storage and improve performance. Administrators can now define how long session data is retained, ensuring efficient log management. Careful consideration of database backups is required when setting this retention period.
Original PR description
The res.device.log table contains a huge amount of data. It makes sense to provide a way for administrators to garbage collect these logs according to their retention policy. The `ir.config_parameter` to determine the retention policy is `base.res_device_log_retention_days`. With the hard GC configured, a log will be deleted if its last activity has exceeded the number of days specified in the system parameter. This can remove all traces of a session identifier. The parameter must be chosen judiciously according to the database backups. Note: Put more information in the logs, as this data may be deleted. Task-5928301
This update resolves an issue where Point of Sale would crash when a user created an order containing a combo with an archived product. The fix prevents the system from attempting to access data from the archived product, ensuring a stable Point of Sale experience. This improves reliability for users managing product inventories.
Original PR description
Steps to reproduce: - Archive a product used in a combo. - Open Point of Sale. - Create a new order. - A blank screen appears (error in console) Cause: - The system attempts to access fields of an archived product included in a combo choice. Fix: - Skip loading the combo choice whose product is archived. Task-5936290
This update addresses a recent failure in the automated testing for the Employee Holiday Report. The fix involves ensuring a necessary table is always initialized, resolving an issue identified in a previous Odoo bug report. This ensures the report functionality continues to operate correctly.
Original PR description
Since odoo/odoo#215798 , Click All test has been failing, this commit aims to fix it by introducing a proper _init function to ensure the table exists at any time task-5907217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where changes made to website translations weren't consistently saved. Now, when editing a translation in one language and switching to another, all delayed translation versions are properly saved, ensuring accurate display across languages. This improves the user experience and data consistency for multilingual websites.
Original PR description
Scenario: - have two languages on website - drop a snippet on a page in main language - go to secondary language => you see the previous page version, and a notification with `Click on…
Scenario: - have two languages on website - drop a snippet on a page in main language - go to secondary language => you see the previous page version, and a notification with `Click on "Edit/Translate" to apply changes made on default language.` is shown - click on Edit: Translate => you see the version with the change from main language applied - save without doing a change Result: nothing is saved Expectation: delayed translations that we are seeing when editing translation should be saved. Cause: Delayed translation (draft version from change of main language) on website were added or disabled with: - 2d08f97c0778469b409fca23f2be5f5a98ce3df8 (October 2023) in 17.0 added the delay translation feature - 0e0a74f8c5fc9f45311e629a76608c6c986d635d (December 2023) in 17.0 disabled the feature - 03a85b13b2c46ef7174123d902e95d5103031c6c (September 2025) in 19.0 enabled the feature again Currently delayed translations are only updated if there is a part of that translation that has been edited and is dirty. Fix: when we save translations, we should also save o_delay_translation that are not dirty. These translations if there is a delayed translation will publish the delayed translation. opw-5187670 opw-5240423 opw-5250497 opw-5254832 opw-5344412 opw-5347408 opw-5419427 opw-5424761 opw-5892371 Forward-Port-Of: odoo/odoo#238696
This update resolves a minor issue in the HTML editor that could occasionally cause errors. The fix uses a technique called 'optional chaining' to safely access the previous sibling element, preventing the error when the element is missing. This improves the overall stability and reliability of the HTML editor.
Original PR description
Before this commit: in rectifySelection, the focusTarget can be null and causing an error when calling the previousSibling After this commit: now we do an optional chaining(?.) on previousSibling task-5481248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248595
This update resolves a problem where font family settings in the mass mailing editor weren't consistently applied. The fix ensures that changes made through the Design Tab correctly override font styles, providing users with greater control over the appearance of their emails. This improves the overall user experience and design flexibility.
Original PR description
There is an issue where some editor descendants have a rule overriding their `font-family` which has more precedence than the inherited `font-family` from the Design Tab. How to reproduce: - create a new mass_mailing - add a text snippet - select all text and change e.g. the `font-size` - open the Design Tab and change the `font-family` of paragraphs Issue: - the text `font-family` does not change Resolution: Fix a css rule applying on every element that is not a `fa` element so that it only applies on the `o_layout` element to let the Design Tab override the `font-family` for specific elements (e.g. `<p>`, `<a>`, ...). task-5869568 Forward-Port-Of: odoo/odoo#245304
This update fixes a technical error in the l10n_hr module where tax group receivable accounts were incorrectly linked to payable accounts. This misconfiguration was preventing accurate tax reporting and financial calculations. The change ensures proper accounting for tax groups, resolving a potential reporting issue.
Original PR description
The receivable accounts were wrongly setup where the receivable account of the tax group was set with the payable account, ... task-5045769 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248842
This update resolves an issue where users with limited inventory access experienced an error when validating recurring product deliveries. The fix ensures the system correctly retrieves necessary invoice information, preventing access restrictions that were blocking the validation process. This improves the reliability of recurring subscription deliveries.
Original PR description
When a user that only has inventory access right validate a delivery that has an recurring product it will trigger an access right error. Steps to reproduce: ------------------- * Install sales,…
When a user that only has inventory access right validate a delivery that has an recurring product it will trigger an access right error. Steps to reproduce: ------------------- * Install sales, inventory, subscription, * Create a subscription product * Create and validate a sale order with this product and a recurring plan * Connect to Odoo with an user that only has inventory user right * Validate the delivery -> Access Error Observation: ------------- When we validate the delivery,we call button_validate that will call [_action_done](https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock/models/stock_picking.py#L1427) During this we try retrieve invoices information [here](https://github.com/odoo/enterprise/commit/b07b1c47c97bb6d6da9fa61dacb5cba66aff2a16#diff-dbf7b40a6942fbcc81ebc4c3009a8a37a5a620cffac74889bd0ff2bccd52b1e3R30-R36). The issue is that this user doesn't have access right to several records: * sol.order_id.invoice_ids -> sale.order.invoice_ids * sol.order_id.last_invoice_date -> sale.subscription.plan opw-5869446 Forward-Port-Of: odoo/enterprise#106623
This update resolves an issue where users were encountering an error when editing reconciled invoice lines within the bank statement reconciliation process. The fix initializes necessary variables to prevent a runtime error, ensuring users can successfully adjust reconciled amounts and maintain accurate bank statement records.
Original PR description
Currently, an error occurs when user edits a reconciled line. **Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):** - Install the `Accounting`…
Currently, an error occurs when user edits a reconciled line. **Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):** - Install the `Accounting` module. - Create an `invoice` with an `invoice line` having an amount greater than zero. - `Confirm` the invoice. - Go to the `Bank journal` and create a `statement line` with the same amount as the invoice. - Click `Reconcile` on that `statement line` and select the newly `created invoice line`. - Click the `pencil icon` to edit the line, enter a `positive amount` in the Balance field, and save. `UnboundLocalError: local variable 'original_base_lines' referenced before assignment` The error occurs because, when a specific condition [1] becomes true, the variables original_base_lines and original_tax_lines are expected to be defined. However, if reconciled_lines_ids is present in move_line_to_edit, these variables are never initialized and are later referenced, causing the UnboundLocalError [2]. This commit ensures that original_base_lines and original_tax_lines are initialized to None, which prevents the error. [1]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1393-L1394 [2]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1410-L1411 sentry-7189027839 Forward-Port-Of: odoo/enterprise#104432
This update corrects a bug that prevented invoices with product lines having a price of zero in the Mexican (mx) tax module from being saved. The fix ensures that required tax object fields are correctly populated, resolving a critical issue for users creating invoices with zero-priced items. This improves invoice creation functionality for mx clients.
Original PR description
**PROBLEM** If you create an invoice, and add a line with a product with a price of 0, you cannot save the invoice. **STEP TO REPRODUCE** 1. On a mx company, create an invoice for a mx client. 2. Add a line with a product with a price of 0. 3. Try saving the invoice, it will fails. **CAUSE** Field `l10n_mx_edi_tax_object` is required on invoice line with mx company. However, for lines with a price of 0, it is not set by `_compute_l10n_mx_edi_tax_object` because `_l10n_mx_edi_cfdi_invoice_line_ids()` filters them. opw-5402045 Forward-Port-Of: odoo/enterprise#103981
This update corrects an issue where rental order display names were failing due to incorrect data being used. The fix ensures consistent and accurate partner name display by utilizing the `display_name` field, preventing errors when contact names are missing.
Original PR description
Steps to produce: --- - Install `sale_renting` and `contacts` modules. - Go to contact and open `yourcompany` record. - Add a new contact of type Delivery and save (leave the name empty). - Go to…
Steps to produce: --- - Install `sale_renting` and `contacts` modules. - Go to contact and open `yourcompany` record. - Add a new contact of type Delivery and save (leave the name empty). - Go to Rental > New Order. - Select YourCompany, Delivery as the customer. - Add a rental product and confirm the order. - Open the Schedule view. Traceback: --- `TypeError: sequence item 0: expected str instance, bool found`. Root cause: --- - At [1], the system tries to use the customer's name when computing the display name. However, in this case, the delivery contact has no name, resulting in a False value. This False value is then included in the description list, causing the TypeError when joining the sequence. Solution: --- - Use the partner's `display_name` instead of `name`. The `name` field can be `False` in some cases. The `display_name` field is a computed field that always provides a valid, formatted string by using fallback values such as the company name, parent name, or contact type. This ensures consistency and prevents errors [1] https://github.com/odoo/enterprise/blob/f5fea1d7b40e42b7bc1c323cc9613b1aa347da09/sale_renting/models/sale_order_line.py#L61 opw-5914084 --- Forward-Port-Of: odoo/enterprise#106827
This update resolves an issue where the version of the l10n_be_hr_payroll module was incorrectly referenced. This fix ensures accurate tracking and deployment of the payroll module, maintaining the stability and reliability of financial reporting within Odoo Enterprise. It's a routine maintenance update.
Original PR description
Forward-Port-Of: odoo/enterprise#107482
This update reverses a recent change that exposed sensitive time-off type information to all users within the time-off overview. The change was causing a security vulnerability by displaying private time off details. This fix restores the previous system where time-off colors were based on type, ensuring data privacy.
Original PR description
This commit reverts back the change done to gantt color of time-off overview to be based on time off type instead of employee, which made private information (time off type) available to everyone. Task: 5868354
This update corrects a flaw in the VoIP unit tests by replacing a misleading selector with a more accurate one. The change ensures the tests reliably check for expected conditions, and also streamlines the test code by removing unnecessary assertions. This improves the overall stability of the VoIP functionality.
Original PR description
Introduced by [1]. The use of `:value()` is always truthy, making that assertion useless in the related unit test. Replaced by `:empty` as intended and took the opportunity to remove the non-required extra assertion around that code. [1]: https://github.com/odoo/enterprise/commit/0ff7c35c266c547ed3cc63155ffba54727d43c07
This update resolves a bug that prevented the infinite scrolling of VoIP call history in Chrome. The fix addresses an issue with how the system detects the end of the scrolling area, ensuring all recent calls are displayed correctly. This improvement ensures a seamless user experience for accessing call history.
Original PR description
Since [1], the voip calls infinite scrolling does not work anymore. Steps to reproduce: - Make sure to have at least 14 recent calls - Open the softphone - Go to the recent/history tab - Scroll to…
Since [1], the voip calls infinite scrolling does not work anymore. Steps to reproduce: - Make sure to have at least 14 recent calls - Open the softphone - Go to the recent/history tab - Scroll to the end => You are stuck seeing only the 13 last calls. This was a Chrome-only issue, it works on Firefox. Weirdly, the infinite scrolling works on the contact tab on Chrome too, although this is the exact same implementation and configuration. This is due to the unreliable behavior of IntersectionObserver regarding 0x0 elements. The infinite scrolling implementation in VoIP relies on the visibility of a "dummy" `<span/>` added at the end of the tab. That element has no width or height, making the implementation unreliable. As a stable minimal fix, this restores the feature by making the element have a width and height, without any visual/behavior changes thanks to negative margins and no pointer events on the item. Note that [1] disabled a test that was testing the feature. This commit of course re-enables it. [1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd Forward-Port-Of: odoo/enterprise#106658
This update fixes an issue where the month displayed on global invoices linked to POS orders was incorrectly reflecting the invoice creation date instead of the order date. This ensures accurate reporting and compliance with Mexican tax regulations. The fix corrects the 'Meses' attribute in the generated XML.
Original PR description
**PROBLEM** In accounting, if you create a global invoice with an invoice, the attribute `Meses` will be the month of the invoice date. In POS, if you do the same with an order, the attribute `Meses` will be equal to the month the day we create the global invoice, instead of the month of the order date. This is wrong. **STEP TO REPRODUCE** 1. Have an order from the month before (not sure how to do this on a runbot). 2. Create a global invoice. 3. Check the generated xml, and notice the month is wrong. opw-5381607 Forward-Port-Of: odoo/enterprise#107362 Forward-Port-Of: odoo/enterprise#106856
This update corrects a display issue where percentage fields in HR contracts were showing decimal values (e.g., 0.25%) instead of the intended percentage format (e.g., 25%). The underlying calculations remain accurate, and this change ensures a more user-friendly experience when viewing and editing these values. No data was changed.
Original PR description
Percentage fields are stored as a decimal in the DB (0.25) but represent a percent value (25%) The calculations are correct but the display to the user shows 0.25%, this PR fixes that without modifying the values stored on the database task-5350196
This update fixes a previous error where work accident entries were incorrectly being paid on employee payslips. The change adds the necessary entry type to the payroll data, ensuring accurate calculations and proper compensation for work accidents. This resolves a potential financial discrepancy.
Original PR description
The unpaid work accident work entry type was added, but not included in `unpaid_work_entry_type_ids`, causing it to be paid by mistake. Add it to `unpaid_work_entry_type_ids` for the following structures: - structure_type_employee_cp200 - structure_type_employee_cp200_pfi Task: 5484866
This update fixes an issue where the Employer File Number field was hidden in the payroll settings after installing the l10n_hk_hr_payroll module. The fix removes the setting that previously obscured this important data, ensuring users can now correctly input and view this required information.
Original PR description
Issue: - Employer File Number was hidden in Payroll settings after installing the l10n_hk_hr_payroll_empf module. Fix: - Removed the setting that hid the Employer File Number field. task-5476454 Forward-Port-Of: odoo/enterprise#103987
This update resolves several issues impacting the accuracy of Single Touch Payroll reporting in Australia, specifically related to opening balances and year-to-date calculations. The changes include rounding monetary amounts to the correct currency precision and correcting date discrepancies, ensuring compliance and reliable financial data.
Original PR description
- Unable to import opening balances when zeroed out. This should not require Previous Payroll and BMS IDs - Float creates an overflow while computing the YTD sums, which results in too many digits in decimal places. Round all monetary amounts reported to the rounding precision of the currency. - Issues with run date and submit dates for the prior fiscal year. - Fix payslips computation on update actions post finalisation Task - 5685790 Forward-Port-Of: odoo/enterprise#105952
This update fixes a misleading error message displayed when validating Argentine electronic invoices (ARCA). The message has been corrected to accurately reflect the requirement that the invoice date cannot be before the last validated invoice, preventing incorrect invoice processing. This ensures compliance with AFIP regulations.
Original PR description
WSFE error 10016-1 must be "The invoice date cannot be before the last invoice validated in AFIP." instead of "The invoice date cannot be after the last invoice validated in AFIP". Steps to reproduce: validate argentinean customer electronic invoice with invoice date before than the last invoice date validated in ARCA. Task Adhoc side: 44290 Task latam: 1376 Forward-Port-Of: odoo/enterprise#106687 Forward-Port-Of: odoo/enterprise#106305
This update fixes an issue where the activity menu in web_studio was incorrectly displaying all records for custom models, rather than just those with activities assigned to the current user. Now, the activity menu accurately filters records to show only those with associated activities, improving the user experience and data accuracy.
Original PR description
After commit odoo/odoo@5c5fbc10b7024c7227f03e37897d421bba64df82 , actions spawned by the activities menu have their domain managed by dynamic <filter /> rather than a plain readonly domain. Before this commit, clicking on the activity menu to go to a custom model showed every record, not just ones with activities after this commit, only records with activities assigned to the current user are showed opw-5778806 Forward-Port-Of: odoo/enterprise#107277 Forward-Port-Of: odoo/enterprise#106622