Monday, January 12, 2026
17 changes · 18.0
Enhancements to existing features
This pull request introduces basic testing for the Odoo runbot. It's a foundational step to ensure the runbot's reliability and stability, which is crucial for automated processes within Odoo. This change primarily focuses on internal testing and doesn't directly impact user-facing features.
Original PR description
using this commit we are just checking the odoo runbot
Resolved issues and error corrections
This update ensures that branch names on Thai tax invoices are displayed in the correct language based on the customer's language settings. Previously, all invoices used English regardless of the partner's language. This improves the accuracy and professionalism of invoices for Thai customers.
Original PR description
Currently, l10n_th_branch_name is not translatable. Regardless of the language setting, it is printed in English on the tax invoice. This PR addresses that. Task-5438534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue where logging was incorrectly triggered when viewing sales quotes within the Odoo portal. The fix prevents unnecessary requests to the quote URL, ensuring accurate logging and a smoother user experience. This improves system stability and reduces potential performance impacts.
Original PR description
Steps: - Install sales app. - Copy portal of an SO. - use it in editor link or somewhere where preview_url is used. Issue: - Quotation viewed log note adding on the SO. Cause: - `get_link_preview_from_url` method do request on the url that's why it calling it's controller and adding log note. Fix: - Add check for uid in session or `Sec-Fetch-Site` in request header to ensure request is actually coming from user not from some method. opw-5409727
This update ensures that eTIMS configuration warnings are displayed only for companies operating in Kenya. Previously, these warnings appeared for all companies, causing confusion. This change improves the accuracy and relevance of the warnings, streamlining the user experience.
Original PR description
Before: In multi-company setups, the eTIMS configuration warning was shown even when working in companies that are not based in Kenya. This resulted in confusing and irrelevant warnings for users using other localizations. After: The eTIMS configuration warning is now limited to Kenyan companies only. Non-Kenyan companies are no longer impacted, keeping the validation relevant while preserving the intended eTIMS behavior. task-5462334
This update prevents a problem where users in different branches could accidentally create duplicate tax names. Previously, Odoo only checked for duplicates within a user's visible branches. Now, Odoo checks all branches to ensure each tax name is unique, avoiding errors and streamlining accounting processes for companies with multiple locations.
Original PR description
**Description of the issue/feature this PR addresses:** In companies with many branches, a user could create a tax name that already exists in another branch. This happened because Odoo only checked for duplicates in the branches the user could see. To reproduce: 1. Create `Branch A` and `Branch B`. 2. A user with access ONLY to `Branch A` creates "Tax 1". 3. A user with access ONLY to `Branch B` creates "Tax 1". 4. Both are saved, creating a duplicate name. This fix adds sudo() to the check. Now, Odoo will check all branches to make sure the name is unique, even if the user cannot see the other branches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the year field in certain payroll reports was incorrectly displaying a comma. Removing the comma ensures accurate reporting and consistent data presentation for Belgian payroll calculations. This change improves the reliability of financial reports.
Original PR description
. Remove the comma on the year filed on the crossponding reports task-5417861
This update corrects a bug where admin users could inadvertently change the default options for course ratings. The fix ensures that existing ratings and reviews remain unchanged, regardless of edits or deletions made by administrators. This maintains the integrity of course feedback data.
Original PR description
*: website_slides The default values for the admin user should not be changed by editing or deleting others' messages in courses. task-5326273
This update corrects a bug that occurred when a leave request was linked to a refused allocation and the 'Time Off: Cancel invalid leaves' cron job ran. The fix prevents an error caused by accessing an empty data structure, ensuring the system handles refused allocations correctly.
Original PR description
When a leave is linked to a refused allocation and the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs. Steps to reproduce the error: - Install ``hr_holidays`` without demo data -…
When a leave is linked to a refused allocation and
the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs.
Steps to reproduce the error:
- Install ``hr_holidays`` without demo data
- Create a new Time Off Type > Time Off Requests, Approval: No Validation >
Allow Negative Cap: True > Maximum Excess Amount: 2
- Create an Accrual Plan using default values
- Create a New Allocation
- Allocation Type: Accrual Allocation
- Set the Time Off Type and Accrual Plan created above
- Allocation: 1 day > Approve
- Create a new Time Off in the near future (in the current month) and select the Time Off Type created above
- Go back to the Allocation > Refuse
- Run the cron ``Time Off: Cancel invalid leaves``
Traceback:
``IndexError: list index out of range``
https://github.com/odoo/odoo/blob/bc5f24195a486112574900015ecbcf0e3ba32145/addons/hr_holidays/models/hr_leave.py#L1535-L1536
Here, ``leave_type_data`` becomes ``defaultdict(<class 'list'>, {})``
because when the allocation is refused and the cron runs,
the ``get_allocation_data`` method returns an empty defaultdict.
As a result, accessing the index leads to the above traceback.
sentry-6874651972
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update ensures that Manufacturing Orders created through the MTO (Make to Order) route correctly link back to the original Sales Order. Previously, the link was missing, hindering reporting and traceability. This fix ensures accurate tracking of products moving through the manufacturing process.
Original PR description
Problem: Manufacturing Orders should contain information about their origin, but during an MTO route, sale_line_id remains unset after the MO is created when the Sales Order is confirmed. Solution: While preparing the values for the MO (`_prepare_mo_vals`), we will assign the `sale_line_id` based on the MO's move, which has the origin sale_line_id during the MTO route. Steps to replicate on Runbot 18: - Product with MTO and Manufacture routes - BoM with at least one component 1. Create a Sales Order for the product and confirm 2. Navigate to the MO via the smart button 3. Check the field sale_line_id with the inspector, note it is False. opw-5257401
This update fixes an issue where newly created channels weren't immediately visible in the Kanban view. The change ensures channel creators receive a notification, making the channel appear instantly without needing a manual refresh. This improves the user experience and streamlines channel creation.
Original PR description
**Description of the issue/feature this PR addresses:** When creating a channel from the Kanban view, the newly created channel was not visible until a manual refresh. **Current behavior before PR:** When a channel is created from the Kanban view, it does not appear immediately. This happens because the channel creator does not receive the bus notification upon channel creation. **Desired behavior after PR is merged:** The channel creator now receives the bus notification, ensuring that the newly created channel is immediately visible in the Kanban view without requiring a manual refresh. Backport of : #228348 task-[4510421](https://www.odoo.com/odoo/project/1519/tasks/4510421) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a potential issue where canceling a payment could inadvertently unlink related accounting movements. This change ensures data integrity by preventing the removal of these movements, maintaining accurate financial records. It's a small but important fix for reliable accounting operations.
This update resolves an issue where users without specific group permissions would encounter errors when pinning or unpinning embedded actions. Previously, this prevented superuser mode operations (like automated tasks) from functioning correctly. Now, the system checks if the environment is in superuser mode, allowing for seamless action management regardless of user group membership.
Original PR description
Prior to this commit, an AccessError would be raised when pinning or unpinning embedded actions if the current user did not belong to the 'documents.group_documents_user' group. This could cause issues during operations running in superuser mode (e.g., automated actions, installation scripts, or sudo() calls) because the check strictly validated the user's groups without considering the environment's superuser flag. This commit adds a check for `self.env.su` to ensure the AccessError is not raised when the environment is in superuser mode. Task-5380727
This update resolves an issue where the Point of Sale tour would fail when selecting products with configuration options. The fix ensures that the tour only selects products without configuration, preventing the popup failure and improving the tour's reliability. This enhancement ensures a smoother experience for users.
Original PR description
In certain cases, the product selected in the tour would be a product that require a configuration (having attribute lines), which would lead opening a popup that is not handled in the tour, leading to a failure. When selecting the product we now make sure that we select a product that does not require any configuration. same fix as this one : https://github.com/odoo/odoo/pull/241098 runbot-234734
This update resolves an issue where importing electronic invoices would fail if a bank account already existed for the same supplier, even on a different company. Now, the system correctly identifies and utilizes pre-existing bank accounts linked to the same supplier partner, streamlining invoice import processes.
Original PR description
Description of the issue/feature this PR addresses: Imagine a situation where a vendor is defined on a parent company and its bank account already exists. When importing an electronic invoice for…
Description of the issue/feature this PR addresses: Imagine a situation where a vendor is defined on a parent company and its bank account already exists. When importing an electronic invoice for that vendor on a child company, the search for a bank account linked to the same company would not find that pre-existing bank account on the parent company. When later trying to create it, the unicity constraint on (sanitized_acc_number, partner_id) would trigger, failing the import. Current behavior before PR: The electronic invoice cannot be imported if the same IBAN account already exists on the partner but on another company than the invoice being created, even though we are going to create the invoice for a partner linked to that other company. Desired behavior after PR is merged: Banks account already linked to the partner are found irrespective of the company, provided the partner (account holder) is the same. This should be correct since the res.partner.bank company_id is a related on res.partner. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a technical issue within the Accounts Coverage Report that was incorrectly flagging duplicate report lines. The fix ensures the report accurately reflects account data without these false positive errors, improving data reliability for financial reporting. This change impacts the accuracy of balance sheet reporting.
Original PR description
Reproduce the bug: -Install Ireland(ie) reports -Enable debug mode -Go to Reporting>Balance Sheet>Accounts Coverage Report -The generated sheet should have false positive duplicates error Fix: Ignore the report lines that has the same name and the same code task: 5373732
This update ensures that thumbnails are correctly updated for shared requests, even when accessed publicly. Previously, public users accessing shared requests didn't see updated thumbnails. This change resolves an issue where thumbnail propagation was skipped due to user permissions, ensuring a consistent experience for all users.
Original PR description
Bug === 1. Create a request 2. Create a shortcut to that request 3. Share it to public 4. Public upload => The thumbnail is updated on the document, but not on the request. The reason is that the public user has `user_permission = none`, because he has only access with the token, and so we skip the thumbnail propagation. This has no sense, because if we don't have access on the document, we loose the access on the shortcut (even if we are the owner). Task-5485511
This update fixes an issue where Time-Off Responsible users couldn't refuse fully accepted leave requests. The fix ensures these users have the necessary permissions to unlink related calendar entries, allowing them to properly manage leave requests as intended. This improves the usability of the HR holiday management process.
Original PR description
****Behavior:**** When a user who is Time off Responsible but not Officer or Admin and is marked as responsible for an employee tries to refuse a fully accepted leave an access error occurs. This…
****Behavior:**** When a user who is Time off Responsible but not Officer or Admin and is marked as responsible for an employee tries to refuse a fully accepted leave an access error occurs. This occurs because approving a leave creates a resource.calendar.leave linked to the hr.leave, and when refusing it, the system will try to unlink it. https://github.com/odoo/odoo/blob/72e8a29dd0edb0ca3d464142ce869f38f96c730a/addons/hr_holidays/models/hr_leave.py#L896-L901 According to access rules of r.calendar.leaves, Time-off Responsibles are not allowed any access for entries of other employees. Approving them doesn't cause an error because the create operation uses sudo(), assuming that the user must have had valid rights to access the function. This is not the case for the unlink. **Solution:** This fix checks wether the user has write access to the related hr.leave record, then uses sudo(). The idea is that if they are allowed to modify the state of the leave, they can refuse the leave, and therefore should be able to go through the following operations. This is in a similar fashion as the behavior for approving the leaves. ****Steps to Reproduce:**** - Create a Leave Type that requires validation from a manager, and assign one to an employee. - Remove any access rights to Time-Off for the user, but leave Time off Responsible checked. - Assign the user as time-off responsible for the employee - Log in as the user and approve the leave - When refusing the leave, you should get an access error. opw-5178783