Thursday, April 23, 2026
26 changes · saas-19.1
New functionality added to Odoo
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
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 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
- 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
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
This 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 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 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 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 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 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