Tuesday, June 16, 2026
25 changes · saas-19.2
Enhancements to existing features
This update automatically populates the company registry information in Odoo for Swedish businesses based on their VAT number. Swedish VAT numbers always start with 'SE' followed by digits, and this change uses that pattern to accurately identify and fill in the company registry. This improves data accuracy and streamlines accounting processes for Swedish customers.
Original PR description
Organization number is part of the VAT number Official reference: https://www.skatteverket.se/foretag/moms/kopavarorochtjanster/inkopfranandraeulander/kopavarorfranandraeulander.4.3a7aab801183dd6bfd380005738.html > I Sverige börjar alla VAT-nummer med bokstäverna SE (landskoden) och avslutas med siffrorna 01. Om du har en enskild firma följs landskoden av de 10 siffrorna i ditt personnummer. Om du har ett bolag eller en förening följs landskoden av de 10 siffrorna i organisationsnumret. VAT-numret skrivs utan bindestreck. which translates to > In Sweden, all VAT numbers begin with the letters SE (the country code) and end with the digits 01. If you are a sole proprietor, the country code is followed by the 10 digits of your personal identification number. If you are a corporation or an association, the country code is followed by the 10 digits of your organization number. The VAT number is written without a hyphen. Forward-Port-Of: odoo/odoo#269590
This update changes the color of the 'To Review' status badge on employee records from grey to orange. This improves readability, particularly in dark mode, ensuring that HR staff can quickly identify and address employees needing review.
Original PR description
The 'To Review' status on employees uses a grey badge ('secondary'), which has poor contrast and is nearly invisible in dark mode.
Update the 'review_state' field options to change '2_to_review' to 'warning' (orange). This ensures the badge is readable in both light and dark modes.
Task: 6289919
Forward-Port-Of: odoo/enterprise#120268Resolved issues and error corrections
This update resolves an issue where inactive or archived taxes were incorrectly displayed in the bank reconciliation widget. The fix ensures that users only see active taxes during reconciliation, improving data accuracy and preventing potential errors in financial reporting. This change enhances the reliability of the reconciliation process.
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#119522Features or functions removed from Odoo
This update removes a redundant override related to payment processing through payment terminals. The removal of fast payments using terminals made the previous override unnecessary, streamlining the system. This change improves efficiency and reduces complexity.
Original PR description
We removed fast payments using payment terminals, making the `fastPayments` method override useless. see odoo/odoo#270240 task-6303855
This update adjusts the format of unit prices in Polish VAT invoices (l10n_pl_edi) to ensure accurate calculations and alignment with FA(3) standards. While the current system technically complies with KSEF requirements, this change improves invoice consistency and avoids potential discrepancies. This ensures proper reporting for Polish tax purposes.
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 using composite actions with certain website options could cause errors. The fix ensures that actions within these composites are properly bound, preventing crashes and improving the stability of website functionality. This change enhances the reliability of our website experience.
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 resolves a bug that prevented financial reports from correctly sorting when account codes contained 'None' values. The fix converts account codes to integers to ensure accurate sorting and prevent crashes, improving the reliability of financial reporting data.
Original PR description
If you're grouping by account_code on a line using an account_code
engine, and there's a None value, it will crash.
To get that, you can (with demo data):
- install l10n_be
- set "BE Company COA" as the main, keeping "My Company (San Francisco)"
activated
- go to the profit and loss "Profit and Loss (Abbr) (BE)", set the date
as the current year
- set "Consolidation" filter
- Unfold "60/61 - Goods for Resale,..."
```
Traceback (most recent call last):
...
File "... in _compute_formula_batch_with_engine_account_codes
results_list.sort(key=lambda x: math.inf if x[0] is None else x[0])
TypeError: '<' not supported between instances of 'float' and 'str'
```
Because in case of `None`, we compare with `math.inf` but the account
codes are string.
no-task
Forward-Port-Of: odoo/enterprise#120531This update resolves an issue where demo leave allocations wouldn't properly validate during an Odoo upgrade from 17.0 to 18.0. The fix ensures that the approval process is executed correctly, allowing leave allocations to be accurately created and managed across different installation scenarios.
Original PR description
Steps: - Install an Odoo 17.0 database with the Indian Payroll module and demo data. - Upgrade the database to 18.0. Issue: - The Indian payroll demo data creates leave allocations and approves them…
Steps: - Install an Odoo 17.0 database with the Indian Payroll module and demo data. - Upgrade the database to 18.0. Issue: - The Indian payroll demo data creates leave allocations and approves them through an XML function call. - During a fresh installation, demo files are loaded in 'init' mode, so the approval function is executed and the allocations move from 'confirm' to 'validate'. - However, during a 17.0 >>> 18.0 upgrade, demo files are loaded in 'update' mode. Odoo automatically loads demo files with 'noupdate=True' from the load_demo() >> load_data() function: - This value is passed to the XML importer and becomes the default noupdate state for the file. Since the demo XML file does not explicitly override this value, the function tag uses 'noupdate=True'. - When the XML parser reaches the approval function, _tag_function() skips its execution because of noupdate = 'True' and mode = 'update' condition. - As a result, the approval function is not executed during the upgrade and the leave allocations remain in 'confirm' state. Subsequent demo payroll data expects validated allocations and fails during loading. Fix: - Explicitly set 'noupdate=0' on the demo XML file. This overrides the default 'noupdate=True' value applied to demo files, making the parser evaluate the section with 'noupdate=False'. - As a result, '_tag_function()' executes the approval method during upgrades, the demo leave allocations are validated in both fresh/new db installations and 17.0 >>> 18.0 upgrade scenarios. runbot error-https://runbot.odoo.com/odoo/error/230430 task-6268381 Forward-Port-Of: odoo/enterprise#119217
This update introduces a time limit for profiling queries within Odoo. Previously, profiling could run indefinitely, consuming resources. Now, queries are automatically tracked and timed, ensuring efficient resource usage and preventing performance issues.
Original PR description
Modify the query collector so that it add an entry before the query runs and updates the time after it runs. use the async collector periodic sampling to commit the profiler after a time limit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268750 Forward-Port-Of: odoo/odoo#215034
This update resolves an issue where employee profile images were appearing stretched in the Odoo system. The fix involved adjusting image sizing within the employee form view to ensure consistent and proper display. This improves the visual presentation of employee profiles.
Original PR description
Vertical images were stretched due to changes made during the form view's redesign (a58ed7d) and after adding a fixed size (6d40ab9). We've added an `.object-fit-contain` class to fix this issue and a rounded border to make the image's aligned with other similar views. task-5418517 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269171 Forward-Port-Of: odoo/odoo#262033
This update addresses a technical issue that could cause errors when comparing history differences in the web editor. The fix prevents a value error from occurring if the history data is empty, ensuring smoother operation for users. This improves the stability and reliability of the web editor functionality.
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 corrects a technical issue preventing accurate calculation of leave durations within the holiday reporting feature. The fix ensures the system correctly identifies the appropriate resource calendar, resolving a singleton error that was causing incorrect leave calculations. This improves the reliability of leave reports.
Original PR description
resource_calendar was not being when calculting virtual leaves, it leads to a singleton error here:…
resource_calendar was not being when calculting virtual leaves, it leads to a singleton error here:
https://github.com/odoo/odoo/blob/11b0195dddad5055fc33fa3e28b2d2ca60f24935/addons/l10n_fr_hr_holidays/models/hr_leave.py#L163
```
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 519, in _table_sql
table_query = self._table_query
^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/hr_holidays/report/hr_leave_employee_report.py", line 40, in _table_query
self._compute_leave_duration(report_records)
File "/home/odoo/src/odoo/saas-19.2/addons/hr_holidays/report/hr_leave_employee_report.py", line 94, in _compute_leave_duration
leaves_durations = virtual_leaves._get_durations(additional_domain=[('holiday_id', 'not in', leave_ids)])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_fr_hr_holidays/models/hr_leave.py", line 160, in _get_durations
while not leave.resource_calendar_id._works_on_date(date_start):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/resource/models/resource_calendar.py", line 877, in _works_on_date
self.ensure_one()
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 5253, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: resource.calendar()
```
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-prA technical issue prevented users with specific access rights from viewing leave information in the Attendances Gantt View. This fix ensures that the Gantt View correctly displays leave requests, even when users have limited Time Off permissions. The change uses a security enhancement to access necessary data for accurate calendar 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#120587 Forward-Port-Of: odoo/enterprise#119116
This update resolves an issue where users experienced errors when simultaneously editing the names of multiple projects. The fix avoids accessing project names within a multi-record edit, ensuring smoother operation and preventing data inconsistencies. This improves the user experience when managing multiple projects.
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 multiple project names are edited simultaneously, the linked folder names are also updated correctly. Previously, the system didn't reflect these changes, leading to inconsistencies. This fix corrects a bug in the multi-edit functionality, improving data accuracy.
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 resolves an issue where Star printers were incorrectly receiving commands. The fix ensures Star printers use the correct protocol and commands, improving their functionality and reliability. This resolves a technical problem that prevented proper communication with these printers.
Original PR description
Currently Star printers were correctly identified and thus were not using the right protocol and esc/pos commands were instead sent to the printers. `device_id` previously used is `""` for Star printers Star printers ignore such commands. This PR fixes the protocol used with Star printers
This update corrects an issue where Polish VAT invoice imports would fail if certain required fields (P_9A and P_11) were missing or had zero values. The fix allows invoices with these fields absent to be processed correctly, preventing interruptions to the invoice validation process. This ensures smoother import of Polish VAT invoices.
Original PR description
When importing bills, if `P_9A` and `P_11` are absent or zero, a `UserError` is raised: `No net or gross unit price found in the FA (3) for the line with the product.` **Steps to reproduce:** - Upload the problematic XML file as an attachment via `Settings -> Technical -> Attachments` - Create a `validator` server action with the code provided in the referenced ticket, with the `Add Contextual Action` flag set - Reload the page - Select the attachment in list view - Click the gear icon - Run the newly created server action KSeF FA(3) schema documentation: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf Ticket [link](https://www.odoo.com/odoo/project.task/6211065) opw-6211065 Forward-Port-Of: odoo/odoo#265228
This update corrects a problem where Google Calendar attendee information was being dropped incorrectly when an email address matched a configured alias. The fix ensures that all Google attendees are accurately synchronized, preventing missed invitations and improving event attendance tracking. This resolves a previous issue impacting event scheduling reliability.
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 a visual issue on mobile devices where an unnecessary 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 opened. 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#270167 Forward-Port-Of: odoo/odoo#266343
This update enhances the stability of the French PDP registration process by moving a key function to the company record. Previously, the registration process relied on a temporary model, which could be deleted. This change ensures a reliable record is always available, improving the overall system's robustness.
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#270380 Forward-Port-Of: odoo/odoo#270345
A confusing error message related to loyalty discounts has been fixed. The update clarifies the issue for users, ensuring they understand why a discount code wasn't applied. This improves the user experience and reduces support requests related to this specific functionality.
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 optimizes the MRP work order process by preventing unnecessary BoM calculations for quality points like instructions and pass/fail checks. Previously, these checks were slowing down the system, but now they're handled more efficiently, resulting in a significant performance boost. This change improves overall work order processing speed.
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 resolves an issue where creating payments using certain accounting sequences would trigger a technical error. The fix ensures that the system correctly handles date-only values when generating sequence numbers, preventing the traceback and ensuring payment creation functions smoothly. This improves stability and reliability for users creating payments.
Original PR description
## Issue When trying to call `dt.replace` on a `datetime.time`, a TypeError is raised ``` File "/home/odoo/Documents/src/odoo/190/odoo/addons/base/models/ir_sequence.py", line 270, in _next return…
## Issue
When trying to call `dt.replace` on a `datetime.time`, a TypeError is raised
```
File "/home/odoo/Documents/src/odoo/190/odoo/addons/base/models/ir_sequence.py", line 270, in _next
return seq_date.with_context(ir_sequence_date_range=seq_date.date_from, ir_sequence_date=dt.replace(tzinfo=None))._next()
^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'tzinfo' is an invalid keyword argument for replace()
```
## Steps to reproduce
1. Install *Accounting* (`accountant`)
2. Update the `account.payment` sequence:
- Toggle *Use subsequences per date_range* and create a range
3. In Accounting > Customers > Payments, create a payment:
- Payment Type: Receive
- Customer: Any
- Amount: Any
4. **A traceback appears**
## Cause
This error was introduced by https://github.com/odoo/odoo/commit/4b9dd7893f96.
The `AccountPayment._compute_name` method calls `_next_by_code` and passes a date as the `sequence_date`.
https://github.com/odoo/odoo/blob/337efb069f6cf2cb9478a970f075fd139c1e8e0a/addons/account/models/account_payment.py#L420-L422
In the `_next` method, the `dt` variable is set to that date (`datetime.date`), and calling the `.replace` method on that variable raises an error, as there's no tzinfo for `datetime.date`s.
opw-6303885
Forward-Port-Of: odoo/odoo#270283This update resolves an issue where UBL import failed due to a mismatch between the imported unit of measure and the product's category. The fix allows imports to proceed without error, and users can then manually adjust the UoM after the import is complete. This improves import reliability.
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 removes a redundant, read-only column ('Extra Hours (encoded)') from the HR Attendance view. Previously, this column was introduced as a temporary fix, but it's no longer needed. This change simplifies the user interface and improves clarity.
Original PR description
The 'Extra Hours (encoded)' column was previously made read-only in a stable fix, making its presence obsolete for users in this view. This commit removes the `manual_duration` field column entirely from the view to clear interface clutter. Task: 6253553 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268873 Forward-Port-Of: odoo/odoo#266921