Tuesday, June 16, 2026
22 changes · saas-19.1
Resolved issues and error corrections
A technical issue prevented users with specific access rights from viewing leave information in the Attendances Gantt View. This update corrects a rare access error that occurred when calculating leave intervals, ensuring all users can accurately see approved leave on the Gantt chart. The fix adds a temporary access layer to ensure correct calculations.
Original PR description
Version: - 19.0 Steps to reproduce: - Install Attendances and Time Off - Create an internal user. - Give the user: Attendances Officer access & No Time Off Officer/Manager rights - Create an employee…
Version: - 19.0 Steps to reproduce: - Install Attendances and Time Off - Create an internal user. - Give the user: Attendances Officer access & No Time Off Officer/Manager rights - Create an employee linked to the user. - Configure the employee with a Flexible Working Schedule. - Create and approve a Time Off request for the employee. - Open: Attendances -> Gantt View - Navigate to the month containing the employee's approved leave. Issue: - An access error is raised when opening a month that contains the employee's approved leave. Cause: - In `_handle_flexible_leave_interval`, the code accesses `leave.holiday_id` to read fields such as `request_unit_half`, `request_unit_hours`, and `request_hour_from/to` on the `hr.leave` model. - When the current user has Attendances Officer rights but no Time Off access(rare cases), the ORM access check on `hr.leave` raises an AccessError, even though this read is purely for internal calendar computation and does not expose leave data to the user interface. Fix: - Added sudo() on holiday_id to access the employee's leave details and compute the work interval as expected. Task-6264510 Forward-Port-Of: odoo/enterprise#119116
This update corrects a bug where inactive or archived taxes were incorrectly displayed in the bank reconciliation process. The fix ensures that users only see active taxes when reconciling bank statements, improving data accuracy and preventing potential errors in financial reporting. This resolves issue OPW-6245641.
Original PR description
### Issue:
When editing a line within the bank reconciliation widget, inactive and archived taxes are incorrectly available for selection
### Cause:
The bank reconciliation edit line form view carried the `{'active_test': False}` context on the `tax_ids` field
This context allowed archived taxes to be loaded and selected during creation and manual edition
### Fix:
Explicitly force `active_test: True` in the view context for the tax field to ensure only active taxes can be searched and selected by the user
### Steps to reproduce:
- Install `account_accountant`
- Create a new tax and set it to inactive
- Go to the Bank Reconciliation widget
- Create a bank statement line
- Set the account to 600000 Expenses
- Edit the line by clicking on the pencil icon
- Open the Taxes selection dropdown
Before the fix, the inactive tax is visible and available for selection by default
opw-6245641
Forward-Port-Of: odoo/enterprise#119522This update simplifies the messages displayed when a new task is created in Odoo, consolidating two lines into a single, clearer message. This change was made to improve the user experience and avoid confusion, specifically targeting new Odoo 19.1 installations. The fix addresses a technical issue related to message formatting.
Original PR description
Before this commit, when a new task was created in `project.task`, its creation message spanned two lines: "task created" and "task created for project XYZ". This commit unifies them into one to avoid confusion. The first line was caused by the message template having a description attribute. Even though editing the description will not fix the issue for existing databases, we chose to target the earliest possible version that a new customer might start from. The problem does not exist in 19.0. task-5999819
This update improves the accuracy of the reconciliation process by ensuring the matching dialog displays both draft and posted journal items. Previously, the dialog was limited by a default filter, leading to a reduced number of matching results. This change provides a more complete view for users to reconcile transactions.
Original PR description
The reconcile badge counts draft and posted journal items, but the matching dialog forces a posted filter by default, this makes the dialog show fewer lines than count as it discards the draft ones. Remove the default posted search filter so the dialog displays all matching items. task-6234801 Forward-Port-Of: odoo/enterprise#118146
This update fixes a visual issue on mobile devices where an unwanted caret appeared next to the 'Expand' button in the Inbox. It also corrected the alignment of header buttons, preventing them from wrapping onto multiple lines when the messaging menu was open. This ensures a cleaner and more professional user experience on mobile.
Original PR description
On mobile, an unwanted caret was displayed next to the message 'Expand' button in the Inbox because the messaging menu itself opens a dropdown, causing any nested Dropdown to automatically display a caret. This commit also fixes the alignment of the Inbox header action buttons, which wrapped onto multiple lines when opening the messaging menu on mobile while the Inbox tab was already selected. In this case, the `AutoresizeInput` width was computed at its maximum size, leaving insufficient space for the header action buttons and causing them to wrap onto multiple lines. Task-[6244177](https://www.odoo.com/odoo/project/1519/tasks/6244177) Forward-Port-Of: odoo/odoo#266343
This update fixes a bug where follow invitations weren't appearing in user inboxes unless a comment was added. The change ensures that the notification subject is always displayed, regardless of the comment content, ensuring users receive timely follow invitation notifications. This improves the user experience and prevents missed invitations.
Original PR description
Steps to reproduce: - Configure user A to receive inbox notifications. - As user B, invite user A to follow a record with Notify recipients enabled. - Open the inbox of user A. The Invitation to follow notification is not displayed in the inbox when no additional comment is provided. This happens because the notification body is empty unless extra comments are added. This commit fixes the issue by displaying only the subject when the body is empty. Task-[5485727](https://www.odoo.com/odoo/project/1519/tasks/5485727) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269511 Forward-Port-Of: odoo/odoo#244653
This update adjusts the format of unit prices in Polish VAT invoices (l10n_pl_edi) to ensure accurate calculations with the KSEF system. While the existing system technically works, this change aligns the unit price and total without tax, improving invoice accuracy and compliance. This resolves a minor discrepancy impacting invoice presentation.
Original PR description
**STEP TO REPRODUCE** 1. Create an invoice with a unit price of 10.005 and qty of 2. 2. Send the invoice to ksef. 3. Open the xml and notice P_9A (unit price) is 10.00 and P_11 (total without tax) is 20.01 Which is inconsistent (10.00 * 2 =/= 20.01). This PR increase the decimal places of P_9A to 8 digits which is the maximum allowed by the FA(3) format. Note that Ksef doesn't verify the untaxed unit price * quantity = total without tax, so the invoice we send are technically valid. However, it's best to generate invoice where the numbers add-up. opw-6203896 Forward-Port-Of: odoo/odoo#263812
This update resolves a bug where composite actions within website options could fail when using a 'getValue' function. The fix adds a test to ensure the action is properly bound, preventing errors and improving website functionality. This ensures consistent behavior across Odoo versions.
Original PR description
In 18.4 the composite action isn't used extensively, so the problem was unnoticed. However, if you use it with an action that has a `getValue` set, you may get issues, since the action will not be bound. Possible way to reproduce the issue: - Create an option that uses the `composite` action - Set `customizeWebsiteVariable` as a first action in the `actionParam` - Click on an element that has that option => You'll get an error. Note, that testing just this would be useless, so I added a test that tests that the action uses the first `getValue`. Without this fix the test would crash since in `getValue` `this` is unbound. Forward-Port-Of: odoo/odoo#269873
This update addresses a technical issue that could cause a software error when comparing history differences. The fix ensures the system gracefully handles empty history data, preventing a potential crash. This improves the stability and reliability of the web editor feature.
Original PR description
If, for whatever reason, the history we try to compare is an empty string, we might get a value error thrown. We guard the code to avoid the error. see :https://github.com/odoo/odoo/issues/269149 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269722
This update fixes an issue where long text labels in SelectMenu multi-select tags were not being truncated, leading to a cluttered and less readable user experience. Now, tags are automatically shortened to fit, aligning with the design of Many2ManyTags and improving visual clarity.
Original PR description
Before: Tags in SelectMenu (multi-select) had no text-overflow handling. After: Tags now truncate text, consistent with Many2ManyTags behavior. task-5226503
This update fixes a minor visual issue in the web_studio module, where property tags within the SelectMenu were constrained to a limited width. Now, tags automatically expand to fill the available screen space, creating a cleaner and more user-friendly experience. This ensures a consistent and optimized layout for all property selections.
Original PR description
Before: Each tag was limited to 200px, leaving available space unused. After: Each tag now expands to 100% of the available width. task-5226503
This update resolves an issue where product searches weren't working correctly when using the autocomplete feature. The fix adjusts how product names are matched during searches, ensuring accurate results regardless of the search method (copy/paste or direct input). This improves the user experience when finding products.
Original PR description
Steps: - Create a product with a barcode "12345" - Create a sale order - Add a product - search product with name "12345" without copy/pasting - no result - try with copy/pasting - 1 result The problem is due to the fact that there is an optimization in Many2XAutocomplete.search which means that if no results are found for “1234,” it will not search for “12345.” However, product override name_search to returns a product only when the name is exactly equal to its barcode (`=` and not `ilike`), which does not work at all with search optimization. Since: https://github.com/odoo/odoo/pull/228035 opw-5908011 Forward-Port-Of: odoo/odoo#247978
This update resolves an issue where users were unable to edit the names of multiple projects simultaneously. The fix prevents a technical error that occurred when updating the names of multiple projects at once, ensuring a smoother user experience for managing project names.
Original PR description
Currently, an error will occur when user multi edits name of projects. Steps to replicate: - Install `project` and open projects. - From the list view select multiple projects and edit their name.…
Currently, an error will occur when user multi edits name of projects.
Steps to replicate:
- Install `project` and open projects.
- From the list view select multiple projects and edit their name.
Error:
```
File '/home/odoo/src/odoo/saas-19.3/addons/project/models/project_project.py', line 754, in write
analytic_account_to_update.write({'name': self.name})
File '/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py', line 1728, in __get__
record.ensure_one()
File '/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py', line 5341, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: project.project(8, 9, 10)
```
Cause:
- As multiple records were changed at the moment, `self` had multiple recordsets and trying to access `self.name` [1] causes this error.
Solution:
- Avoided accessing `self.name` on a multi-recordset during multi-edit.
- Updated analytic account names using the name recieved in the vals.
[1]: https://github.com/odoo/odoo/blob/a69ec43f490735f639292d116b0207182c5b2581/addons/project/models/project_project.py#L608
sentry-7452096418
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#269830
Forward-Port-Of: odoo/odoo#267620This update ensures that when users rename multiple projects simultaneously, the linked folder names are automatically updated. Previously, the system didn't reflect these changes, leading to inconsistencies. This fix improves data accuracy and simplifies project management.
Original PR description
Currently, when user multi-edits projects names from list view the linked folder name doesnt get updated. Steps to replicate: - Install `documents_project` and open projects. - Select multiple projects and edit their names. Issue: - The project names get updated but their respective linked folder's name doesnt get updated. Cause: - During multi-edit, `self.documents_folder_id` contains the folders of all selected projects. - As a result, `len(self.documents_folder_id.project_ids) == 1` [1] is evaluated on the combined recordset instead of per project, causing the condition to fail whenever multiple projects are renamed. Solution: - Avoided accessing `self.name` on a `multi-recordset` during multi-edit. - Filtered projects individually and updated their document folders using the name in vals. [1]: https://github.com/odoo/enterprise/blob/3c2985ca6011700c271ed14e40e08c89be822753/documents_project/models/project_project.py#L101 sentry-7452096418
This update fixes a visual issue where portal cards on the customer portal lacked a background color. The issue was caused by a default color setting being incorrectly initialized. Now, all portal cards will have a consistent background color, improving the overall user experience and visual appeal.
Original PR description
Steps to reproduce: 1. Go to the "/my" or "/my/home" page. Issues: Portal cards do not have a background color by default. Cause: The `portal-card` color variable was initialized with a `null` value, preventing any default background color from being applied to portal cards. task-6250258
This update optimizes the MRP work order process by preventing unnecessary BoM explosions for quality points like instructions and pass/fail checks. Previously, this process was slow, but now it's significantly faster, improving work order processing times. This change focuses on efficiency and reduces the load on the system.
Original PR description
`_compute_component_ids` unconditionally called `bom.explode()` for every product variant on the BoM, even for quality point types (`instructions`, `pass_fail`, etc.) that never use the `component_id` picker. The field is only meaningful for `register_consumed_materials` and `register_byproducts`. Restrict the expensive path to those two types with an `elif` so all other types return `component_ids = False` immediately. | # Input data | Before PR | After PR | |:---:|:---:|:---:| | 10 variants, 10 components, 2 phantom BoMs, 3 ops | 841 ms | 0.1 ms | | 30 variants, 20 components, 5 phantom BoMs, 3 ops | 1,343 ms | 0.1 ms | | 80 variants, 40 components, 12 phantom BoMs, 5 ops | 8,674 ms | 0.1 ms | OPW-6210368 Forward-Port-Of: odoo/enterprise#118470
This update corrects a problem where Google Calendar attendee information wasn't syncing correctly when an attendee's email matched a configured alias. The fix ensures that all Google attendees are properly synchronized, preventing data loss and improving the reliability of calendar events. This resolves an internal issue (opw-6086240) impacting event attendance accuracy.
Original PR description
_get_sync_partner excludes partners whose email matches a configured alias, returning a list shorter than the emails/google_attendees lists. zip() stops at the shortest, silently dropping the last Google attendee instead of the alias-matched one. Fix by replacing the positional zip with a by-email dict lookup, so each attendee is resolved independently and only the unresolvable one is skipped. opw-6086240 Forward-Port-Of: odoo/odoo#263787
This update fixes an issue where overtime details weren't correctly displayed in attendance records. The visibility condition for overtime information was reversed, preventing accurate reporting. This change ensures that overtime hours are now correctly shown when creating attendance records, providing more reliable tracking of employee time.
Original PR description
Steps: * Create an extra-hours attendance for an employee that has overtime ruleset OR * Create an extra-hours attendance for an employee that has no overtime ruleset Issue: * The overtime details in the attendance view visibility condition was flipped Solution: * Reverse the visibility condition of the XML element Task: 6295710 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#269744
A confusing error message related to loyalty discount codes has been resolved. The fix clarifies the issue for users, ensuring they understand why a discount wasn't applied when a minimum purchase requirement wasn't met. This improves the user experience and reduces potential frustration.
Original PR description
Issue: Error message was ambiguous and left users wondering what was wrong. Steps to reproduce: Set a discount code where the conditional rule is set to "minimum purchase" among specified products. Then, spend an amount larger than this on unrelated products and try to apply the discount code. "A minimum of x(currency) should be purchased to get reward" Cause: Poor error message caused ambiguity Solution: Corrected the error message so that the user can better understand where the issue is. opw-6290514 Forward-Port-Of: odoo/odoo#269319
This update simplifies accessing employee profiles from the avatar card. Previously, a confirmation dialog forced users to activate inactive companies. Now, a 'View Profile' dropdown offers two options: directly opening the employee profile (activating the company) or accessing the contact profile without company activation. This provides a smoother user experience while addressing potential concerns about broad company scope.
Original PR description
When opening a profile from the avatar card, the employee's company may not be in the user's active companies. Until now this popped a confirmation dialog that only let the user either activate the…
When opening a profile from the avatar card, the employee's company may not be in the user's active companies. Until now this popped a confirmation dialog that only let the user either activate the other company or cancel, with no way to reach the still-accessible contact profile. Replace the dialog with a less intrusive "View Profile" dropdown, shown only when the employee's company is allowed but not active. It offers two choices: - Open Employee Profile (activates the company) - Open Contact Profile (no company activation) Activating an extra company widens the active-company scope for the whole session, which is not always desirable, so keeping a non-mutating path to the contact profile is useful. In every other case (no employee, company already active, or company not allowed) the plain "View Profile" button is unchanged. task-6074597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264073
This update resolves an issue where UBL import failed due to a mismatch between the product's and imported unit of measure categories. The fix allows imports to proceed without error, and users can manually adjust the UoM after the import is complete. This improves the reliability of UBL invoice processing.
Original PR description
The new collected_values UBL import flow sets product_uom_id from the XML unitCode without checking that the resolved UoM category matches the matched product's UoM category. When they diverge, writing the line triggers the incompatible error. Steps to reproduce: - Create a product "XYZ" with UoM "Units" (category "Unit"). - Import a Peppol UBL bill whose line has Item/Name "XYZ" and unitCode="MTK" (uom_square_meter, "Surface"). - Import fails with: "The Unit of Measure (UoM) 'm²' you have selected for product 'XYZ', is incompatible with its category : Unit." This fix will avoid setting the product_uom_id when the UoM category doesn't match the product's UoM category, allowing the line to be imported without error. The user can then manually set the correct UoM after import. opw-6121714 Forward-Port-Of: odoo/odoo#269933 Forward-Port-Of: odoo/odoo#269714
This update fixes a potential instability issue with the PDP registration process. By moving a key function to the company record, we ensure the registration process remains reliable even if the temporary PDP registration model is deleted. This improves the overall robustness of the system.
Original PR description
The aim of this commit is to move _get_iap_url on res.company model instead of pdp.regitration. This move is made for 2 reasons: 1. PDP registration is a transient model which means that the object could be deleted in the time. 2. PDP registration implementation was using the model (api.model) and the record (self.edi_mode) which is a bad implementation. So by moving this function on company, we ensure that we always have a record to call the function and then the function is no longer an api.model. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270345