Wednesday, February 4, 2026
25 changes · 19.0
Enhancements to existing features
Customers now receive a clearer message when Xendit rejects a payment because the phone number was entered incorrectly. This helps shoppers understand what to fix, reducing confusion and support requests during checkout.
Original PR description
The error message returned from Xendit when there is input error on phone number is not understandable. Customers often don't know which information has been input incorrectly. task-5877596 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the one-time payment form by removing a redundant version field. The form now automatically displays payments for the correct employee based on the context, ensuring accuracy and streamlining the process. This change improves usability and avoids potential errors.
Original PR description
… payment form The one time payment view is accessed only via the smart button on the employee form for a specific version. This view displays only that employee's one time payments for the selected version. Since the version is provided by the context and creating a payment for a different employee or version would not make sense, the version field is made invisible. Task: 5384437
Resolved issues and error corrections
The website search pop-up now closes automatically when a user enters edit mode. This prevents the pop-up from blocking drag-and-drop snippet placement, making page editing work as expected.
Original PR description
Steps to reproduce: 1. Go to the Website. 2. Click the search icon in the header. 3. When the search modal opens, click 'Edit' to enable website editing. 4. Attempt to add a snippet. Observed behavior: - Snippets cannot be added while the global search modal remains open. Expected behavior: - Snippets should be draggable and added normally in edit mode. This commit ensures that the global search modal is closed when entering edit mode, preventing it from blocking add snippet. task-5421051 Forward-Port-Of: odoo/odoo#241414
Code cleanup and technical improvements
This update simplifies internal attendance overtime rule code by reusing an existing function instead of keeping duplicated logic. It does not change user-facing behavior, but makes future maintenance safer and easier.
Original PR description
In odoo/odoo#240263, these functions were duplicated as changing the signature was not possible. In this commit we want to improve the readability of this file by calling the new function inside the duplicated function.
This update fixes several issues in Odoo's internal Hoot testing system, including more complete browser request simulation and stricter error checks. These changes help developers catch problems earlier and reduce the risk of faulty tests passing unnoticed, without directly changing day-to-day user features.
Original PR description
### [FIX] Hoot fixes This PR contains several fixes for the Hoot system. See each commit description for more details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246402 Forward-Port-Of: odoo/odoo#244726
Currently an log error is generated when the user tries to install the `Japanese` language after installing the `Invoicing (account)` module. Error: `OSError: Syntax error in po file (line 1273): unescaped double quote found` This issue is caused by a bug in Weblate that incorrectly escapes quotation marks `(\")`. As a result, the PO file becomes corrupt because the quotation mark that should terminate the string is improperly escaped. This commit resolves the issue described above by m
Original PR description
Currently an log error is generated when the user tries to install the `Japanese` language after installing the `Invoicing (account)` module. Error: `OSError: Syntax error in po file (line 1273): unescaped double quote found` This issue is caused by a bug in Weblate that incorrectly escapes quotation marks `(\")`. As a result, the PO file becomes corrupt because the quotation mark that should terminate the string is improperly escaped. This commit resolves the issue described above by manually correcting the affected PO file. sentry-6976676644
Odoo now prevents users from enabling ordered tracking on HTML fields, a setting that caused saves to fail after editing those fields. This avoids a configuration path that could break invoice or other record updates when custom HTML fields are used.
Original PR description
From https://github.com/odoo/odoo/pull/241367#issuecomment-3711040501 Nothing prevent tracking from being enabled on HTML fields, but if it is enabled, updates of the field systematically fail. This commit avoids this error by hiding the "Enable Ordered Tracking" for HTML fields. Steps to reproduce: - Install sale and web_studio - Activate debug mode - Add a custom HTML field inside the invoice form view - Open the "More..." of the field (or go to Settings/Technical/Field) and go to the new field - Set "Enable Ordered Tracking" to 1 - Save - Go to an invoice and modify the new field - Save => An error was displayed task-5236436 Forward-Port-Of: odoo/odoo#242183
Accounting settings now prevent users from selecting receivable or payable accounts as default income or expense accounts. This avoids configuration mistakes that could later block bill creation with error messages.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Settings" - Edit "Expense Account" property **Issue:** It is possible to set a receivable or payable account for the property. If a payable account is set, a constraint will trigger a UserError when trying to create a bill with that account. The same issue happens for "Income Account". **Cause:** The field is a related field. On the original field, there is a domain to prevent selecting these types of account, but the domain is not applied to the related field. **Solution:** Checking the company will retrieve the domain set on the original field. opw-5492092 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246798
Fixed an issue where turning Studio on or off could disrupt the layout of a project-related button in Sales. This keeps the interface consistent and avoids visual confusion for users working with sales projects.
Original PR description
**Before this commit:** When the user toggled studio, the `action_view_project_ids` stat button layout would break. **After this commit:** The stat button layout no longer breaks. task-5480309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Calendar event descriptions now wrap inside popover windows instead of overflowing or being cut off. This makes longer descriptions easier to read and improves the usability of calendar event previews.
Original PR description
Changes done: - [x] `calendar`: Add `class="text-wrap"` in the description field of the calendar view to use it in the popover - [x] `web`: Define the appropriate class in the calendar popover field **Before** <img width="548" height="428" alt="antes" src="https://github.com/user-attachments/assets/77060ee6-30a1-47ed-8ba4-d5c2baa33fe3" /> **After** <img width="559" height="627" alt="despues" src="https://github.com/user-attachments/assets/cc9dfb47-3f98-4b5b-80c2-c3e5c15df0b0" /> @Tecnativa TT60670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246924
Automated tests now skip unnecessary device logging when test sessions are created. This reduces extra database activity during testing without changing normal user behavior in production.
Original PR description
In tests, when using `authenticate`, we create a session. When this session is retrieved (for example because we use `url_open`), we detect a new device and insert a log. The consequence is that a query is performed in many tests and that is not necessary. The fix consists of disabling the `res.device.log` feature by default in tests. task-5894825 Forward-Port-Of: odoo/odoo#246445
This fixes an issue where color overlays on website video backgrounds could disappear after a user selected the block and saved the page again. Website editors can now keep the intended visual styling without needing to reapply the filter.
Original PR description
The color filter applied to a video background would disappear after selecting the block and saving the page again. Steps to reproduce: =================== 1. Enter Edit mode on the website. 2. Drag…
The color filter applied to a video background would disappear after selecting the block and saving the page again. Steps to reproduce: =================== 1. Enter Edit mode on the website. 2. Drag and drop a snippet (e.g., "Intro"). 3. Set a video background for the block and apply a color filter. 4. Save the page. 5. Enter Edit mode again, click the block to select it, and Save. -> The color filter is removed from the video background. Cause: ====== Selecting the block triggers the `toggleBgImageClasses()` function. This function attempts to determine the background configuration. Since a video background is used, there is no standard image URL, so the code proceeds to call `setImageBackground` with an empty URL ([1]). This update process involves re-applying the color filter via the `selectFilterColor` action. However, the current background image style (the filter color) was not being passed to this function during this specific update flow. Consequently, the function assumed no filter existed and removed it ([2]). Solution: ========= Retrieve the current `filterColor` (which exists in background-image style) and pass it explicitly when calling the apply function. [1]: https://github.com/odoo/odoo/blob/fa482e36bc36809e55b6a11ebcc5bb130f20fd31/addons/html_builder/static/src/plugins/background_option/background_image_option.js#L18-L20 [2]: https://github.com/odoo/odoo/blob/fa482e36bc36809e55b6a11ebcc5bb130f20fd31/addons/html_builder/static/src/plugins/background_option/background_image_option_plugin.js#L170 opw-5448696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242236
This fixes an issue in the web editor's custom gradient picker where selecting pure white could unexpectedly reset the color slider to red. The change keeps the picker display consistent, reducing confusion when users fine-tune colors.
Original PR description
**Current behavior before PR:** In editor's custom gradient picker, if `#FFFFFF` is picked from the very top of picker area, the color slider is reset to color `red`. This happens because when moving picker pointer to the top of area, `selectedColor` prop is updated to `#FFFFFF`, which calls `onWillUpdateProps` callback. As result, `convertRgbToHsl` sets hue value 0 for `#FFFFFF`, setting color slider to red. **Desired behavior after PR is merged:** This commit ensures that in `onWillUpdateProps` callback, `setSelectedColor` should not get called if `newSelectedColor` is the same as `this.colorComponents.cssColor` to prevent updating UI twice while picking the color. task-5170041 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245558 Forward-Port-Of: odoo/odoo#236644
The API documentation generator now correctly displays full container parameter types, such as lists with their item type. This helps users and developers read more accurate method documentation and reduces confusion when integrating with APIs.
Original PR description
In python 3.10; When the type of a method parameter is a container (eg: `list[T]`), `stringify_signature` was not getting the full type but only the origin of it (eg: `list` instead of `list[int]`). This commit fixes the issue by stringifiying the container types separately. runbot-237782
This update resolves an issue where salary attachments would display an empty employee field after an employee was archived. The fix ensures that salary attachments accurately reflect the current employee status, preventing data inconsistencies and improving reporting accuracy. This change maintains data integrity for payroll records.
Original PR description
Steps To Reproduce: Create a salary attachment for an employee. Archive that employee. The corresponding salary attachment has an empty `Employee`. Issue: `employee_ids` many2many field doesn't take archived records into consideration, So when an employee is archived, it leads to emptying the record. Fix: Add active_test context to field definition and domain to form view of salary attachment so the employee remains on salary attachment and for new record creation, so it doesn't take archived employees. task-5438657 Forward-Port-Of: odoo/enterprise#106275 Forward-Port-Of: odoo/enterprise#102985
This update resolves an issue where uploading a new signature PDF would fail if the 'signature' item type (ID 1) was deleted. The problem stemmed from a previous change that created a dummy item to identify roles, leading to an error when no item type was found. This fix ensures a smooth sign upload process.
Original PR description
steps to reproduce :
- delete the sign.item.type with id 1 ("signature")
- try to upload a new pdf to sign
The issue appears since PR 91189 that creates a dummy item to recognize roles that can be vacuumed.
Since the item type of the dummy item is irrelevant, we now just try to find the first one we can to fill in the dummy item with an Error if none is exists.
Forward-Port-Of: odoo/enterprise#106219
Forward-Port-Of: odoo/enterprise#106138This update resolves a problem preventing users from viewing the package status for Lazada orders within picking and sale orders. The fix grants necessary access to the `lazada.order.item` model, which was previously restricted to 'Sales Administrator' users. This ensures all users can see the correct Lazada order information.
Original PR description
Versions -------- - 19.0+ Steps ----- Two issues: 1. Create a new user with `Sales "User: Own Documents Only"` rights, and `Inventory "User"`. 2. Try to access any picking or sale order. Issue ----- ``` Failed to read field stock.move.lazada_order_item_ids You are not allowed to access 'Lazada Order Item' (lazada.order.item) records. This operation is allowed for the following groups: - Sales/Administrator Contact your administrator to request access if necessary. ``` Cause ----- Both the picking form view and the sale order form view need access to the `lazada.order.item` model to display the pacakge status on Lazada. However, all Lazada specific models are only accessible with Sales "Administrator" rights. Solution -------- Add read access to `lazada.order.item` for stock and sales users.
This update resolves an issue where lengthy reconciled names on bank statements were being displayed as a long list of commas. The fix involves repositioning a text truncation element, resulting in a cleaner and more readable statement line display for users. This improves the overall user experience.
Original PR description
When we have a lot of reconciled names, it can happens that you just have a long list of comma. It's because the text truncate was misplaced. This commit will fix this by moving the text truncate no task id Forward-Port-Of: odoo/enterprise#105674
Before this commit, opening some malformed PDF failed during flattening because PyPDF2 strict parsing and form-field reads raised errors. After this commit, we try first parsing the PDF in the usual way and if we fail, we try again with strict=False. See https://pypdf.readthedocs.io/en/stable/user/robustness.html. task-5902859
Original PR description
Before this commit, opening some malformed PDF failed during flattening because PyPDF2 strict parsing and form-field reads raised errors. After this commit, we try first parsing the PDF in the usual way and if we fail, we try again with strict=False. See https://pypdf.readthedocs.io/en/stable/user/robustness.html. task-5902859
This update resolves an issue where the printer selection wizard could generate errors when attempting to use printers that had been removed from the database. By filtering out printers without corresponding devices, the system now avoids these errors, ensuring a smoother user experience.
Original PR description
Printers saved by the selection wizard in local storage can correspond to records that no longer exist in the database (removed in the meantime). To avoid a traceback when creating the wizard with non- existing printers, we filter out the ones that don't correspond to any device.
This update fixes an issue where recurring prices on ecommerce product pages used incorrect grammar, specifically displaying billing periods in singular form. The change ensures that recurring prices always use the correct plural form, resulting in a more professional and user-friendly experience for customers.
Original PR description
Issue: - On ecommerce product pages, recurring prices displayed incorrect grammar. - Billing periods greater than one were shown in singular form (e.g. 'Every 6 month' instead of 'Every 6 months'). Fix: - Updated recurring price display logic to use plural period labels when the billing period value is greater than one. Impact: - Recurring prices now display correct and user-friendly grammar. taskid-5529937
This update fixes an issue causing payment terminal receipt text to display with unwanted styling (borders and light/dark mode). The fix removes a specific CSS file that was incorrectly applied to the POS, ensuring a cleaner and more professional receipt appearance. This improves the user experience for customers using the point-of-sale system.
Original PR description
The `pos_appointment` module includes all of the `html_editor` assets into POS, despite only a small subset of the functionality being used. One of these assets was an SCSS file that set code block styling on all `pre` elements. Since the POS uses `pre` elements to display the text from payment terminals on the receipt, it was causing this text to be drawn with a border box and light/dark mode styling. The fix is to remove this specific SCSS file from the POS bundle. It shouldn't affect `pos_appointment` functionality since the code editing plugin is not loaded. Before: <img width="325" height="694" alt="image" src="https://github.com/user-attachments/assets/1c23ee18-0832-496f-b69e-8d9e90b5ed73" /> After: <img width="337" height="700" alt="image" src="https://github.com/user-attachments/assets/2998e66f-c582-422b-b3c7-31bcb849e75b" />
This update resolves an issue where users with only sales access couldn't view invoices. The fix grants the 'salesman' group the necessary read permissions to the asset data, allowing them to correctly access and manage invoices within the Enterprise module. This ensures sales teams have full visibility into related financial transactions.
Original PR description
### Issue: User with sale access group cannot access invoices. #### Steps to reproduce: - Install demo data - In user setting, `Access Rights` tab, remove `Accounting` access and set `Sale` access to Administrator for user Demo. - Log in using Demo user. - Create a SO, and after confirming, create an invoice. - As you see, you will get access rights error. ### Cause: Group salesman doesn't have `read` access on `account.asset`. As a result on enterprise, `account.move._compute_asset_ids` fails: https://github.com/odoo/enterprise/blob/c366abe1d3423d5e184675b5fb786b5f401ae94f/account_asset/models/account_move.py#L320 Community PR: odoo/odoo#242516 Ticket [link](https://www.odoo.com/odoo/project.task/5461135) opw-5461135
This update fixes an issue where the employee's filling status wasn't updating correctly when the associated address state was changed. The system now dynamically adjusts the filling status based on the employee's working address location, ensuring accurate payroll calculations for states like Alabama. This resolves a discrepancy in state-based filling status updates.
Original PR description
to reproduce: ============= - create employee and set working address with state in CA - set filling status to match the state - in the address record change the state to AL (don't change the record in employee) - go back to employee form view, filling status is still the same problem: ======== currently we are relying on a constraint to check if the filling status is valid for the state in the working address. But `api.constrains` doesn't support dotted paths, so modifying `address_id.state_id` doesn't trigger it. solution: ========= make the filling status computated field depending on `address_id.state_id` opw-5878740
This update adjusts the way product prices are stored within Odoo, ensuring greater accuracy and consistency. The change addresses a technical issue identified in previous testing, improving the reliability of price calculations. This update primarily impacts the core functionality of product management.
Original PR description
Fix tests, related to https://github.com/odoo/odoo/pull/243987 task-4895014 Forward-Port-Of: odoo/enterprise#106203 Forward-Port-Of: odoo/enterprise#104728