Daily updates from Odoo
Thursday, April 23, 2026
51 changes · saas-19.1
New functionality added to Odoo
This update adds the ability to export Slovak VAT reports in XML format, aligning with government regulations. This ensures accurate and compliant reporting for our Slovakian clients, simplifying their tax filing processes. It backports a feature previously introduced in the saas-19.1 release.
Original PR description
Backported the XML export for Slovak VAT report introduced in saas-19.1 (commit https://github.com/odoo/enterprise/commit/ab6ec9b8bc568e9c88de4556c685b721f001680c7) Related: https://github.com/odoo/odoo/pull/260337 task-6139318 Forward-Port-Of: odoo/enterprise#114448
This update adds the ability for users to easily attach documents from the Documents app to invoices and accounting statements through the Accounting Send & Print wizard. Previously, this functionality was limited to the standard mail composer used in other modules like Quotations. This enhancement streamlines the process of sending invoices and statements with supporting documentation.
Original PR description
The standard mail composer (e.g., used in Quotations) allows users to add files or paste links directly from the Documents app. However, this functionality was missing in the custom `account.move.send` wizard used for Invoicing and Accounting. This commit introduces the 'Add from Documents' feature to the Accounting Send & Print wizard. task- 5905930 Forward-Port-Of: odoo/enterprise#111422
Enhancements to existing features
This update adds a Slovak VAT tax report, aligning with official DPHv25 form requirements. It includes mappings for key tax scenarios like bad debts and reverse charges, ensuring accurate reporting for Slovak businesses. This improves compliance and reporting capabilities within Odoo.
Original PR description
Backported the Slovak tax report introduced in saas-19.1 (commit 32afab28dacf79e200eef27ee10c66101e275e07) along with its related fix (commit 6414da3c4eeef23ca86ce70c05b426878602bb4d). Additionally, included a small adaptation commit to ensure the report works properly in v19. Related: https://github.com/odoo/enterprise/pull/114448 task-6139318 Forward-Port-Of: odoo/odoo#260337
This update enhances the process for finding audit return types by allowing searches based on return names. It also updates the standard, French, and Belgian audit reports to use fiscal year periods instead of annual periods, streamlining reporting and aligning with current regulations.
Original PR description
This change enables the user to search for the return types using the name of the return. In addition, it switches the generic audit, french audit and belgian audit to use the fiscal year periodicity instead of the annual periodicity. task: 5948404 Forward-Port-Of: odoo/enterprise#112280
This update enhances the visibility of tax return export files for users. Instead of being attached to the record, the generated XML and PDF files are now automatically posted as notes in the chatter thread upon tax return validation, making them easily accessible. This simplifies access to important tax documentation.
Original PR description
The xml and pdf of export of the tax return are not so visible for the user, thus the change creates the files on the validation of the returns and exports them to the chatter where they would be pinned task: 5871091 Forward-Port-Of: odoo/enterprise#111769
This update clarifies French accounting reports by splitting account 649 into two new accounts (6491 and 6492). This change accurately separates social security charges from salaries, aligning with French accounting standards (ANC PCG 2026). The original account remains but is marked as deprecated.
Original PR description
Splitting account 649 into two new accounts (6491 and 6492) is necessary to handle the Profit and Loss report properly. This ensures we can accurately separate social security charges from salaries in the report. Reference: ANC PCG 2026, page 445, note (h) https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf task-6053784 Forward-Port-Of: odoo/odoo#257398 Forward-Port-Of: odoo/odoo#255038
Resolved issues and error corrections
This update fixes an issue in several localized tax reports where an old report-crossing setting was left behind during an upgrade. As a result, affected reports can now open correctly again in newer Odoo versions.
Original PR description
- This aggregation expression used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses term from the same report), and the subformula was removed from the…
- This aggregation expression used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses term from the same report), and the subformula was removed from the data file without explicitly resetting it to False. This became a problem in 18.3, because the cross_report syntax changes. Because of that, a migrated report failed to open, since it still was using the old syntax on that expression. We fix that by explicitly emptying the subformula. see https://github.com/odoo/odoo/pull/193106 ```python3 Opération invalide Dans le rapport "Section I (LU)", à la ligne "472 - Autres Ventes / Recettes", avec le libellé "balance", Le format de l'expression de rapport croisé est invalide. Format attendu : cross_report(<report_id>|<xml_id>) Exemple : cross_report(my_module.my_report) ou cross_report(123) ``` opw-6103170 upg-4166654(lu) upg-4163103(it) upg-4175631(ug) upg-4177165(es) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258826
Calendar reminder notifications now properly go to the meeting organizer as well as other internal users. This fixes a case where the administrator could be missed, so reminders are more reliable and consistent for everyone inside the company.
Original PR description
Steps to reproduce: --------------------------------- 1. Install Calendar module with demo 2. For both Users: User > Preferences > Notifications > In Odoo 3. Log in through Admin > Calendar > New…
Steps to reproduce:
---------------------------------
1. Install Calendar module with demo
2. For both Users: User > Preferences > Notifications > In Odoo
3. Log in through Admin > Calendar > New meeting
4. Set a start time in the near future
5. Add Marc Demo as an attendee
6. Under Options > Reminders, add a reminder that triggers shortly before the meeting (e.g., 15 minutes)
7. Save the meeting
8. Log in as Marc Demo in another browser window
9. Wait until the reminder time is reached
Observation:
---------------------------------
The reminder notification is displayed for Marc Demo. The Administrator (Mitchell Admin) does not receive any notification.
Issue:
---------------------------------
In `_notify_next_alarm`, the domain
`('group_ids', 'in', self.env.ref('base.group_user').ids)`
was used to filter internal users. However, the admin user does not have
`base.group_user` directly in their `group_ids`, it is only present in `group_ids.all_implied_ids` (inherited through group hierarchy). This caused the admin user to be excluded from the user search, so no bus alarm notification was sent to them.
Solution:
---------------------------------
The `share` field on `res.users` correctly identifies internal users (`share=False`) vs portal/public users (`share=True`) by checking the full group hierarchy, including implied groups. This ensures the admin (and all internal users) receive alarm notifications while still excluding portal and public users.
https://github.com/odoo/odoo/blob/b261223c8e15c412a06a0d938d217bdf0ab9f9ff/odoo/addons/base/models/res_users.py#L459-L464
opw-6010337
Forward-Port-Of: odoo/odoo#255263We fixed an issue where opening a shared helpdesk ticket could crash if the original message author had been deleted. The ticket now opens normally, even when some author details are no longer available, improving reliability for shared links.
Original PR description
Currently, an error occurs when opening a shared helpdesk ticket link if the message author has been deleted. **Steps to Reproduce:(v19.2)** - Install Contacts and Helpdesk modules (with demo data). - Log in as "**Marc Demo**". - Create a helpdesk ticket and send a message via the chatter. - Log in as **Admin**. - Delete the demo user and the related partner from Contacts. - Go to Helpdesk > All Tickets and open the created ticket. - Click "**Share Ticket**" and open the generated link in another browser. Error: `ValueError - Expected singleton: res.partner()` **Cause:** When the partner linked to `message.author_id` is deleted, the recordset becomes empty, which raises a singleton error. Fix: This commit ensures that the author details are only included when the message author exists. sentry-7337698605 Forward-Port-Of: odoo/odoo#260332 Forward-Port-Of: odoo/odoo#254175
The refusal wizard now avoids automatically selecting email templates that have been archived. This prevents outdated templates from appearing pre-filled when users refuse an applicant, helping keep the workflow clearer and less error-prone.
Original PR description
Pre-requisites: --------------- 1. Create or duplicate any `hr.applicant` email template. 2. Archive the newly created template. 3. Archive the email template linked to a refuse reason. Steps to…
Pre-requisites: --------------- 1. Create or duplicate any `hr.applicant` email template. 2. Archive the newly created template. 3. Archive the email template linked to a refuse reason. Steps to reproduce: ------------------------- 1. Install hr_recruitment. 4. Go to Recruitment > Applications > All Applications and open an applicant. 5. Click on the "Refuse" button to open the refuse wizard. 6. Click on the "Email Template" and click on 'Search More' 7. Observe available templates Issue: ------- If a refuse reason is linked to an archived email template, the wizard automatically pre-fills that archived template Cause: ---------- The `_compute_template_id` method automatically assigns the template from the refuse reason without checking whether the template is active, which allows archived templates to be pre-filled in the wizard. https://github.com/odoo/odoo/blob/aa2a7c0e5a5de970cdb8f6a7ba9f02ad75cf5078/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L91-L96 Solution: ----------- - Update `_compute_template_id` to ensure only active templates are automatically assigned. opw-5974244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257580 Forward-Port-Of: odoo/odoo#251186
This change stops combo products from being selected on the mobile sales order line form. It prevents empty zero-priced lines from being created without their required child items, reducing errors and avoiding incomplete orders.
Original PR description
Combo products bypasses the configurator in mobile view, resulting in a 0-price line with no child lines. Exclude them via domain on the field. opw-5999935 Forward-Port-Of: odoo/odoo#260056 Forward-Port-Of: odoo/odoo#256790
Project chatter will no longer automatically post tracking messages when a linked Sales Order changes status. This reduces unnecessary activity in the record history and keeps the chatter focused on more relevant project updates.
Original PR description
Before this commit: - The chatter on the Project record tracked and logged changes to the linked Sales Order's status. After this commit: - Explicitly set `tracking=False` on the related `sale_order_state` field in `project.project`, `project.task` models. - Status updates to linked SOs will no longer automatically post tracking messages in chatter. task-6079809 Forward-Port-Of: odoo/odoo#258549
Helpdesk tickets will no longer automatically post chatter messages when the linked Sales Order changes status. This reduces noisy activity in ticket conversations and keeps the discussion focused on customer support updates.
Original PR description
Before this commit: - The chatter on Helpdesk Tickets tracked and logged changes to the linked Sales Order's status. After this commit: - Explicitly set `tracking=False` on the related `sale_order_state` field in `helpdesk.ticket`. - Status updates to linked SOs will no longer automatically post tracking messages in chatter. task-6079809 Forward-Port-Of: odoo/enterprise#114078
A display issue could turn normal percent signs into doubled percent signs in rendered website content. This fix ensures text is shown exactly as entered when no placeholders are involved, preventing awkward or incorrect page copy.
Original PR description
`_compile_format` unconditionally escaped `%` to `%%` to protect against Python's `%`-formatting, but only appended the `% (values,)` formatting operation when `#{...}` placeholders were present. With no placeholders, the escape was never undone and `%%` leaked into the rendered output.
This went unnoticed until the introduction of paramteric t-call: https://github.com/odoo/odoo/commit/eb6e88a25050
And since we use `.translate` and `.f` directly in existing views this became apparent
Example:
```xml
<t t-call="website.s_wd_testimonial"
_testimonial_quote.translate="...by 400%."/>
```
will be rendered as `...by 400%%.` on the page.
To prevent this, we can simply check for the absence of values and simply return the repr as is if there isn't any.
Forward-Port-Of: odoo/odoo#260434This update removes an incorrect tax tag from several French service taxes. It helps ensure tax reporting is applied only where intended, reducing the risk of mistaken calculations or declarations.
Original PR description
**Issue:** In French localization, a tax tag (i.e. "17") was wrongly added on several taxes for service by a fix: https://github.com/odoo/odoo/commit/f9237cfbb6a9ffbd0a392e4e77e097d5963a5fc3 This tax tag should only be applied on taxes for goods, not service. **Solution:** Remove the tax tag from the following taxes: - 20% EU S - 8.5% EU S - 10% EU S - 5.5% EU S - 2.1% EU S opw-5871998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260617
This update resolves an issue where the Odoo system couldn't correctly handle the Turkey timezone after a recent Ubuntu 24.04 update, which moved timezone data. The fix adds a fallback mechanism to ensure accurate timezone calculations, preventing errors during database upgrades. Additionally, the update addresses timezones in America/Catamarca and America/Godthab that were previously unsupported.
Original PR description
**[FIX] handle Turkey timezone when tzdata-legacy not installed** In #236660 we switched from pytz to zoneinfo. The library `pytz` has `Turkey` in **pytz.all_timezones_set**. On the other hand…
**[FIX] handle Turkey timezone when tzdata-legacy not installed**
In #236660 we switched from pytz to zoneinfo.
The library `pytz` has `Turkey` in **pytz.all_timezones_set**.
On the other hand starting from ubuntu 24.04 as tzdata was split and `Turkey` was [moved](https://documentation.ubuntu.com/release-notes/24.04/#tzdata-package-split) out of tzdata to tzdata-legacy.
If we run a db which has reference to `Turkey` timezone, on a server which is ubuntu 24.04 and tzdata-legacy not installed, we will get an error as we did not have fallback for `Turkey` while we have for `Türkiye`. Because zoneinfo will not have `Turkey` in `zoneinfo.available_timezones()`
Issue was discovered during upgrade of db which has res.partners with timezone=`Turkey` from 19.0 to saas~19.1. The upgrading docker container was nobel and it did not have tzdata-legacy.
For fixing the issue we added fallback for `Turkey`.
Tbh I do not think we need a fallback for `Türkiye` but I wanted to not change the old behaviour.
###
**[FIX] handle America/{Catamarca,Godthab} timezones**
As we moved from `pytz` to `zoneinfo` in **saas~19.1**
we have 2 more timezones which were existing in `pytz`
but not in `tzdata` adn we do not have fallback for them.
They are in `tzdata-legacy`:
- America/Catamarca
- America/Godthab
We added fallback for them.
We already have a failing upgrade request because of
America/Catamarca.
Turkey:
```
File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 742, in _compute_field_value
return super()._compute_field_value(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/addons/mail/models/mail_thread.py", line 495, in _compute_field_value
return super()._compute_field_value(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 4271, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 83, in determine
return needle(*args)
^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 503, in _compute_recurrence
event_values = event._get_recurrence_params()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 1341, in _get_recurrence_params
event_date = self._get_start_date()
^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 1573, in _get_start_date
return start.replace(tzinfo=UTC).astimezone(ZoneInfo(self.event_tz)).date()
^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/_monkeypatches/zoneinfo.py", line 130, in __new__
z = super().__new__(cls, key)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/zoneinfo/_common.py", line 24, in load_tzdata
raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key Turkey'
```
Catamarca:
```
Traceback (most recent call last):
File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 335, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 348, in mock_action
return self.mock_act_window(action)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 508, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 541, in mock_view_form
[data] = record.read(fields_list)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 2735, in read
self._origin.fetch(fields)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 3067, in fetch
fetched.mapped(field_name)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5479, in mapped
return [getter(record) for record in records]
^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1794, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1965, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 4271, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 83, in determine
return needle(*args)
^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/addons/base/models/res_users.py", line 455, in _compute_tz_offset
user.tz_offset = datetime.datetime.now(ZoneInfo(user.tz or 'UTC')).strftime('%z')
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/_monkeypatches/zoneinfo.py", line 130, in __new__
z = super().__new__(cls, key)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/zoneinfo/_common.py", line 24, in load_tzdata
raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key America/Catamarca'
```
tbg-2529
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-prThis update resolves an issue where timesheet forecasts incorrectly included planned hours on public holidays. The fix ensures the system accurately excludes holiday periods, regardless of whether they're linked to a specific calendar, and accounts for timezone differences to prevent date shifting.
Original PR description
### Steps to reproduce: - Install project_timesheet_forecast module - Configure your database to have a far timezone (Montevideo/Uruguay in my case) - Create a public holiday starts from 12AM to…
### Steps to reproduce: - Install project_timesheet_forecast module - Configure your database to have a far timezone (Montevideo/Uruguay in my case) - Create a public holiday starts from 12AM to 11:59PM with a calendar - Create a planning slot for a resource that overlap with the public holiday - Check the Timesheets / Planning analysis report - Group by employees > day **- Check the date of the public holiday and notice there are still planned hours shown** - Remove the calendar from the public holidays that we created previously - Check the report once again **- Notice the day of the public holiday and the day after has no planned hours** ### Cause: In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule. Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies ### Fix: We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves. opw-5027070 Forward-Port-Of: odoo/enterprise#111846
This update fixes an issue where a subscription could be automatically reopened after a salesperson manually closed it. Previously, approvals or payments triggered reopening, leading to potential inconsistencies. Now, subscriptions remain closed after manual closure, ensuring accurate subscription management.
Original PR description
Before this commit, when a subscription was closed manually by the salesperson, it could be reopened when a transaction was approved or an invoice paid. It could cause issue. In this case, we should not reopen automatically. task-5900481 Forward-Port-Of: odoo/enterprise#113026 Forward-Port-Of: odoo/enterprise#106487
This update removes an outdated requirement for country information on payment tokens used for subscription invoices. Previously, this restriction caused processing issues, but modern payment providers now support invoices without country details. This change improves invoice processing reliability and efficiency.
Original PR description
Before this commit, a country was mantadory on the payment token when it was used to pay invoices of subscriptions. This behavior was fetched back from internal code in 15.3. This issue was not visible until recently. Some token are fine without country, the provider allows it but the cron fails to process the sale order when the contract is processed. THis commit remove that old constraint. opw-5268156 task-5349998 Forward-Port-Of: odoo/enterprise#100166
This update prevents customers without a portal account from seeing the 'Pay Now' button in follow-up emails. This avoids confusion and ensures customers aren't directed to a portal they can't access, streamlining the invoicing process.
Original PR description
If a customer has no portal account, the pay now button added to follow-up emails won't allow them to access any invoices on the portal. Even if they register afterwards, a separate account will be created and they won't have access to those invoices. To avoid confusion, this commit hides the pay now button when the customer has no portal account. task-6075621 Forward-Port-Of: odoo/enterprise#112891
This update resolves a problem where confirming deliveries for kit products would trigger errors. The fix ensures that kit moves are correctly processed during delivery validation, preventing tracebacks and allowing deliveries to be confirmed smoothly. This ensures accurate stock accounting and avoids disruptions in the order fulfillment process.
Original PR description
**Issue**: Making a product a kit could prevent confirming deliveries. **Steps to reproduce**: - Make sure the account application is installed - Create a product P without kit - Create a SO and…
**Issue**: Making a product a kit could prevent confirming deliveries. **Steps to reproduce**: - Make sure the account application is installed - Create a product P without kit - Create a SO and confirm it - Make the product P a kit - Validate the delivery associated to the SO -> A traceback occurs: the record does not exist anymore **Cause**: While confirming the delivery: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L168 It first filters which moves are out (`moves_out`). On the move associated with product P, since the kit is not exploded yet: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L172 Then explodes the kit: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L174 https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mrp/models/stock_move.py#L357-L361 By doing so, the original move associated to the product P are deleted: https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mrp/models/stock_move.py#L399 Thus, `moves_out` contains moves that no longer exist, and eventually, and eventually while accessing `product_id`: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L179 A traceback is thrown **Aditionnal information** Validating a delivery of a kit product whose moves were not exploded will trigger their explosion and require a second validation. Therefore, no stock valuation errors will be created. opw-6063602 Forward-Port-Of: odoo/odoo#258403
This update resolves an issue preventing developers from creating new, empty Odoo repositories for testing and development. The change relaxes a validation check, allowing empty repositories to be created without errors, which improves the development workflow. This ensures developers can easily start new projects without encountering initial setup problems.
Original PR description
Initialize a new empty git repository where you are going to vide-code some new Odoo modules. Because the repository is empty (no addon yet) the CLI fails with an "option --addons-path: the path <path> is not a valid addons directory". This makes vide-coder sad, and bigrams want vide-coders to be happy, so drop the sanity-check and also accept empty addons. Forward-Port-Of: odoo/odoo#259007 Forward-Port-Of: odoo/odoo#256913
This update fixes an issue where scanning GS1 barcodes with leading zeros (like EAN-13 codes) wasn't working correctly. The fix ensures that products are accurately identified when scanning these barcodes, preventing errors during sales transactions. This improves the reliability of the Point of Sale system.
Original PR description
When scanning a GS1 barcode whose GTIN-14 has a leading zero (e.g. a product stored with EAN-13 "5400000002649" is encoded as GTIN-14 "05400000002649"), the product lookup in _getProductByBarcode failed because the exact string did not match the stored barcode. opw-6117948 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259199
This update resolves an issue where the Point of Sale app on iOS Safari would unexpectedly crash due to a lost connection to its local database. The fix prevents data loss and improves the overall stability of the app, particularly when the app is in the background. This ensures a smoother and more reliable experience for users.
Original PR description
On iOS/Safari, the WebKit IDB server process can be killed by the OS (e.g. due to memory pressure when the app is backgrounded), resulting in an UnknownError: "Connection to Indexed Database server lost". Additionally, returning from background can leave the connection in an InvalidStateError "closing" state while this.db remains non-null. opw-5121896 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259697 Forward-Port-Of: odoo/odoo#253943
This update fixes an issue where the system wasn't correctly applying pension fund tax (TC08) when the VAT rate was 0.00 during XML import. The fix ensures accurate tax assignment, improving compliance and preventing missing tax associations in imported vendor bills.
Original PR description
### Issue before this commit: When importing vendor bills from XML files containing a pension fund (e.g., type TC08), the pension fund tax was not correctly applied to the invoice lines. As a result,…
### Issue before this commit: When importing vendor bills from XML files containing a pension fund (e.g., type TC08), the pension fund tax was not correctly applied to the invoice lines. As a result, the imported bills were missing the expected tax association. ### Steps to reproduce the issue: 1. Download Accounting and l10n_it 2. Set the pension fund type as TC08 (or another one is also fine) in the Advanced Tab of 4% F.Pens. tax 3. Try to upload an XML for vendor bills with a TC08 tax 4. The tax is not associated ### Cause of the issue: The issue was caused by the handling of the VAT rate (AliquotaIVA) when its value was 0.00. The code incorrectly treated this value as falsy, preventing the correct identification and assignment of the pension fund tax during the import process. ### Reason to introduce the fix: The fix ensures that a VAT rate of 0.00 is correctly interpreted as a valid value rather than being ignored. This allows the system to properly detect and apply the pension fund tax during XML import, ensuring accurate tax assignment and compliance with expected accounting behavior. opw-6093352 Forward-Port-Of: odoo/odoo#258341
This update fixes an issue where the tip amount was incorrectly displayed in the Point of Sale (PoS) system when using a locale with a comma as the decimal separator. The fix ensures that the tip amount is correctly formatted based on the user's selected language and regional settings, improving the user experience and accuracy of payments.
Original PR description
Steps to reproduce 1. Set language decimal separator to "," and thousands separator to "." 2. Open PoS, create an order (e.g. total 17.85) 3. Pay more than the total (e.g. 22) 4. Open the Tip popup —…
Steps to reproduce
1. Set language decimal separator to "," and thousands separator to "."
2. Open PoS, create an order (e.g. total 17.85)
3. Pay more than the total (e.g. 22)
4. Open the Tip popup — it shows 415 instead of 4,15
5. Confirm — tip is set to 415
Issue
When overpaying, the change is passed as `startingValue` to the NumberPopup via
`String(amount)` (https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L232),
which always uses "." as decimal separator. This value is used directly as the
display buffer in NumberPopup
(https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/components/popups/number_popup/number_popup.js#L53),
so the user already sees "415" instead of "4,15" when the popup opens. When the
user confirms, `computeNewTip` parses this value with the locale-aware `parseFloat`
from `@web/views/fields/parsers`
(https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L279
and https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/web/static/src/views/fields/parsers.js#L73-L83),
which uses `localization.thousandsSep` and `localization.decimalPoint` to interpret
the string. With "," as decimal separator and "." as thousands separator,
`parseFloat("4.15")` treats the "." as a thousands separator, strips it, and
returns 415 instead of 4.15.
opw-5895622This update resolves an issue where the 'Configuration' menu was hidden for users with 'All Timesheets' access, preventing them from managing billing targets. The fix ensures that billing-related menus are correctly displayed or hidden based on user permissions and feature settings, improving usability for approvers.
Original PR description
Steps to reproduce Bug 1: 1. Login as a user with "All Timesheets" (Approver) access. 2. Disable the "Timesheet Assistant" feature for this user. 3. Ensure "Billing Rate Indicators" is enabled in…
Steps to reproduce Bug 1:
1. Login as a user with "All Timesheets" (Approver) access.
2. Disable the "Timesheet Assistant" feature for this user.
3. Ensure "Billing Rate Indicators" is enabled in settings.
Steps to reproduce Bug 2:
1. Login as a user with "All Timesheets" (Approver) access.
2. Disable the "Billing Rate Indicators" setting in company settings.
3. Ensure "Timesheet Assistant" is enabled in settings.
Steps to reproduce Bug 3:
1. Only install 'sale_timesheet_enterprise'.
2. Go to Timesheets > Configuration > Settings.
3. Toggle "Billing Rate Indicators" (timesheet_show_rates) or change the encoding unit (timesheet_encode_uom_id), then save and check the menus.
Issue:
1. The "Configuration" menu is hidden, preventing access to billing targets even if the user has "All Timesheets" access.
2. The "Billing Time Targets" menu is still visible inside Configuration even if the "Billing Rate Indicators" feature is disabled in the settings.
3. Menu visibility does not update immediately after saving the settings. Menus that should appear (e.g., "Employee Billing Time Targets" or "Timesheets Assistant") remain hidden, or vice versa, until the cache is cleared or the server is restarted.
Cause:
1. The `hr_timesheet_enterprise_menu_configuration` was restricted in XML to groups that excluded "All Timesheets" users.
2. The `_load_menus_blacklist` logic in Python only blacklisted billing menus for users who were both Managers and System Admins, leaving them visible to regular Approvers even when the feature was disabled.
3. The load_menus method is decorated with @ormcache and stored in the Registry LRU cache. Menu visibility depends on timesheet_show_rates and timesheet_encode_uom_id through _load_menus_blacklist. When this field is updated, the ORM does not automatically invalidate the cached load_menus result because these specific fields are not part of the configuration fields. As a result, the stale old menu remains in memory.
Fix:
- Updated XML to include `hr_timesheet.group_hr_timesheet_approver` in the Enterprise Configuration menu permissions.
- Refactored `_load_menus_blacklist` to:
- Hide all billing-related menus for all users when the feature is disabled.
- Hide the parent Configuration menu if it would otherwise be empty.
- Override the write method in res.company in both modules and explicitly call env.registry.clear_cache() when the relevant configuration fields are modified.
task-5428010This update corrects a bug where night shift templates created with specific start times would incorrectly extend shift durations by one day. The fix ensures accurate calculation of shift lengths when using templates, preventing overestimation of work time. This improves the reliability of shift planning.
Original PR description
Issue: ---------------------------------------- Creating a night shift from a template produces a shift spanning over one additional day. Steps to reproduce: ---------------------------------------- - Create a planning shift template form 23h to 1h the next day (2h) - It must have a span over 2 working days - Create a shift and use this template - The shift spans over one more day Cause: ---------------------------------------- In `_calculate_start_end_dates()`, we call `plan_days()` with `start` having the hours specified. So in `plan_days()` when retrieving the worked days, the first day is ignored because the resource is not supposed to be working from 23h to 1h (considering their calendar). Then we count two days, and so the end date is offset by one day. Solution: ---------------------------------------- We should call `plan_days()` without the hour specified so we make sure the first day is included in the count. opw-6134844
This update fixes an issue where the ‘Scan the QR code to pay’ message on kiosk online payment pages was consistently displayed in English, regardless of the user’s selected language. Now, the payment page will correctly display the QR code instructions in the language the user has set for their Odoo instance, improving the user experience for international kiosk payments.
Original PR description
Currently if you use an online payment with the kiosk, the payment page with the QR code is not translated. Steps to reproduce: ------------------- * Create an online payment method with demo * Install any language, you don't need to switch * Open kiosk configurations * Set the online pm in the available payment methods * Set the language istalled as the default language * Make an order, go to payment page > "Scan the QR code to pay" is written in english no matter the language opw-6074194 Forward-Port-Of: odoo/odoo#259895
This update resolves a problem where the website's interactive tour wouldn't consistently disappear after use. The fix ensures the tour's iframe is fully loaded before the edit mode is initiated, improving the user experience and preventing unexpected behavior.
Original PR description
This commit fixes a non-deterministic problem of the tour by ensuring the iframe is ready before opening an edit mode. runbot-240987 Forward-Port-Of: odoo/odoo#260309
This update resolves a critical issue causing crashes and slow performance when generating the VAT Books Excel report for large invoices. By optimizing memory usage and query execution, the report now runs efficiently even with extensive data, improving user experience and system stability.
Original PR description
Related Ticket: https://www.odoo.com/odoo/project/49/tasks/6037414 ### Description of the issue/feature this PR addresses: Generating the "VAT Books" Excel report causes severe performance…
Related Ticket: https://www.odoo.com/odoo/project/49/tasks/6037414 ### Description of the issue/feature this PR addresses: Generating the "VAT Books" Excel report causes severe performance bottlenecks and MemoryError crashes on databases with a massive volume of invoice lines. This PR introduces strict memory management and query optimizations to prevent server crashes and drastically speed up the XLSX export process. ### Current behavior before PR: When exporting the VAT Books report for a large dataset, the system attempts to hold the entire workbook structure in RAM. Additionally, the ORM unnecessarily prefetches fields when iterating over the account.move.line recordset and performs excess sub-queries to look up move_type for journal entries. This combination results in massive memory consumption, slow load times, and eventual server crashes. ### Desired behavior after PR is merged: The VAT Books report generates successfully and efficiently, even on massive databases, with a significantly reduced memory footprint. Specifically: - The ORM bypasses cache bloat by disabling field prefetching (prefetch_fields=False) during the recordset iteration. - The query execution is optimized by changing the search domain from move_type to move_id.move_type, leveraging the existing join table rather than triggering expensive sub-queries. ### Benchmark: The model is iterating through ~1.1M journal items when generating the full report. For Memory: | # Input Data | Before PR | After PR| | -------- | -------- | -------- | | ~7,800 journal items | 1.4GB| 202 MB | | ~32,000 journal items | MemoryError | 278 MB | | ~141,500 journal items | MemoryError | 760 MB | | ~1.1M journal items | MemoryError | 1.4 GB | For Speed: | # Input Data | Before PR | After PR| | -------- | -------- | -------- | | ~7,800 journal items | 2 min | 1.5s | | ~32,000 journal items | MemoryError | 4s | | ~141,500 journal items | MemoryError | 12s | | ~1.1M journal items | MemoryError | 56s | ### Reference opw-6037414 ----------------------------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#112230
This update streamlines the payment refresh button in the Odoo Enterprise system. Previously, the button was always visible, leading to unnecessary checks. Now, it only appears for payments that are actively being processed (pending or unsigned), optimizing system performance.
Original PR description
… batches The refresh button was always shown, which could cause unnecessary calls to OdooFin if the payment is finalised (accepted, rejected or canceled). With this change, the button is shown only for payments in progress (pending or unsigned). task-6103900 Forward-Port-Of: odoo/enterprise#113182
This update resolves an issue where close buttons on web views without names triggered unexpected behavior in the system. Now, the system accurately identifies when a close button is used, ensuring proper tracking and functionality. This improves the reliability of web view actions.
Original PR description
View buttons with no name cause onClosed to be called without any parameters even if special=true or dismiss=true. This commit fixes that which allows to know if a close/discard button caused the action onClosed callback. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260482 Forward-Port-Of: odoo/odoo#260301
This update resolves compatibility issues with Python 3.14 and the Ubuntu Resolute operating system. The changes include necessary opcode additions and improvements to data handling, ensuring continued stability and functionality of Odoo.
Original PR description
Forward-Port-Of: odoo/odoo#258568
This update fixes an issue where draft stock moves were incorrectly flagged as unavailable, even when sufficient stock existed. The change adjusts how availability is calculated to accurately reflect available quantities, ensuring accurate forecasting and preventing order fulfillment problems. This improves the reliability of stock management.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Update on-hand quantity to 2 units - Create a delivery with 2 units of P1 and keep it in draft state Problem: The forecast availability is…
Steps to reproduce: - Create a storable product "P1" - Update on-hand quantity to 2 units - Create a delivery with 2 units of P1 and keep it in draft state Problem: The forecast availability is displayed in red (not available), even though the stock is sufficient to fulfill the move. Explication: For draft consuming moves, the forecast availability is computed as: `virtual_available - move.product_qty` In the case where stock exactly matches the demand, this results in 0. However, on the JS side, availability is evaluated with: `forecast_availability >= product_qty` So with forecast_availability = 0 and product_qty = 2, the condition evaluates to False, incorrectly marking the move as not available. https://github.com/odoo/odoo/blob/c7fede7f44c668ccc0a094d8341c3cae8879a7f1/addons/stock/static/src/widgets/forecast_widget.js#L31 Solution: When the available quantity is sufficient to cover the move (using float_compare), set forecast_availability to the full available quantity instead of subtracting the move quantity. This ensures the JS condition correctly evaluates to True and the move is marked as available. opw-5159142 Forward-Port-Of: odoo/odoo#258504 Forward-Port-Of: odoo/odoo#257354
This change simplifies the setup of the Mollie payment method in POS. Previously, a validation error blocked users from saving their configuration, requiring them to repeat steps. Now, users can complete the initial setup once, and an error will still appear if the API key isn't provided before a payment is made.
Original PR description
Before this commit, when configuring the Mollie payment method in POS, a validation error would be raised if the associated payment provider did not have the API key set. While this makes sense given that it needs to be set in order for payments to work, it resulted in this unintuitive UX: 1. User fills in all the fields in the Mollie POS payment method form. 2. The user tries to save, but hits the validation error. 3. The user uses the internal link to go to the payment provider and fill in the API key. 4. The user returns to the POS payment method form, but because the form couldn't save they have to fill in everything *again*. This commit removes the validation error, allowing everything to be filled in just once. There will still be an error if trying to make a payment without an API key set. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260293
This update corrects a visual issue on the subscription portal where product lines weren't correctly aligned with tax totals. The change ensures that only invoiceable products are displayed, resolving the mismatch and providing accurate tax calculations for customers. This improves the clarity and reliability of subscription information.
Original PR description
Previously, the portal view for subscriptions displayed all un-collapsed products from the sales order, ignoring whether they were actually invoiceable lines. This caused a visual mismatch where the displayed lines did not correspond to the calculated tax totals at the bottom of the view. This commit updates the visibility logic to ensure that product lines are only included if they are invoiceable. task-6128619 Forward-Port-Of: odoo/enterprise#114088
This update fixes a previous issue where invoice settlement could fail if the commercial partner information wasn't fully loaded. The change streamlines the process by directly using the partner ID from the invoice data, preventing errors and ensuring smooth invoice settlement. This improves the reliability of the POS system.
Original PR description
Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice. This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID. opw-6023150 Forward-Port-Of: odoo/enterprise#113852 Forward-Port-Of: odoo/enterprise#111957
This update enhances the account reports experience on mobile devices and touchscreens. The chatter is now consistently visible at the bottom of the screen, and the annotation icon is always accessible, addressing previous issues where it was hidden or required a hover. This ensures users can easily review and interact with reports on any device.
Original PR description
Previously, the chatter was hidden on device too smalls and the annotation icon was only visible with hover so not visible on touch devices such as phones or tablets. Now, we have the chatter at the bottom when the device is too small and always display the annotation icon on touch devices. task-5106852 Forward-Port-Of: odoo/enterprise#95737
This update fixes an issue where floors were incorrectly displayed in the restaurant POS system. Previously, floors were loaded through indirect processes, leading to inaccurate floor selections. Now, the system correctly shows only the floors directly assigned to the current restaurant configuration.
Original PR description
Floors loaded indirectly (e.g. via recursive loading of paid orders) could appear in the floor selector even if they belonged to a different PoS config. The selector was iterating over the full in-memory model store instead of the floors explicitly assigned to the current config. opw-6025172 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259537 Forward-Port-Of: odoo/odoo#257113
This update fixes an issue where child contacts of German companies were incorrectly flagged as companies when the l10n_de_reports module was installed. The change ensures that only companies with their own distinct commercial entities are recognized as such, improving the accuracy of German tax reporting. This prevents misclassification and potential reporting errors.
Original PR description
Problem: When l10n_de_reports is installed, child contacts of a German company are incorrectly considered as companies as well. Steps to reproduce: 1. Install l10n_de_reports. 2. Create a company with a German VAT number (e.g. DE123456789). 3. Create a child contact under that company. 4. The child contact will be incorrectly considered as a company. Cause: If l10n_de_reports is installed, any partner with a German VAT number (DE + 9 digits) is considered as a company. Since child contacts share the same VAT as their company, they would be considered as companies as well, which is not correct. However, a partner should only be considered as a company if they are their own commercial entity. https://github.com/odoo/odoo/blob/e6bd6b106c376336594edd868c09505032008ac1/odoo/addons/base/models/res_partner.py#L819
This update enhances the accuracy of French Profit and Loss reports by splitting a key account. Specifically, it separates social security charges from salaries, aligning with French accounting standards (ANC PCG 2026). The old account remains for legacy systems but is marked as deprecated.
Original PR description
Splitting account 649 into two new accounts (6491 and 6492) is necessary to handle the Profit and Loss report properly. This ensures we can accurately separate social security charges from salaries in the report. Reference: ANC PCG 2026, page 445, note (h) https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf task-6053784 Forward-Port-Of: odoo/enterprise#112905 Forward-Port-Of: odoo/enterprise#111420
This update resolves a crash that occurred when opening salary adjustments on mobile devices. The issue stemmed from a missing delete action in the mobile view, which caused a technical error. The fix includes adding a necessary kanban view and correcting a field description to ensure proper functionality across all device types.
Original PR description
Steps to reproduce ================== - Install hr_payroll - Use a mobile viewport - Go to Employees - Open a record - Switch to the Salary Adjustments notebook tab => TypeError: undefined is not an…
Steps to reproduce ================== - Install hr_payroll - Use a mobile viewport - Go to Employees - Open a record - Switch to the Salary Adjustments notebook tab => TypeError: undefined is not an object (evaluating 'props.activeActions.onDelete=this.onDelete.bind(this)' Cause of the issue ================== The SalaryAttachment2ManyField widget overrides the rendererProps to handle the delete action, but this isn't defined on mobile (because a kanban view is used) See https://github.com/odoo/odoo/blob/9f93f22ed5f6d5dbbafeb0a8c6fababdc2a65d45/addons/web/static/src/views/fields/x2many/x2many_field.js#L196-L212 Solution ======== Since there is no delete action on the kanban view, there is no need for an override. While we are at it, there was no kanban view defined. Thus a default view was used https://github.com/odoo/odoo/blob/138fad6d54a0b59885b1e5c712beb8f581c9555c/odoo/addons/base/models/ir_ui_view.py#L2835-L2846 It only contained the field description. Since that one is optional, records without a description were almost invisible.. Thus we also add a basic kanban view opw-6047295 Forward-Port-Of: odoo/enterprise#113317
This update fixes an issue where invoices generated from KSeF bills weren't correctly processing gross unit prices. The system now properly handles both net and gross unit price options provided by vendors, ensuring accurate invoice generation and compliance with Polish tax regulations. This prevents incorrect invoices and potential tax discrepancies.
Original PR description
**PROBLEM** When receiving bills from KSeF, we don't handle gross unit price and default to a price_unit of 0.0. Leading to an incorrect invoice. When generating the bill, the vendor can choose to report the net unit price (P_9A) or gross unit price (P_9B). We need to handle both cases. opw-6066027 Forward-Port-Of: odoo/odoo#260314
This update fixes a frustrating issue where clicking 'Discard' in the Sign Template would cause the page to reload and flicker. Now, the discard process happens instantly within the existing sign iframe, providing a smoother and more reliable user experience. This simplifies the process and improves usability.
Original PR description
Before this commit, clicking Discard in Sign Template reloaded the action/PDF iframe, which caused flicker. The discard flow was also more complex than needed and field normalization was noisy. After this commit, discard now happens in place: we fetch fresh sign items/radio sets, reset fields inside the existing iframe, and keep the page mounted with no reload. task-6121560 Forward-Port-Of: odoo/enterprise#113853
This update resolves issues where imported BIS3 invoices didn't accurately reflect totals due to data synchronization problems. The changes improve the import process by streamlining data handling and ensuring correct calculations, leading to more reliable invoice data. A new testing approach, 'Partial Imports,' has also been implemented for better test management.
Original PR description
This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file. The new way we import BIS3 invoice can be…
This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file. The new way we import BIS3 invoice can be categorized as: - collecting all the values from the XML to a dictionary object - prepare the values and amounts to write to the invoice in its entirety using the tax computation engine helpers - write the whole processed values to the invoice (as a single write) - (in 18.0 ~ 18.2) recalculate discrepancies and update the invoice lines (if needed) with the corrected amounts This commit also includes a new test suite for BIS3 import, and a new approach of import testing, "Partial Imports", is introduced to better atomize the big import test files (and make it understandable). In the long term, `l10n_account_edi_ubl_cii_tests` will eventually be removed in favor of these small-but-many partial tests. task-id: 5058687 Co-authored-by: Yosua Nicolaus <yoni@odoo.com> Forward-Port-Of: odoo/odoo#260128 Forward-Port-Of: odoo/odoo#250160
This update enhances the accuracy of invoice data imports by adding a crucial filter to identify partners associated with move lines. It's part of a larger effort to correct inconsistencies in invoice data synchronization. This ensures more reliable financial reporting.
Original PR description
This commit is part of a bigger commit on the community side- to refactor the import code of BIS3 Invoice to fix various unsynchronized values issues. task-id: 5058687 Forward-Port-Of: odoo/enterprise#114351 Forward-Port-Of: odoo/enterprise#108356
This update resolves a problem where activity updates weren't reliably shared between Odoo tabs. The issue stemmed from interference with a specific internal route (`/mail/data`) during testing. This fix ensures activity updates function consistently, improving the reliability of testing and the overall user experience.
Original PR description
The `@mail/activity/activity/activity updates are shared between tabs` fails in a non-deterministic fashion. It occurs because the `/mail/data` route can interfere with the test. runbot-242616 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260529 Forward-Port-Of: odoo/odoo#260265
This update resolves a bug where users with limited permissions were encountering errors when accessing task details within subscription orders. The fix involves simplifying data retrieval to prevent privilege-related access issues, ensuring smoother operation for all users.
Original PR description
The change in e75bc6a1fac056d72fe9e73513635f9e0ba7db22 may cause some access errors when the user don't have the proper privileges. STR: 1. Having a user (demo) with minimal permissions: sales own documents, timesheets and project user 2. Having a sales order for customer that demo user can read with services in it. 3. Having that customer a task with a sale that the demo user can't read. 4. When the user tries to change the line to one that he can actually read, an error raises. The display_name function tries to fetch data from the lines related order. Let's just sudo that fetch to avoid these kind of issues. A demo video: https://www.loom.com/share/ddd02d72bcea4652b79549aba47d5334 opw-5969767 cc @moduon MT-14483 Forward-Port-Of: odoo/enterprise#113996
This update streamlines the way Odoo processes XML reports within the l10n_sk_reports module. By using the standard XML parser, we've reduced unnecessary complexity and improved performance. This change ensures more efficient report generation and maintenance.
Original PR description
Removes the custom XMLParser configuration in favor of the default etree parser. This reduces unnecessary overhead and ensures we are using the standard library's recommended defaults for processing XML content.
This update ensures that service order line display names accurately show the price unit when requested, regardless of context. Previously, the display name was inconsistent, potentially omitting the price unit for service products. This fix corrects a bug related to how the 'with_price_unit' context flag is used, improving the clarity and accuracy of service order information.
Original PR description
Before this commit, when `formatted_display_name` is true in the context, the display name of `sale.order.line` records will always show the partner and the price unit if it contains a service product. The problem is `with_price_unit` is no longer checked in the context to really know if we want to display or not the price unit in the formatted display name. This commit checks `with_price_unit` in the context to display the price unit in the formatted display name if it is truly in the context.