Daily updates from Odoo
Tuesday, June 16, 2026
143 changes
13 changes
Enhancements to existing features
This update adds a time limit to the Odoo profiler, preventing excessively long query analysis. The system now automatically tracks and commits profiling data at regular intervals, improving performance and reducing the impact on user experience. This ensures the profiler remains responsive and efficient.
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
Resolved issues and error corrections
This update fixes an issue where multiple taxes on Brazilian sales orders were displayed on a single line, making them difficult to read. The change adds a line break to display each tax detail on its own line, improving clarity and usability for users.
Original PR description
Upon creating a SO in the Brazilian localization and computing taxes, tax details are displayed on the SO lines. However, when multiple taxes are applied, all tax details are shown on a single line, making them difficult to read. Add a line break between tax details so that each tax is displayed on a separate line. Before: https://www.awesomescreenshot.com/image/61178015?key=703ceba935bbf0b97f4b45c649722827 After: https://www.awesomescreenshot.com/image/61178078?key=3b980b91b7657aa48dec9b825549ebeb opw-6234768 Forward-Port-Of: odoo/enterprise#120527
This update corrects a bug that caused errors when date calculations used a missing or `None` offset value. The fix ensures that date movements are avoided when an offset isn't explicitly provided, preventing unexpected behavior in AI-powered features. This improves the reliability of date-based computations.
Original PR description
Currently, an exception is raised when `offset` is `None` and is compared
with `MIN_OFFSET` or `MAX_OFFSET`.
Currently `offset = op.get("offset", 1)` to assign a default value of `1` when
the `offset` key was missing from `op`. However, this does not handle cases
where the `offset` key is present but its value is `None`.
This commit fixes the issue by defaulting `offset` to `0` when it is missing or
`None` in `op`. Using the default value ensures no date movement occurs
when `offset` is not explicitly provided.
Sentry-7448086997
Forward-Port-Of: odoo/enterprise#118466This update corrects a bug where inactive or archived taxes were incorrectly displayed within the bank reconciliation process. The fix ensures that users can only select active taxes, improving data accuracy and preventing potential errors during reconciliation 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 improves the accuracy of the reconciliation process by ensuring the matching dialog displays both draft and posted journal items. Previously, the dialog was limited, showing fewer items due to a default filter. 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 adjusts the format of unit prices in Polish tax invoices (FA3) to ensure accurate calculations and alignment with tax regulations. While the current system technically complies with KSEF requirements, this change improves invoice accuracy by using the maximum allowed decimal places. This resolves a potential discrepancy between unit price and total without tax.
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 an issue where the VoIP softphone would throw errors when receiving calls from numbers not linked to a contact. The fix ensures that a task can be created from a contactless call and prevents the 'Tasks' button from appearing when no contact is associated with the call, improving usability.
Original PR description
**Problem:** Two linked errors occur in the Phone (VoIP) softphone when a call is made to or received from a number that is not linked to any contact. **Steps to reproduce:** 1. Receive or make a…
**Problem:** Two linked errors occur in the Phone (VoIP) softphone when a call is made to or received from a number that is not linked to any contact. **Steps to reproduce:** 1. Receive or make a call from the softphone using a phone number that is not linked to any existing contact. 2. Open the call's actions and click "Create" > "Task". -> A client error appears and the task is not created. 3. On a voip.call form whose Contact has been removed, click the "Tasks" smart button. -> A server error is raised. **Current behavior:** Step 2 raises "Cannot read properties of undefined (reading 'id')" and step 3 raises "ValueError: not enough values to unpack (expected 1, got 0)". **Expected behavior:** Creating a task from a contactless call should open the task form without a default contact, and the Tasks smart button should not be reachable when the call has no contact. **Cause of the issue:** Both code paths assume a call always has a linked partner. In `action_list_patch.js`, `getCreateTaskAction` only checks `shouldShowTaskButton` in its predicate but reads `this.contact.id` in its `onClick`; for a contactless call `this.contact` is undefined. In `voip_call.py`, `action_view_tasks` delegates to `self.partner_id.action_view_tasks()`, whose `ensure_one()` fails on the empty partner recordset. Unlike the softphone "view tasks" action, which is gated by `this.contact?.task_count`, the form stat button had no visibility guard. **Fix:** The create-task action now mirrors the existing contact and lead actions, which already build their context conditionally on `this.contact`, so a contactless call simply opens the task form with no default partner. The Tasks stat button is hidden when there are no tasks, matching the softphone predicate and ensuring the partner-less code path is never reached. opw-6246641 Forward-Port-Of: odoo/enterprise#119412
This update fixes a technical issue that could cause errors when comparing history differences in the web editor. The fix ensures the system handles empty history data gracefully, preventing a potential error and improving stability. This change ensures the web editor functions reliably for all users.
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 pull request resolves a visual issue where the cursor appeared incorrectly within dropdown input fields in account reports. The change aligns the cursor to the right, improving the user experience and ensuring consistent input behavior within these reports.
Original PR description
Dropdown inputs inside of an account report show the cursor in the center of the input field. The cursor has been changed to be right-aligned. task-6247454
This update resolves a bug that occurred when sorting financial reports by account code, specifically when a value of 'None' was present. The fix ensures the system handles missing account codes gracefully, preventing crashes and improving the reliability of financial data reporting. This ensures accurate reporting for all users.
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 corrects a validation error that occurred when importing Polish VAT (KSeF) invoices. The fix allows invoices without the required `P_9A` and `P_11` fields to be processed correctly, preventing interruption of the invoice workflow. This ensures smoother and more reliable 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 fixes a problem where Google Calendar attendee information wasn't always syncing correctly when some invitations matched existing email aliases. The change ensures that all Google attendees are properly synchronized, preventing missed invitations and improving the reliability of calendar events. This resolves an internal issue (opw-6086240) that impacted event scheduling.
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 prevents deleting a batch payment once its linked payments have been marked as 'sent' and an XML export file has been generated. Because we cannot modify the 'sent' status for SEPA payments, this change ensures data integrity and allows continued generation of necessary export files. This avoids potential issues with generating updated payment reports.
Original PR description
When you create a batch payment, linked payments are marked as sent, and an export file is generated (XML). But if you delete the batch payment, the payments will remain marked as sent, meaning you won't be able to re-generate a new XML file for those payments. As we don't want to unmarked them as sent (we can't for SEPA payments), we decided to disallow the batch payment deletion in those cases. task-6117210
16 changes
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
Resolved 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#119522This 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
18 changes
Enhancements to existing features
This update automatically populates the company registry information in Odoo for Swedish businesses using their VAT number. Swedish VAT numbers always start with 'SE' followed by digits, and this change leverages this pattern to streamline data entry. This improves accuracy and reduces manual effort for users operating in the Swedish market.
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
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
7 changes
Resolved issues and error corrections
This update resolves an issue where Odoo incorrectly identified ZIP files due to a bug in the underlying library. By adapting Odoo's detection process, we ensure accurate MIME type identification for ZIP files and related formats, preventing potential errors in file handling. This maintains consistent functionality for users.
Original PR description
Libmagic version 0.46 (currently available in Debian Trixie/Forky and Ubuntu Resolute) introduced a regression regarding ZIP file detection. While it correctly identifies a ZIP file when reading…
Libmagic version 0.46 (currently available in Debian Trixie/Forky and Ubuntu Resolute) introduced a regression regarding ZIP file detection. While it correctly identifies a ZIP file when reading directly from a file path, it fails when reading the exact same content from a buffer, returning a generic 'application/octet-stream' instead. Because `guess_mimetype` primarily evaluates buffers, this upstream bug breaks MIME type detection for ZIP files (and related formats like docx, xlsx, etc.) in Odoo environments running this libmagic version. Since we cannot directly fix the library itself, this commit adapts Odoo's `guess_mimetype` to fallback to our custom implementation when libmagic returns the generic 'application/octet-stream' to workaround this library's bug. Upstream libmagic fixes: - https://github.com/file/file/commit/f1adef05b8a85be50d28965b1fd21fcceacf7a4e - https://github.com/file/file/commit/60b2032b96fc185b37fb0f2152e834efb2edad6e Upstream python-magic issue: - https://github.com/ahupp/python-magic/issues/354 runbot-938197 Forward-Port-Of: odoo/odoo#269506
This update resolves a technical issue where the Urbanpiper order information screen incorrectly displayed customer details even after the customer was removed. The fix ensures that customer information is only shown when a valid customer is associated with the order, improving the user experience and preventing error messages.
Original PR description
Steps to reproduce: ==== - Place an order through Urbanpiper. - Edit the order and remove the customer. - Open the ticket screen and click the info button. - A traceback occurs. Cause: ==== - Customer details were rendered even when no customer was linked to the order. Fix: ==== - Display customer details only when a customer is present on the order. task-6233812 Forward-Port-Of: odoo/enterprise#120290 Forward-Port-Of: odoo/enterprise#118147
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 accuracy and consistency. It addresses a minor discrepancy in the unit price and total without tax calculation.
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 fixes a visual issue in Outlook Desktop where email layouts, specifically the `s_three_columns` design and button styling, were not rendering correctly. The changes ensure consistent appearance and functionality of emails when viewed in Outlook Desktop, improving the overall user experience.
Original PR description
Problem: - `s_three_columns` is not rendered correctly in Outlook Desktop when the equal-height option is enabled. - Button padding, border radius, and background color are not rendered properly in…
Problem: - `s_three_columns` is not rendered correctly in Outlook Desktop when the equal-height option is enabled. - Button padding, border radius, and background color are not rendered properly in Outlook Desktop. Solution: - Set the `height` attribute on `td.card-body` along with `valign` so columns keep the same height in Outlook Desktop. - Use `v:roundrect` to support rounded corners (`arcsize`) and background colors (`fillcolor`), making buttons render consistently with the editor in Outlook Desktop. Before: <img width="1249" height="1297" alt="image" src="https://github.com/user-attachments/assets/828bc42b-1e21-404c-a5ae-81d4ee688802" /> After: <img width="1249" height="1309" alt="image" src="https://github.com/user-attachments/assets/263a1c30-fe86-4e40-b3c2-476abc2bf84a" /> Steps to reproduce: - Add the `s_three_columns` snippet with one card containing more content than the others. - Add some buttons. - Send or preview the email in Outlook Desktop. - Observe that column heights and button styling are not rendered correctly. opw-6044725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269791 Forward-Port-Of: odoo/odoo#269274
This update addresses a technical issue that could cause errors when comparing history data. The fix prevents a ValueError from occurring if the history data is unexpectedly empty, ensuring smoother operation of the web editor feature. This improves the stability and reliability of the Odoo platform.
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 resolves an issue where the 'Fill' option on the /shop page didn't correctly adjust product image sizes. The fix ensures that product thumbnails now accurately reflect the selected 'cover' or 'contain' fill mode, improving the visual presentation of products.
Original PR description
**Problem:** On the /shop page, the "Fill" option in the web editor (cover/contain toggle on product card images) appears clickable but has no visible effect on the product thumbnails. **Steps to…
**Problem:**
On the /shop page, the "Fill" option in the web editor (cover/contain toggle on product card images) appears clickable but has no visible effect on the product thumbnails.
**Steps to reproduce:**
1. Install website_sale and open /shop.
2. Open the web editor and select the shop page.
3. Locate the "Fill" button group in the right panel (with the two svg icons).
4. Click the alternate option to switch between cover and contain.
5. Observe that the product card thumbnails do not change appearance.
**Current behavior:**
The toggle flips the `o_wsale_context_thumb_cover` class on the products table (and the activation of the `products_thumb_cover` view), but the product images keep rendering with `object-fit: contain` regardless of the toggle state.
**Expected behavior:**
The image fill mode follows the toggle:
- "cover" option active → product image uses `object-fit: cover`
- "cover" option inactive → product image uses `object-fit: contain`
**Cause of the issue:**
The product image template renders the img with the `object-fit-contain` utility class, and the local SCSS rule declares
`.object-fit-contain { object-fit: contain !important; }`. The CSS variable `--o-wsale-card-thumb-fill-mode` (set to `cover` by `.o_wsale_context_thumb_cover`) does cascade down to the img, but the non-variable, `!important` rule on the utility class always wins, so the variable-driven rule
`object-fit: var(--o-wsale-card-thumb-fill-mode, contain)` is silently overridden and the toggle becomes inert.
**Fix:**
Making the `.object-fit-contain` rule read the same CSS variable lets the existing toggle mechanism take effect without changing any template or removing the utility class. Outside the `.o_wsale_context_thumb_cover` context the variable is undefined, so the `var(..., contain)` fallback preserves the prior `contain` behavior for any other consumer of the class. This keeps the change to a single SCSS line, with no XML touched and no other CSS class semantics altered.
opw-6231432
Forward-Port-Of: odoo/odoo#268302
Forward-Port-Of: odoo/odoo#266717This update corrects a validation error that occurred when importing Polish VAT (KSeF) invoices. Previously, the system required specific fields (`P_9A` and `P_11`) to be present, even if they contained zero values. This change relaxes this requirement, allowing invoices without these fields to be processed correctly, ensuring smoother VAT compliance.
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
33 changes
New functionality added to Odoo
This update adds sample data and an interactive onboarding tour specifically for appointment types like account payments, HR recruitment, and restaurant bookings. This allows new users to quickly understand and experience the appointment functionality within Odoo Enterprise, improving the initial user experience.
Original PR description
*=appointment_account_payment,appointment_hr_recruitment,pos_restaurant_appointment This PR adds demo events for selected appointment types and introduces an onboarding tour. Task-6233604
Enhancements to existing features
This update adds dropzones to controller pages within the Enterprise module, improving the user experience for tasks like appointments and helpdesk requests. Standardizing dropzone messages ensures a more consistent and intuitive workflow for users interacting with these features.
Original PR description
*: appointment, website_appointment, website_helpdesk This commit introduces the missing dropzones for controller pages and standardizes the dropzone messages. task-4430461 Community: https://github.com/odoo/odoo/pull/233738
This update adjusts the number of badges displayed on shift templates to a maximum of 4. Previously, the limit was lower, which could restrict the visibility of important scheduling information. This change improves usability and ensures all relevant details are easily accessible for shift planners.
Original PR description
This commit changes the maximum visible badges limit to 4 for shift templates. task-3705263
This update improves the report editor by displaying a clear warning in the sidebar if a report block is shared with another user. This helps ensure collaborators understand who is editing a report and prevents potential conflicts. It's a simple but important enhancement for team collaboration.
Original PR description
In the report editor, the sidebar show if the currently editing block is shared. If so, the name and a warning is shown in the sidebar. TASK-6144417
This update introduces a new boolean field in fleet vehicles to manage CO2 emission calculations. When selected, it intelligently copies CO2 values from similar vehicle models (diesel or gasoline) if available, or multiplies the default value by 2.5. This ensures more accurate tracking of vehicle emissions.
Original PR description
[IMP] l10n_be_hr_payroll: false hybrid:
1 - false hybrid boolean field is added to the fleet_vehicle_model
1.1 - I added it to fleet_vehicle as a related field
1.2 - It is displayed in fleet_vehicle_model view conditionally
2 - When Plug-in diesel is selected and false_hybrid is ticked as true
2.1 - Look to other diesel model with same name and if there are any, take its default_co2 and use it in this model
2.2 - If not, multiply the current default_co2 by 2.5
3 - When one of the Plug-in gasoline/full-hybrid is selected and false_hybrid is ticked as true
3.1 - Look to other gasoline model with the same name and if there are any, take its default_co2 and use it in this model
3.2 - If not, multiply the current default_co2 by 2.5
task - 6146410This update simplifies the naming of new fields created within Odoo's Studio interface. Previously, fields received random, complex names, making them difficult to manage. Now, fields are named with a consistent 'x_studio_[field_type]_[n]' format, ensuring clarity and ease of identification.
Original PR description
Currently, a new field created with Studio will have a randomly generated name (ie: `x_studio_integer_field_p1a_c0s291499`). This commit simplifies the generation as follows: `x_studio_[field_type]_[n]` with `n` being an increment to avoid duplicates. (ie: `x_studio_integer_1`). task-6241678
This update adds a confirmation popup when users reset manually modified salary rules. This ensures users understand the potential impact on database salary rules, preventing unintended consequences and improving data accuracy. It's a small change designed to enhance data integrity.
Original PR description
A new confirmation popup will be displayed to the user in case they reset a manually modified salary rule in order to inform them of the effects of that reset on the salary rules in the DB. Task: 6222776
Resolved issues and error corrections
This update resolves an issue preventing printing receipts from the Odoo Mobile App. The fix allows the app to correctly print receipts, mirroring the functionality available on the desktop and web versions. This improves the mobile user experience for order review and fulfillment.
Original PR description
**Steps to reproduce:** - Go on the Odoo App, start the PoS - Go to orders, and go to paid ones - Click on review - Click on Print Receipt - It doesn't do anything but it prints correctly on browser or desktop **Why the fix:** This is a partial backport of 41e4549 that fixes the app to allow the way we created IFRAMES in PoS since 19.2, allowing us to print on the app again. Community PR: https://github.com/odoo/odoo/pull/265024 opw-6186261 Forward-Port-Of: odoo/enterprise#120043
This update corrects a misleading error message that prevented new online account connections for Canadian bank accounts (which don't use IBANs). The fix skips the journal duplication check when an account number is missing, ensuring a fresh journal is created and preventing unnecessary errors. This improves the user experience for a common scenario.
Original PR description
…unt number When a provider returns an account without `account_number` (typical for Canadian banks, which do not use IBANs), the existing-journal search ran with `bank_account_number = False`.…
…unt number When a provider returns an account without `account_number` (typical for Canadian banks, which do not use IBANs), the existing-journal search ran with `bank_account_number = False`. Because `bank_account_number` is a related field on `bank_account_id.account_number`, that search matched every bank journal in the user's allowed companies whose `bank_account_id` was unset. If any of those journals was tied to a connected online link, the new sync was blocked with the misleading error "There's already a synchronized journal linked to this IBAN", even though no IBAN was involved. Skip the search entirely when `account_number` is falsy: without an identifier there is nothing meaningful to dedup against, and the downstream code already handles `existing_journals` being empty by creating a fresh journal. Note: when the provider omits `account_number`, a delete-and-recreate of the connection will now create a fresh journal rather than coincidentally reusing an unlinked empty-`bank_account_number` journal. That reuse path already failed (with a spurious "IBAN already connected" error) as soon as the user had more than one such journal, so the prior behavior was not reliable. The supported recovery path remains the reconnect button on the existing journal, which uses the `active_id` branch and is unchanged. opw-6253563 Forward-Port-Of: odoo/enterprise#119848
This update resolves a visual issue in dark mode and improves the user experience of the Gantt holiday view. Specifically, the way users select holidays has been corrected to accurately reflect the number of selected days, enhancing usability and data accuracy.
Original PR description
- changed selected value in the view to be number of selected cells instead of number of selected records - fixed a visual bug in dark mode where the create popup has ugly background task-id: 6124765 Forward-Port-Of: odoo/enterprise#119253 Forward-Port-Of: odoo/enterprise#116229
This update resolves an issue where the Balance Sheet report incorrectly displayed zero amounts when using the 'Ledger' grouping option. The fix ensures the 'Ledger' group is only applied when appropriate (multicompany or different journal groups are present), preventing incorrect calculations.
Original PR description
[FIX] account_reports: only restore horizontal group from previous_options when it's available The 'Ledger' group will only be available when in multicompany or using different journal groups. It was…
[FIX] account_reports: only restore horizontal group from previous_options when it's available
The 'Ledger' group will only be available when in multicompany or using different journal groups. It was still restored from previous options, even when it shouldn't have been available.
=============================================
[FIX] account_reports: properly compute Ledger group when there's no journal group
To reproduce the issue
1) Populate the db with some data impacting the Balance Sheet
2) Delete all the journal groups that would be created by default
3) Open the Balance Sheet, with multiple companies active.
4) Select the "Ledger" horizontal group
====> The report is displayed horizontally grouped by company, but all amounts are 0.
This happens because, when no journal group exists, the "Ledger" horizontal group creates a column group per company, applying a domain doing ('journal_id', 'in', []), so nothing matches. This is caused by the fact that, in this case, options['journals'] will require to match all journals, and will hence be an empty list. We fix it by properly searching for all journals to build the horizontal group's domain when options['journals'] is empty.
Forward-Port-Of: odoo/enterprise#119418This update corrects a potential issue in the Swiss payroll module where users could incorrectly request refunds on payslips. Swiss regulations limit employees to one payslip per month, so the system now guides users to cancel and re-create the payslip for any necessary corrections. This ensures compliance with Swiss payroll rules.
Original PR description
Prevent refunds for CH payslips since only one payslip per month is allowed for Swiss payroll. Users should cancel the payslip and create a new one to apply corrections. task-5951981 Forward-Port-Of: odoo/enterprise#107943
This update ensures that when users open links in new tabs or windows, the current debug mode settings are automatically carried over to the new page. Previously, this functionality was broken, causing debug information to be lost. This improvement maintains a consistent user experience and simplifies debugging workflows.
Original PR description
Before this commit, opening a link in a new tab or window via middle-click or Ctrl+click would lose the active debug state, as the query parameter was not forwarded to the new page context. This commit ensures that the debug status is copied from the current window and appended to the target URL when a user opens a link in a new window. task-6285277
This update adds a temporary mock model to the spreadsheet dashboard edition module, resolving an issue that prevented test cases from running correctly. This ensures the stability and reliability of the dashboard's testing process, allowing for continued development and quality assurance.
Original PR description
This commit introduces a mock `SpreadsheetDashboardFavoriteFilter` model in the `spreadsheet_dashboard_edition` module. It ensures that test cases relying on favorite filters can run correctly. Task: [5114625](https://www.odoo.com/odoo/2328/tasks/5114625)
This update fixes a visual issue where the 'suggestion' icons weren't appearing in the Assistant when it detected tasks. The change ensures the Assistant correctly identifies activity types, allowing the icons to display accurately and provide better guidance to users. This improves the Assistant's usability and effectiveness.
Original PR description
- When the Assistant detected activities such as 'Working on task', the suggestion icon was not displayed because the event type was not assigned. Unlike `aw.rule` matches, the Odoo URL resolver only set the label and related record information, but did not set the activity type required by `getIcon()`. - Expose the activity type through `get_assistant_data` and assign the activity type when resolving model URLs in extractWatcherActivity. task-6259793 Forward-Port-Of: odoo/enterprise#120370
This update resolves a bug where the employee field in appraisals wouldn't automatically populate when using the appraisal smart button from the employee record. The fix ensures the correct employee ID is passed through the system, regardless of the user's navigation path, improving the appraisal process flow.
Original PR description
[FIX] hr_appraisal: fix auto-fill of employee in appraisal Bug production: 1 - employee app -> department -> select employees -> select any employee -> use appraisal smart button in top ->…
[FIX] hr_appraisal: fix auto-fill of employee in appraisal
Bug production:
1 - employee app -> department -> select employees -> select any employee -> use appraisal smart button in top -> employee_id is not coming
Bug cause:
1 - When we press smart button of appraisal action_send_appraisal_request in hr_employee is called.
2 - It send the self.env.context as a context and active_model and active_id.
3 - In hr_appraisal, _get_default_employee function calculates the default employee_id by looking to context and especially by looking to active model and id.
3.1 - If active_model is hr.employee and there is active_id, it finds the employee automatically (that is the case when we are coming directly from employee -> smart button hr_appraisal)
3.2 - When we first click to department and then we click to employee and smart button, active_model is hr.department and default_employee_id cannot be calculated in default version.
Bug solution:
1 - I have passed the default_employee_id to the context in action_send_appraisal_request function. Since we know the employee in the action_send_appraisal_request function we can pass it directly.
task - 6285434
Forward-Port-Of: odoo/enterprise#119737This update fixes a bug where the 'Due' button wasn't appearing on customer forms when a balance existed, specifically for customers linked only at the journal entry line level. The fix ensures the button is always visible, regardless of how the customer is linked to accounting records, improving user experience and financial reporting accuracy.
Original PR description
Steps to Reproduce: 1. Install Accounting module (without Point of Sale). 2. Create a customer. 3. Create a journal entry with that customer set only at line level. 4. Post the journal entry. 5. Open…
Steps to Reproduce: 1. Install Accounting module (without Point of Sale). 2. Create a customer. 3. Create a journal entry with that customer set only at line level. 4. Post the journal entry. 5. Open the customer form. Issue: The Due smart button is not visible on the partner form even though an outstanding balance exists for the customer. Note: This issue does not reproduce when Point of Sale is installed, as the POS module overrides `_compute_has_moves` with its own implementation that checks the outstanding balance directly. Root Cause: The `_compute_has_moves` method queries only `account.move `for partner matching. When a partner is referenced only at the account.move.line level, the partner is never picked up by this query, resulting in `has_moves = False` and the Due button remaining hidden. Fix: Replaced the EXISTS-based implementation with a UNION-based approach as the EXISTS implementation evaluated the query per partner row, whereas UNION processes all partners in a single batch query. Additionally extended the UNION to also include account.move.line partner matching, ensuring partners referenced only at the line level, are correctly detected and has_moves is set to True. Result: The Due smart button is now correctly visible for all partners with an outstanding balance, regardless of whether the partner is set at the journal entry level or only at the line level. owp = 6243562 Forward-Port-Of: odoo/enterprise#120492 Forward-Port-Of: odoo/enterprise#119084
This update resolves an issue where account reports were displaying with incorrect styling due to a missing CSS class. The change ensures that all lines within the reports are rendered with the correct visual formatting, improving the overall presentation and readability of financial data. This ensures consistent and accurate reporting.
Original PR description
commit introducing the issue: https://github.com/odoo/enterprise/commit/6608d5c21a7fb9d57786c2a7618b878e244bd420 Forward-Port-Of: odoo/enterprise#120532
This update resolves an accessibility issue with tooltips on smartphones and tablets. By using the `data-tooltip` attribute instead of the native `title` attribute, the tooltip service now provides a consistent and reliable experience for all users, including those using keyboard or touch devices.
Original PR description
Treat the `title` attribute as `data-tooltip` in the tooltip service. On touch devices (like smartphones, tablets) the native `title` based tooltip is unreliable and inaccessible, so we now read `title` and expose it via `data-tooltip` to provide consistent behavior. - Many user agents do not expose the `title` attribute in an accessible way (for example they require a pointing device to show a tooltip), which excludes keyboard-only and touch-only users [1] - This change ensures the same appearance and behavior for tooltips triggered via `title` and via `data-tooltip` - We no longer have duplicate tooltips caused by nested `data-tooltip` and `title` attributes. task-6159644 [1]: https://html.spec.whatwg.org/multipage/dom.html#the-title-attribute
This update resolves an issue where the account audit status on reports wasn't updating correctly. By using a more efficient method to load the status data, the display now reflects the most current information, ensuring accurate reporting. This change addresses a technical dependency update related to Odoo's rendering engine.
Original PR description
Load the account audit status record via asyncComputed instead of a useLayoutEffect-triggered async method, so the record is returned as a reactive value rather than written as a side effect on useState state. WHY: useLayoutEffect deprecated with OWL3
This update resolves a technical issue where the Urbanpiper order information screen displayed customer details even when no customer was associated with the order, causing a traceback. The fix ensures customer details are only shown when a customer is correctly linked to the order, improving the user experience.
Original PR description
Steps to reproduce: ==== - Place an order through Urbanpiper. - Edit the order and remove the customer. - Open the ticket screen and click the info button. - A traceback occurs. Cause: ==== - Customer details were rendered even when no customer was linked to the order. Fix: ==== - Display customer details only when a customer is present on the order. task-6233812 Forward-Port-Of: odoo/enterprise#120521 Forward-Port-Of: odoo/enterprise#118147
This update fixes an issue where multiple taxes applied on Brazilian sales orders were displayed on a single line, making them difficult to read. The change adds a line break to separate tax details, improving clarity and usability for users. This ensures accurate tax reporting and a better user experience for Brazilian customers.
Original PR description
Upon creating a SO in the Brazilian localization and computing taxes, tax details are displayed on the SO lines. However, when multiple taxes are applied, all tax details are shown on a single line, making them difficult to read. Add a line break between tax details so that each tax is displayed on a separate line. Before: https://www.awesomescreenshot.com/image/61178015?key=703ceba935bbf0b97f4b45c649722827 After: https://www.awesomescreenshot.com/image/61178078?key=3b980b91b7657aa48dec9b825549ebeb opw-6234768 Forward-Port-Of: odoo/enterprise#120527
This update resolves an issue where inactive taxes were incorrectly displayed and selectable within the bank reconciliation process. The fix ensures that only active taxes are available for selection, improving data accuracy and preventing users from inadvertently using archived tax information. This enhances the reliability of financial reconciliation reports.
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 fixes an issue where the reconciliation dialog only displayed posted journal items, hiding draft items. Removing a default filter ensures the dialog shows all matching items, providing a more complete and accurate reconciliation view. This improves the user's ability to resolve discrepancies.
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 resolves a bug that was causing a warning related to minimum wage calculations for Belgian employees. The fix ensures the system correctly identifies the appropriate job category and wage scale, preventing inaccurate reporting. This ensures compliance and accurate payroll processing for our Belgian clients.
Original PR description
**Description:** Select Belgium company, employee, select student and make its contract as 1st of January. Error appears. For repetition look to the provided link. **Implemntation:** . Add a check for l10n_be_job_category_id, as it is required to determine the minimum wage scale. . Add corresponding tests task-6302901
This update fixes an issue where the Balance Sheet report export was incorrectly including all accounts instead of the selected one when changing date filters. The fix removes a filtering mechanism that was unintentionally introduced, ensuring the report accurately reflects the user's chosen account selection.
Original PR description
Steps: - Open Balance Sheet report and unfold lines - Open the General Ledger from a line with an account - On GL report, change date filter - Export XLSX report -> We export all accounts instead of the one selected in the search bar Cause: Since f8dceec74e44ffe4aef67655be8811c96da91eba we filter out the filter if a default account is defined in the context which is the case in the `caret_option_open_general_ledger` method Fix: Remove the filtering as the behavior that was fixed by the mentioned commit does not happen anymore. opw-6234427 Forward-Port-Of: odoo/enterprise#119588 Forward-Port-Of: odoo/enterprise#119156
This update resolves an issue where HR users without payroll access couldn't view employee type configurations. The change adds HR Manager permissions to the field, allowing all users to access this setting. This ensures consistent functionality across the system.
Original PR description
**Steps to Reproduce** 1. Create a database on v19.3. 2. Install `hr` and `hr_payroll`. 3. Create or log in as a user who only has access rights for the Employee app (`hr`) and no Payroll access. 4.…
**Steps to Reproduce**
1. Create a database on v19.3.
2. Install `hr` and `hr_payroll`.
3. Create or log in as a user who only has access rights for the Employee app (`hr`) and no Payroll access.
4. Go to **Employees → Configuration → Employee → Employee Types**. Opening the Employee Types menu raises the following error:
```python
You do not have enough rights to access the field "employee_type_id" on
Employee Contract (hr.version). Please contact your system administrator.
Operation: read
User: 2
Groups: allowed for groups 'Payroll / Assistant'
```
**Issue Description:**
The field `employee_type_id` is defined in both modules with different group restrictions:
* In `hr/models/hr_version.py`, the field is restricted to **HR Managers**. [field](https://github.com/odoo/odoo/blob/f7e87637d5c47047ebffda0f3c929c25022c3f27/addons/hr/models/hr_version.py#L184)
* In `hr_payroll/models/hr_version.py`, the field is extended with the **Payroll / Assistant** group.
[field](https://github.com/odoo/enterprise/blob/acd831acd0f59f7b8c15bccfb6da0c3969fc3f6d/hr_payroll/models/hr_version.py#L41) When both modules are installed, access to `hr.version.employee_type_id` requires Payroll permissions.
In v19.3, PR #241780 introduced the `employee_count` [computation](https://github.com/odoo/odoo/blob/f7e87637d5c47047ebffda0f3c929c25022c3f27/addons/hr/models/hr_employee_type.py#L25) on `hr.employee.type`. During this computation, `_read_group()` is executed on `hr.employee` using the domain.
[pr] : https://github.com/odoo/odoo/pull/241780/changes
HR-only users (without hr_payroll.group_hr_payroll_user) cannot read the field, causing below traceback.
**Solution**
added `group_hr_manager` group to the field `employee_type_id` so both groups can view employee_type.
**Traceback**
```python
File "/home/odoo/src/odoo/saas-19.3/addons/hr/models/hr_employee_type.py"
line 25, in _compute_employee_count
employee_count_by_employee_type = dict(self.env['hr.employee']._read_group(
...
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 2732, in
check_field_access
raise AccessError(error_msg)
odoo.exceptions.AccessError: You do not have enough rights to access the field
"employee_type_id" on Employee Contract (hr.version).
Operation: read
User: 8
Groups: allowed for groups 'Payroll / Assistant'
```
opw-6246367
upg- 4302826
tgb- 2751
Forward-Port-Of: odoo/enterprise#120233This update adjusts the certification checksum to align with recent changes to the core Odoo system. Specifically, a new scale driver was implemented to reduce exception handling, necessitating this checksum update for accurate certification verification. This ensures continued compliance and proper operation of the l10n_eu_iot_scale_cert module.
Original PR description
As we updated the scale driver to reduce the amount of exception caught, we need to update the certification checksum. see odoo/odoo#268796 Forward-Port-Of: odoo/enterprise#119683
This update ensures that all properties from records – previously missing from spreadsheet exports – are now included. This change aligns the export behavior across different views (kanban, list, spreadsheet) and resolves a previous limitation, ensuring complete data transfer for spreadsheet users. It’s a fix to improve data consistency.
Original PR description
* = [documents_spreadsheet] When exporting properties from records in the web kanban and list views, sub-properties created within a record were previously not supported. Support for exporting these sub-properties has now been added. However, in spreadsheet this should only be enabled from saas-19.2 onwards (where it is already available). To keep the behavior aligned with the usual flow on earlier versions, this filters out the sub-properties exported from the record in `spreadsheet_edition`. community: https://github.com/odoo/odoo/pull/264267 task-6123524 Forward-Port-Of: odoo/enterprise#119675 Forward-Port-Of: odoo/enterprise#118913
This update fixes an error that occurred when downloading the asset template, specifically when a user removed the account code from their Fixed Assets account. The change allows for optional account codes, ensuring the system correctly identifies the asset account name instead of throwing an error. This prevents disruption to the asset template download process.
Original PR description
Currently, an error occurs when downloading the asset template. **Steps to Reproduce:** - Install the `account_asset` module without demo data. - Go to `Accounting` > `Configuration` > `Accounting` >…
Currently, an error occurs when downloading the asset template. **Steps to Reproduce:** - Install the `account_asset` module without demo data. - Go to `Accounting` > `Configuration` > `Accounting` > `Chart of Accounts`. - Open the `Fixed Assets` account, set a `Depreciation` value, and remove the `account code`. - Go to `Accounting` > `Accounting` > `Assets & Liabilities` > `Assets`. - Click `With our template` on the screen. `TypeError: startswith first arg must be str or a tuple of str, not bool` After this [recent commit], account codes became optional and can be removed. As a result, when the code is removed from the Fixed Assets account and when donloading the asset template, the system checks whether the account name starts with the account code [1]. Since the account code is `False`, it raises an error. This commit ensures that the check is only performed when the account code exists; otherwise, the account name is used directly for the asset account. [recent commit]: https://github.com/odoo/odoo/commit/c3313b336b9f1305c363097745926f2bdf61e277 [1]- https://github.com/odoo/enterprise/blob/421fce171dc158faa3b13406b6cea5c1c907ee49/account_asset/controller/asset_template_controller.py#L46-L49 sentry-7487406857 Forward-Port-Of: odoo/enterprise#117580
Code cleanup and technical improvements
This pull request updates the employee field in the HR module to improve data consistency and clarity. The change ensures a more standardized approach to recording employee information, which will help with reporting and data analysis. This is a refactoring effort focused on internal HR processes.
This update simplifies the bank reconciliation process within Odoo Enterprise by restructuring the core function. The changes enhance readability and maintainability, making it easier for developers to understand and update the code. This ultimately contributes to a more stable and efficient accounting system.
Original PR description
Reworked the try_auto_reconcile function to make it more readable by creating helper functions and splitting the function into multiple smaller ones. task-6171727 Forward-Port-Of: odoo/enterprise#120500 Forward-Port-Of: odoo/enterprise#116958
This update modernizes the Live Chat component to align with Odoo's OWL3 framework. The change replaces outdated React hooks with newer Signal/useEffect equivalents, resolving a deprecation issue. A small adjustment using setTimeout ensures the chat interface refocuses correctly after AI responses.
Original PR description
Replaces proxy/useRef/useLayoutEffect with signal/useEffect (OWL3 APIs). setTimeout is used when refocusing after AI response because OWL3's useEffect fires synchronously on signal change, before the DOM patch that re-enables the textarea. WHY: useLayoutEffect is deprecated in OWL3
4 changes
Resolved issues and error corrections
This update optimizes the MRP work order process by preventing unnecessary BoM explosions for non-material quality points like instructions and pass/fail checks. Previously, this process was slow, but now it's significantly faster, reducing processing time by orders of magnitude. This improves overall system responsiveness and efficiency.
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
This update corrects a potential issue in the Swiss payroll module where users could incorrectly request refunds for payslips. Swiss regulations limit one payslip per month, so the system now directs users to cancel and re-create the payslip for any necessary corrections, ensuring compliance with Swiss tax laws.
Original PR description
Prevent refunds for CH payslips since only one payslip per month is allowed for Swiss payroll. Users should cancel the payslip and create a new one to apply corrections. task-5951981 Forward-Port-Of: odoo/enterprise#107943
This update corrects a bug that occurred when a subformula was removed from a report without resetting its value. This prevented errors during record processing, ensuring reports could be generated correctly. The change resets subformula values to 'False' to avoid future issues.
Original PR description
The subformula was [removed](https://github.com/odoo/enterprise/pull/117601) without resetting its value to False, leaving existing values in the database. This causes errors when processing records that still contain a subformula value. ```.py Invalid subformula in expression "balance" of line "Treasury shares": -sum ``` To prevent these errors, existing subformula values are reset to False opw-6297901
This update corrects a bug where selection fields in Odoo's web studio were incorrectly flagged as required, even when not explicitly marked so. The change ensures that required fields are only applied when explicitly set to 'true', preventing unexpected behavior and improving the usability of the studio for users creating and editing forms.
Original PR description
Before: any studio property using a SelectMenu (selection) component, without a `required: false` in the childProps, was implicitly required because the check used `required !== false`, which evaluates `undefined` as truthy. After: `required` is only applied when explicitly set to `true`. task-5226503
9 changes
Resolved issues and error corrections
This update resolves a problem where Odoo incorrectly identified ZIP files when reading data from a buffer, leading to incorrect MIME type detection. The fix adapts Odoo's system to use a custom implementation when libmagic returns a generic response, ensuring accurate file type identification for ZIP and related formats. This prevents potential errors in handling attachments.
Original PR description
Libmagic version 0.46 (currently available in Debian Trixie/Forky and Ubuntu Resolute) introduced a regression regarding ZIP file detection. While it correctly identifies a ZIP file when reading…
Libmagic version 0.46 (currently available in Debian Trixie/Forky and Ubuntu Resolute) introduced a regression regarding ZIP file detection. While it correctly identifies a ZIP file when reading directly from a file path, it fails when reading the exact same content from a buffer, returning a generic 'application/octet-stream' instead. Because `guess_mimetype` primarily evaluates buffers, this upstream bug breaks MIME type detection for ZIP files (and related formats like docx, xlsx, etc.) in Odoo environments running this libmagic version. Since we cannot directly fix the library itself, this commit adapts Odoo's `guess_mimetype` to fallback to our custom implementation when libmagic returns the generic 'application/octet-stream' to workaround this library's bug. Upstream libmagic fixes: - https://github.com/file/file/commit/f1adef05b8a85be50d28965b1fd21fcceacf7a4e - https://github.com/file/file/commit/60b2032b96fc185b37fb0f2152e834efb2edad6e Upstream python-magic issue: - https://github.com/ahupp/python-magic/issues/354 runbot-938197 Forward-Port-Of: odoo/odoo#269506
This update fixes a rendering issue in Outlook Desktop where the layout of emails with three-column designs (`s_three_columns`) and button styling were not displaying correctly. The changes ensure consistent visual appearance of emails in Outlook Desktop, improving the overall email experience for users.
Original PR description
Problem: - `s_three_columns` is not rendered correctly in Outlook Desktop when the equal-height option is enabled. - Button padding, border radius, and background color are not rendered properly in…
Problem: - `s_three_columns` is not rendered correctly in Outlook Desktop when the equal-height option is enabled. - Button padding, border radius, and background color are not rendered properly in Outlook Desktop. Solution: - Set the `height` attribute on `td.card-body` along with `valign` so columns keep the same height in Outlook Desktop. - Use `v:roundrect` to support rounded corners (`arcsize`) and background colors (`fillcolor`), making buttons render consistently with the editor in Outlook Desktop. Before: <img width="1249" height="1297" alt="image" src="https://github.com/user-attachments/assets/828bc42b-1e21-404c-a5ae-81d4ee688802" /> After: <img width="1249" height="1309" alt="image" src="https://github.com/user-attachments/assets/263a1c30-fe86-4e40-b3c2-476abc2bf84a" /> Steps to reproduce: - Add the `s_three_columns` snippet with one card containing more content than the others. - Add some buttons. - Send or preview the email in Outlook Desktop. - Observe that column heights and button styling are not rendered correctly. opw-6044725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269791 Forward-Port-Of: odoo/odoo#269274
This update resolves an issue where users without an employee assigned to their company branch would encounter an error when creating expenses from documents. The fix ensures the system correctly handles users without a direct employee link, preventing a misleading error message and improving the user experience for all company branches.
Original PR description
Fix a bug where a traceback is displayed when a user with no employee on the parent company tries to create an expense from a document. Steps to reproduce: - install expense and documents - create a branch to the main company - create a user with access to both companies and group 'Team Approver' - create an employee for this user in the branch company - select both companies and go in Documents - select a document and in the action menu, click 'Create an Expense' -> This tracebacks before commit, and an user error is displayed after task-6237021
This update fixes an issue where the 'translate' button disappeared in the report editor when creating new reports. The fix ensures the button remains visible, allowing users to easily translate report resources regardless of whether they're editing an existing or new record. This improves usability and simplifies the report creation process.
Original PR description
The web.TranslationButton template now only renders when canTranslate is true, so the field button can hide itself on a new record still edited inside an x2many. The report editor reuses that template with its own component, which did not define the getter, so its translate button was no longer rendered. The component always edits an existing ir.ui.view, so its canTranslate returns true. Steps to reproduce: 1. Activate a second language in Settings > Translations > Languages 2. Open any report in Studio and edit its sources via the XML editor => The translate button next to the resource selector is missing Ticket [link](https://www.odoo.com/odoo/project.task/6260427) opw-6260427
This update resolves a technical issue where the web_editor module could encounter an error if it attempted to compare an empty history. The code has been updated to gracefully handle this situation, ensuring the editor continues to function correctly. This prevents potential disruptions to users when reviewing changes.
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 the import of UBL invoices incorrectly processed line extensions set to zero. Specifically, it ensures accurate calculations for quantity and discounts during the UBL import process, preventing incorrect invoice data. This ensures data integrity when dealing with products sold in quantities of one.
Original PR description
**PROBLEM** When line extension value is 0, because `bool(0.0) == False` we skip some important computation for the import. **STEP TO REPRODUCE** 1. Create an invoice with a product, with quantity > 1, and a discount of 100%. 2. Send the invoice to peppol, to generate a ubl. 3. Import the ubl, notice it will create a line with quantity = 1, and discount > 100% which is incorrect. opw-6227836
This update prevents users from attempting to translate records within x2many relationships when those records haven't been fully saved. The translate button is now greyed out with a helpful tooltip, guiding users to first save the parent record before translating its child. This resolves a previous error and improves the user experience.
Original PR description
Backport of https://github.com/odoo/odoo/pull/265512 A new record edited inside an x2many has no id of its own, so the translate button is now greyed and inactive there, with a tooltip inviting to save the record and its parent first. Steps to reproduce: 1. Activate a second language in Settings > Translations > Languages 2. Open the Surveys app and create a survey 3. Add a question, then in the Answers tab add a line and type a value 4. Click the EN button next to the answer, fill the second language, and Save => RPC error operator does not exist: integer = boolean from WHERE id = false Ticket [link](https://www.odoo.com/odoo/project.task/6260427) opw-6260427
A recent issue causing crashes when accessing documents through activities has been resolved. This fix addresses a technical problem related to how the system handles data loading, preventing errors when setting company information. This ensures a more stable and reliable experience for users accessing documents.
Original PR description
### Description When navigating to Documents via an activity, the list view crashes with a TypeError on setting 'COMPANY'. ### Root Cause An asynchronous race condition occurs between parent and child `onWillStart` hooks. The child finishes an await before the parent's hook runs `expandDefaultValue()`. Thus, `this.state.expanded[sectionId]` is undefined when the child tries to write to its nested keys. ### Solution Await `sectionsPromise` first in the child hook. opw-6276003 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue in Odoo's Studio that caused errors when deleting the last column from a report table. The fix ensures the system handles the scenario of deleting the final column gracefully, preventing tracebacks and improving the user experience. This ensures Studio remains stable and reliable for report customization.
Original PR description
Problem: When deleting the last column in a table in studio we get a traceback. Cause: `firstCell` will be null if we delete the last cell in the table. Fix: Added a null check on `firstCell` before calling `setCursorEnd`, so the cursor is only repositioned when the table still has remaining cells. Steps to reproduce: - Edit a report with a table. - Remove all columns. - Traceback will occur when deleting the last one. opw-6263696