Monday, February 2, 2026
31 changes · saas-19.1
Enhancements to existing features
This update simplifies the mention plugin in Odoo by removing unnecessary protections around mention nodes. This change improves performance and reduces complexity within the composer interface. Additionally, redundant code related to mentions has been removed.
Original PR description
Currently, mention nodes are protected using the ProtectedNode plugin to avoid issues when editing the content of the composer. Considering we don't nessecarily need to protect mention nodes with no mutation allowed on them, we can remove the protection on mention nodes. Also, remove reduntant MENTION_SELECTORS task-5264818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237351
This update adjusts the National Social Security Fund (NSSF) contribution limits to align with the latest regulations under the NSSF Act 2013. Specifically, the lower and upper earnings limits have been revised, impacting the maximum combined contribution a worker can make. This ensures compliance with current Kenyan tax laws.
Original PR description
This commit updates the NSSF Lower and Upper Earnings Limits in accordance with the 4th year of implementation of the NSSF Act 2013. - Set Lower Earnings Limit (Tier 1) to 9,000. - Set Upper Earnings Limit (Tier 2) to 108,000. - Resulting max combined contribution is now 6,480. Task: 5485002 Forward-Port-Of: odoo/enterprise#105019
Resolved issues and error corrections
This update fixes an issue where users wouldn't receive a warning when entering invalid email addresses during shared sign request declines. Now, the system validates email formats and displays a clear warning message, preventing incorrect data entry and improving the user experience. This ensures data integrity for shared agreements.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Create a shared sign request. - Try to decline the sign request. - Enter an email address in an invalid format. Issue: - No warning is shown to the user for an invalid email and An RPC_ERROR appears in the console. - This happens because the _check_signer_email_validity constraint fails when signer_email is not valid. Solution: - Validate the email format when the user submits the refusal request. - Show a warning message if the email format is invalid. task-5454929 Forward-Port-Of: odoo/enterprise#103146
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 the demo data to use a standard 40-hour work week, improving data consistency and reducing complexity. This simplifies the demo experience for users.
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
This update fixes an issue where the UrbanPiper store identifier field was visually overflowing its container. The changes include wrapping the field and button in a container with flexible width and overflow-hidden styling, resulting in a cleaner and more user-friendly display of this key information.
Original PR description
Before this commit: --- - The UrbanPiper store identifier field could overflow its container. After this commit: --- - Wrap the store identifier field and action button in a container. - Apply `overflow-hidden` and flexible width to the store identifier field. task-5472992 Forward-Port-Of: odoo/enterprise#103464
This update resolves an issue that previously prevented users from duplicating journal entries containing outdated accounts. Now, users can successfully duplicate entries with deprecated accounts, correct the accounts in the draft, and post the entry. The system validates only during the posting stage, ensuring flexibility in using historical entries as templates.
Original PR description
Before this commit, duplicating a journal entry that contained a deprecated account raised a validation error immediately. This blocked the duplication process entirely, preventing users from using historical entries as templates. This commit changes the validation to be done in write function and post. Now, users can duplicate an entry with a deprecated account, correct the account in the draft, and post successfully. Validation only blocks the user if they attempt to post the entry without fixing the deprecated account. or if the user inserted a deprecating account while editing the move. task-5417810 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#243782 Forward-Port-Of: odoo/odoo#240230
This change clarifies how product settings are managed by preventing users from editing the 'Packagings' field directly within the product view. Previously, editing was possible from both the product and product template views, causing confusion. This fix ensures 'Packagings' settings are consistently managed on the product template, aligning with user expectations.
Original PR description
## Short functional explanation of the error When creating a variant, we can click on it and it will show the field "packagings" on the product view, which is editable. However, packagings are…
## Short functional explanation of the error When creating a variant, we can click on it and it will show the field "packagings" on the product view, which is editable. However, packagings are managed on the product template view, where the field is also editable. This creates confusion for the users, as it doesn't align with the sentence on the view "All general settings about this product are managed on the product template". ## Reproduction Steps 1. Create a product. In the Attributes & Variants tab, create a variant. 2. The smart button Variants should appear. Click on it. 3. In the list view, click on the variant you just created. 4. Under Sales, modify the Packagings field. 5. Click on 'the product template' blue text. The product template popup appears. 6. Go to Sales tab and modify the Packagings Field. ### Expected behavior The packagings should be editable only on the product template view. ### Unexpected behavior The packagings is also editable on the product.product view. ## Origin of the issue Missing a readonly="1" in the xml of product.product view __ opw-5065419 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent update caused a crash when uploading images with URLs, specifically when the URL was provided as a 'bytearray'. This fix ensures that bytearrays are correctly converted to standard 'bytes' before URL detection, resolving the error and restoring reliable image uploads. This prevents disruptions to the import process.
Original PR description
The recent mimetype refactor reintroduced a crash where `python-magic` fails on `bytearray` inputs with a `TypeError` (ctypes buffer mismatch). Steps to reproduce: - Have python-magic library installed - Products > Import records - Upload a file containing an URL as image_1920 - Test upload The upload fails with error: `Could not retrieve URL: <img-url> [image_1920: L1]: argument 2: TypeError: wrong type` This restores the fix from 7f36e380c0b175d0046a19f49e572944a5b307d9 by ensuring `bytearray` inputs are converted to `bytes` before detection. opw-5893097
This update fixes a technical error in the attendance and overtime system, preventing a system crash when approving overtime. The issue stemmed from a misconfigured link between attendances and overtime records. This ensures the system functions correctly when managing overtime approvals.
Original PR description
…vertime
STEP TO REPRODUCE: (hr_Work_entry need to be installed to be tested fromt he frontend) ------------------
1- Create an overtime rule with this configuration :
quantity rule differs from hours defined in the contract
2- Create two attendances on the same day (should be a worked day and should not be today)
one from 1AM-2PM
second from 2PM-undefined
3- Approve the overtime of the first attendance
REASON:
------
If hr_work_entry is installed a traceback will be raised because the link between overtime to attendance is not correctly done Attendance -> overtime (only the first attendance have a link with overtime) overtime, attendance -> the two will be returned
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#246478This update resolves an issue where overtime approvals weren't consistently linked to employee attendance records. Previously, only one attendance was associated with overtime, leading to inaccurate reporting. This fix ensures all relevant attendance records are correctly linked to overtime, improving the reliability of time tracking data.
Original PR description
…dance and overtime
STEP TO REPRODUCE:
------------------
1- Create an overtime rule with this configuration :
quantity rule differs from hours defined in the contract
2- Create two attendances on the same day (should be a worked day and should not be today)
one from 1AM-2PM
second from 2PM-undefined
3- Approve the overtime of the first attendance
REASON:
------
The link between overtime to attendance is not correctly done Attendance -> overtime (only the first attendance have a link with overtime) overtime, attendance -> the two will be returned
Forward-Port-Of: odoo/enterprise#105988This update corrects a bug that caused duplicate default appointment slots to be created when scheduling appointments. The fix ensures that slots are only added once, preventing scheduling conflicts and improving appointment booking accuracy. This resolves a user-reported issue impacting appointment scheduling functionality.
Original PR description
Steps to reproduce: - Install website_appointment - Go to the frontend and create a new appointment from there - The appointment created has its default slots duplicated When creating an appointment type, it's possible that we end up creating the default slots two times by passing in the compute of the category and then the onchange linked to category_slot_scheduling. Technically, when we were in the onchange after the compute, slot_ids was populated by NewId records. So when assigning and creating a second time the default slots, the NewId would at the end become real records and the new one were added on top. Now we add a check on the previous category to create the default slot only when we came from a custom appointment and reset them if it is now a custom one. task-5499200 Forward-Port-Of: odoo/enterprise#104482
This update resolves a problem that occurred during Odoo upgrades where the system incorrectly processed partner information. Specifically, the system expected only one record per partner when calculating document counts, but multiple records were found. This fix ensures accurate document counts during upgrades and normal operation.
Original PR description
When trying to compute the document count during the upgrade, we encountered a ValueError because multiple records were found for a partner. The system expected a singleton ``` File…
When trying to compute the document count
during the upgrade, we encountered a ValueError
because multiple records were found for a partner. The system expected a singleton
```
File "/home/odoo/src/enterprise/19.0/documents_hr/models/hr_employee.py", line 34, in _compute_document_count
('partner_id', '=', self.work_contact_id.id)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields_misc.py", line 112, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.partner(11393, 11612, 13026, 13085, 13066, 11674, 13007, 11240, 11420, 13086, 2687, 8998, 10309, 8195, 8468, 6439, 8151, 6580, 7928, 10301, 11058, 10515, 5274, 9243, 8141, 8435, 8889, 7761, 7733, 8443, 8545, 9252, 8457, 9980, 5495, 11424, 6458, 10558, 11070, 8924, 11731, 11528, 11615, 11766, 13021, 13080, 11758, 11742, 9306, 8826, 11004, 9393, 8879, 9317, 11652, 13075, 11744, 11160, 11644, 11763, 11416, 11618, 11732, 7931, 3846, 8442, 10299, 7916, 8429, 8057, 11061, 9342, 6435, 6553, 6512)
```
Forward-Port-Of: odoo/enterprise#101902This update resolves a technical issue preventing "Access Rights" users from accessing the documents application. The change restricts access to certain features and visibility within the application, ensuring only administrators can utilize advanced functionalities. This improves the user experience for a broader range of users.
Original PR description
Internal Users with the "Access Rights" access right were not able to open the documents application, which raised an access error traceback on the `ai_sort_prompt` field - which has restricted access to only admins. The access error was raised because the `ai_sort_prompt` field was added to the search_panel_fields for users with Access Rights access rights. We changed it so it is only added when users have the document system adminstrator role. We also changed the document_service's start method to also define the documentSystem user which is the system adminstrator user. With that we could limit visibility of the System Prompt item in the cog menu to those users. task-5375110 Forward-Port-Of: odoo/enterprise#105741
This fix ensures that Swiss payroll payslips generated from payruns display the employee's full name instead of a generic 'new payslip' title. The change corrects a technical issue where the system wasn't properly formatting the payslip name, leading to an inconsistent user experience. This improves clarity and professionalism for Swiss clients.
Original PR description
_ ## Short functional explanation of the error When generating a payslip from a payrun for an employee on the swiss localization, the name of the PDF payslip is simply "new payslip" instead of…
_ ## Short functional explanation of the error When generating a payslip from a payrun for an employee on the swiss localization, the name of the PDF payslip is simply "new payslip" instead of "Salary Slip - <name of employee> - <time period of the slip>" ## Reproduction Steps 1. Install the app l10n_ch_hr_payroll. 2. Make sure you use a Swiss company. 3. Go to Payroll and click on the Payslips tab > payslips. 4. Click on Pay Run. Select Switzerland: ELM salaries and click Continue. 5. Select an employee for which you'd like to generate the payslip. 6. Click on the employee row in the list view. 7. Click Compute sheet > Print. ## Expected behavior A PDF with name "Salary Slip - <employee name> - <time period>" is generated. ## Unexpected Behavior A PDF with name "new Payslip" is generated. ## Origin of the issue When printing the slip with this flow, we don't call the method ```_compute_name()``` used to compute the name of the current slip. Therefore, it stays at 'New Slip', which is the default name. Henceforth, we have to call this method manually when printing the slip. _ opw-5253811 Forward-Port-Of: odoo/enterprise#103471
This update resolves an issue where service products were missing a default packaging type. The previous XML ID was incorrect and no longer functional. This ensures service products are properly configured for EDI reporting in Kenya.
Original PR description
Update the xmlid for the default packaging type for service products, the previous one `l10n_ke_edi_oscu.packaging_type_ou` seems to have never existed. opw-5220129 Forward-Port-Of: odoo/enterprise#105905
This update resolves an issue where actions in the Documents app would fail when switching between languages. The system now filters actions to only include those associated with the currently active languages, ensuring a smoother user experience and preventing errors during language transitions. This improves stability and usability.
Original PR description
Filter Embedded Actions Based on Active Languages ### Impacted versions: 18.0 and later ### Steps to reproduce: - Install at least 2 languages - Install documents and accounting or other app to have actions on select - Uninstall one language - You will get an error when trying to activate again actions on select (also appears on network interface) ### Current behavior: When a language is deactivated, its corresponding translations may still appear in server actions, leading to errors when trying to add them to the context. This issue is now resolved by filtering actions to only include those linked to active languages. Task: [5420820](https://www.odoo.com/odoo/project/49/tasks/5420820) Forward-Port-Of: odoo/enterprise#102938
This update prevents visitors from seeing or attempting to use live chat commands like `/help` or `/leave`. Previously, these commands were visible, even though they weren't functional for non-users. This change improves the user experience and security by removing potentially confusing and unusable options.
Original PR description
**Current behavior before PR:** channel commands like `/help ` or `/leave` are visible to visitors even it is not functional for them. **Desired behavior after PR is merged:** commands are now hidden from visitors. task-4552209 related: [PR](https://github.com/odoo/enterprise/pull/82963) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246120 Forward-Port-Of: odoo/odoo#196737
This update hides live chat commands (like `/help`) from website visitors and guests. Previously, these commands were visible, creating a potential security risk and a confusing experience for non-users. This change enhances website security and provides a cleaner, more intuitive interface for legitimate users.
Original PR description
**Before PR:** channel commands like `/help ` or `/leave` and more are visible to visitors or guest even it is not functional for them. **After PR:** all commands are now hidden from visitors/guests. task-4548666 Forward-Port-Of: odoo/enterprise#105777 Forward-Port-Of: odoo/enterprise#82963
This update enhances the performance of account reporting by optimizing the way data is filtered within key tables. The change ensures more efficient report generation, leading to faster processing times and improved user experience. This resolves a technical issue impacting report loading speed.
Original PR description
In addition to: - [x] #104936 And other PRs in Odoo core: - [x] odoo/odoo#243833 - [x] odoo/odoo#243967 - [ ] odoo/odoo#246440 Forward-Port-Of: odoo/enterprise#105960
This update fixes an issue where product names weren't consistently displayed in the correct language based on the user's current language setting. Previously, accessing a product name twice with different language contexts would result in the incorrect language being used. Now, the system always uses the specified language context when calculating and displaying product names, ensuring accurate translations for all users.
Original PR description
Description of the issue/feature this PR addresses: Compute of display_name in different languages that can be returned incorrect Current behavior before PR: When accessing two times in the same method the display_name of a configured product but the second time having a .with_context(lang=lang) other than the previous language, the returned display name will not be in the specified language as the cached value will be returned. Desired behavior after PR is merged: _compute_display_name should always take into account a change of language in context when the value is accessed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246489 Forward-Port-Of: odoo/odoo#242829
This update prevents the eCommerce reporting menu from appearing to users without the necessary permissions. Previously, users were redirected to the website without a clear error message. The fix ensures a more user-friendly experience by displaying an access error when the menu is unavailable.
Original PR description
__Steps to reproduce on runbot:__ 1. Login with Mitchell Admin 2. Remove Marc Demo from the `sales_team.group_sale_salesman` access group (User: Own Documents Only) 3. Login with Marc Demo 4. Open…
__Steps to reproduce on runbot:__ 1. Login with Mitchell Admin 2. Remove Marc Demo from the `sales_team.group_sale_salesman` access group (User: Own Documents Only) 3. Login with Marc Demo 4. Open the Website app and go to Reporting > eCommerce => You are redirected to the website in frontend mode __Reason:__ Clicking on the eCommerce reporting menu calls `action_dashboard_redirect`, which redirects to the website if the user is not in `base.group_system`, `website.group_website_designer`, or `sales_team.group_sale_salesman`. Since Marc Demo is not in any of these groups, he is redirected to the website without any message, which is not very user friendly. __Fix:__ - Add the groups to the menu to prevent showing it if the user does not have access to it anyway. - Raise an access error instead of redirecting to the website to make it clear to the user that they cannot open the dashboard even if they could see it. This also fixes [`TestMenusDemo`] by preventing this menu from being tested with the demo user in case he doesn't have access to it. [`TestMenusDemo`]: https://github.com/odoo/odoo/blob/736b71202db840ba6a7ed7e7f014b5b7c493d589/addons/web/tests/test_click_everywhere.py#L41C9-L41C41 runbot-234747 Forward-Port-Of: odoo/odoo#244963
A test error was caused by inconsistent values used when creating payment provider records, specifically when the 'payment_custom' module was installed. This update ensures tests always use 'none', resolving the error and improving test stability.
Original PR description
Depending on the modules installed, the tests sometimes use a different value for creating the `payment.provider` record. The code is sometimes set to custom if the `payment_custom` module is installed. This causes a runbot error. To avoid this, we force the code `none` in our tests. This will have no impact and will fix the indeterminate error. RunbotID: 237707
This update corrects a bug that prevented the system from creating vendor partners when the vendor bill XML data lacked a 'Departamento' value. The fix ensures accurate vendor partner creation, streamlining invoice processing and avoiding data entry errors. This resolves an issue impacting the l10n_uy_edi module.
Original PR description
If the xml file has a tag "Departamento" without a value, the vendor partner creation fails because the state is searched with an empty string and detects a state that is not correct because the xml has no state value. Task Adhoc side: 109004 Forward-Port-Of: odoo/enterprise#105801
This update ensures that when a user confirms an upsell on a subscription, all remaining alternative quotations are automatically cancelled. Previously, confirming one upsell would leave others in a pending state. This change improves the subscription management process and prevents unnecessary quotes from being created.
Original PR description
Currently, when creating multiple upsells for a specific subscription, confirming one of them leaves the others in the sent state instead of cancelling them. This fix ensures that all other upsells for the same subscription are cancelled once one upsell is confirmed. task-5270139 Forward-Port-Of: odoo/enterprise#105694 Forward-Port-Of: odoo/enterprise#100058
This update fixes an issue where a work center wouldn't be blocked after a work order was deleted. The timer continued running, preventing proper resource management. Now, deleting a work order correctly stops the timer and prevents the work center from being blocked.
Original PR description
Steps to reproduce: - Start the timer on the work order - Delete the work order - Try to block the work center Current behavior: - The work center is not blocked because the latest mrp.workcenter.productivity is still active Expected behavior: - The work center is blocked - mrp.workcenter.productivity is stopped opw-5475227 Forward-Port-Of: odoo/odoo#245815
This update fixes a problem where product barcodes weren't printing correctly, resulting in blank pages. The issue stemmed from a change in how report templates were configured. The fix ensures that product barcodes are generated accurately across all supported printing formats.
Original PR description
## Issue When printing the barcode for a product, only a blank page would be printed. ## Steps to reproduce 1. Install Barcode (`stock_barcode`) 2. Create a product and set a barcode 3. On the…
## Issue
When printing the barcode for a product, only a blank page would be printed.
## Steps to reproduce
1. Install Barcode (`stock_barcode`)
2. Create a product and set a barcode
3. On the product page, click Actions (cog wheel) > Print Labels
4. Print with any of the following format:
- Dymo
- 2 x 7 with price
- 4 x 7 with price
- 4 x 12
- 4 x 12 with price
5. **For the Dymo format, the barcode is not displayed properly. For the four other formats, a blank page is printed**
## Cause
[This commit](https://github.com/odoo/odoo/commit/b7ec60d68c6ee23f7684960e33e5bd6290c9d829) made the `t-call` tag parametric, replacing the `t-set` and `t-value` pairs in various contexts. In this case, the parameters were not added to the correct `t-call`. Without `columns` and `rows` defined, the `report_productlabel` template would not produce anything:
https://github.com/odoo/odoo/blob/b6598c11a3580cfc6ff1ffeb67b0d388c55383d1/addons/product/report/product_product_templates.xml#L129-L131
opw-5877421This update enhances the security and reliability of our Peppol integration by allowing servers to initiate deregistration when a client is no longer active. The Peppol system now uses a 'soft reset' to allow users to re-register, addressing a previous incident. This change improves the overall stability and compliance of the account_peppol module.
Original PR description
Reintroduce server-initiated deregistration on `client_gone`, but only for implementations that explicitly handle it. The base proxy client now just raises the error. Peppol opts in by soft-resetting its configuration so users can re-register. See the IAP postmortem for the rationale and incident history. https://github.com/odoo/iap-apps/pull/1317 no-task Forward-Port-Of: odoo/odoo#246002 Forward-Port-Of: odoo/odoo#239254
This update ensures that IoT printers can utilize LNA (Line Notification Access) when enabled in the printer settings. Previously, this setting was hidden for IoT printers, preventing their use. This change makes LNA accessible for all printers, including IoT, enhancing POS functionality.
Original PR description
This PR https://github.com/odoo/enterprise/pull/102622 activates lna for the iot box requests if "use_lna" is active in the printer settings. However the field is invisible for the iot printers. This PR makes it visible for all printers, including iot to use lna with iot in saas-19.1
A recent test failure related to the restaurant appointment tour has been resolved. The fix ensures the test consistently simulates the correct time, preventing inconsistencies in how the tour behaves. This improves the reliability of our automated testing process.
Original PR description
The `RestaurantAppointmentTour` was failing inconsistently because the browser used the real system clock during the initial Point of Sale load, while the test data was created for a specific mock date (Jan 28). Because the PoS logic filters appointments based on the current time, the test data was being misinterpreted or "normalized" by the application before the tour had a chance to freeze the clock. Moving `Chrome.freezeDateTime` to the absolute first step of the tour ensures the simulated time is applied as early as possible, making the test deterministic. runbot-232601 Forward-Port-Of: odoo/enterprise#106024
This update corrects a visual issue where an extra checkbox was appearing in the active action dropdowns, causing layout problems. The fix removes the unnecessary styling and ensures consistent display of active actions within the dropdown menu. This improves the user experience by preventing visual overflow and ensuring proper item representation.
Original PR description
Webclient style has style to apply checkbox next to active dropdown item when it doesn't have the `.dropdown-item_active_noarrow`, through adding some content in `.dropdown-item:before`. This checkbox is problematic because it overflows with `Dropdown`, and items in a discuss action list dropdown already have enough to show when they are active or not. This commit cancels the webclient style of adding the checkbox by adding `dropdown-item_active_noarrow` on ActionList's dropdown items. Part of Task-5867464 Before / After (see barely checkbox overflows on "Unmute" item): <img width="254" height="268" alt="Screenshot 2026-01-30 at 18 06 27" src="https://github.com/user-attachments/assets/196ec808-c22c-41f0-9ab3-c8f9b9a52535" /> <img width="254" height="264" alt="Screenshot 2026-01-30 at 18 17 42" src="https://github.com/user-attachments/assets/77a918db-fd55-4a09-8c47-ec615bd4f280" /> Forward-Port-Of: odoo/odoo#246586
This update removes the 'Add Note' button from the kiosk interface within the Odoo POS Self-Order module. This simplifies the kiosk experience for customers, reducing potential confusion and improving ease of use. The change was implemented as part of a standard improvement.
Original PR description
The goal of this pr was to remove the "Add note" button in the Kiosk. task: 5470923 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr