Monday, June 8, 2026
34 changes · saas-19.3
Enhancements to existing features
This update aligns the default VAT reporting frequency for Norwegian businesses within Odoo Enterprise to bi-monthly (every 2 months). This change simplifies reporting for Norwegian companies, matching the most common reporting practice in Norway and reducing potential compliance complexities. This update ensures accurate and streamlined VAT reporting for our Norwegian customers.
Original PR description
Set the default VAT periodicity for Norwegian companies to every 2 months, aligning with the most commonly used reporting frequency in Norway. task-6209940 Forward-Port-Of: odoo/enterprise#119524 Forward-Port-Of: odoo/enterprise#117054
This update clarifies how half-day work periods are displayed on payslips. Previously, half-days were shown as separate entries, creating confusion. Now, the system consolidates these entries for a clearer and more straightforward view of an employee's work time and pay.
Original PR description
In order to clearly distinguish work days that extended full day or half day, the worked days under the payslips will not display both entries as separate types with the half days flagged Task: 5975762 Forward-Port-Of: odoo/enterprise#112328
This update improves the DEP7 export process by switching from PDF to JSON files. This change ensures compliance with BMF (RKSV) requirements and provides machine-readable data for official tools, streamlining reporting and data exchange.
Original PR description
In this commit: ------------------- - Updated the DEP7 export to generate a zip with JSON files instead of PDF, in compliance with BMF (RKSV) requirements. - The export now produces a valid JSON document containing the machine-readable data expected by the official BMF tools. - The filename format has also been adjusted to follow common conventions (e.g. `Name_Duration_DEP_KassenID.json`). Task: 6071034 Forward-Port-Of: odoo/enterprise#112276
Resolved issues and error corrections
This update ensures that all date references within the stock accounting module consistently use Odoo's standard date format. Previously, the system relied on the user's device settings, which could lead to inconsistencies in reports and data. This change improves data accuracy and reliability for financial reporting.
Original PR description
Why this Commit: --- toLocaleString() relies on the device's local format instead of the Odoo-configured format. Since Odoo already defines a standard date format,the toLocaleString() usages should be replaced to ensure consistency. After this commit: --- <img width="1884" height="363" alt="image" src="https://github.com/user-attachments/assets/8cee2d86-10dc-48d7-8c3a-369ec257c101" /> date references consistently use the Odoo-configured date format. OPW: 6087341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259651
Code cleanup and technical improvements
This update simplifies how plugins manage submit buttons within Odoo. Previously, a single, hardcoded list required developers to modify core code for each plugin. Now, plugins can easily register their own submit button selectors, making updates and maintenance much easier and more flexible. This improves the overall stability and maintainability of the Odoo platform.
Original PR description
\* = website, website_payment Previously submit button selectors were defined in a single hardcoded string in the save snippet logic. This made the list harder to maintain and required modifying the base code whenever a new plugin needed to exclude its submit button from being saved as a snippet. Introduce a resource allowing plugins to register their own submit button selectors. Plugins can now extend this list directly from their code without modifying the base implementation. This makes the logic easier to maintain and provides a reusable extension point for other submit-button related behaviors in plugins. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266991 Forward-Port-Of: odoo/odoo#252679
This update resolves an issue that prevented successful testing of duplicated databases for the l10n_de_pos_cert module. Specifically, the commit removes `client_id` and `tss_id` during database duplication, allowing for proper testing in neutralized environments. This ensures consistent and reliable testing of the German POS certification functionality.
Original PR description
In this commit: -------------------- - On a duplicate database `client_id` and `tss_id` are removed so it works as test in neutralized dbs without throwing errors. task- 5457231 Forward-Port-Of: odoo/enterprise#104119
This update fixes an issue where portal users were redirected to the wrong folder when accessing documents. The fix ensures that links from the Documents section correctly navigate users to the intended folder, improving the user experience and preventing confusion. This was caused by a minor coding oversight that has now been resolved.
Original PR description
# How to reproduce - As admin, give access to folder X & folder Y to a portal user - As that portal user, go to Documents, click on folder X and copy the page url - Click on folder Y - Paste the URL in the browser's search bar # The problem You are still in folder Y, even though the link should be to folder X. # Cause We forgot to keep `documents_init`' s `folder_id` (refactored into `user_folder_id`) in https://github.com/odoo/odoo/commit/6bdcc357b195faa0aad8c05eac23aa0a762dd76b opw-6132231 Forward-Port-Of: odoo/enterprise#116928
This change fixes an error that occurred when users removed the CRM module after installing it. The tour service incorrectly attempted to retrieve a tour data based on a module that was no longer present, leading to a system error. This fix ensures the tour service functions correctly regardless of the CRM module's installation status.
Original PR description
When the user installs the ``crm`` module and later uninstalls it, a traceback is generated. Steps to reproduce the error: - Install ``crm`` module and then uninstall it Traceback: ```py IndexError:…
When the user installs the ``crm`` module and later uninstalls it, a traceback is generated. Steps to reproduce the error: - Install ``crm`` module and then uninstall it Traceback: ```py IndexError: list index out of range ``` When the tour service starts, it retrieves the last tour stored in localStorage at [1] which is ``crm_tour``. In commit [2], ``options.fromDB`` was removed. Because of this, the condition is bypassed and ``get_tour_json_by_name`` called for ``crm_tour`` at [3], which does not exist in the database. It then calls ``_get_tour_json``, which leads to the above traceback from the following line. https://github.com/odoo/odoo/blob/575ad98eecf3f3760b8a0b482cd3b71e8ad4b50f/addons/web_tour/models/tour.py#L48-L53 [1]: https://github.com/odoo/odoo/blob/575ad98eecf3f3760b8a0b482cd3b71e8ad4b50f/addons/web_tour/static/src/js/tour_state.js#L13-L15 [2]: https://github.com/odoo/odoo/commit/7e5fdec2e600feb0fbfc663107175b75ec842fea [3]: https://github.com/odoo/odoo/blob/575ad98eecf3f3760b8a0b482cd3b71e8ad4b50f/addons/web_tour/static/src/js/tour_service.js#L163-L164 sentry-7473093931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request reverts a recent change that was causing missing information (like order details) on the DIN 5008 delivery slip. The fix prioritizes stability and avoids impacting a large number of customers. This ensures accurate delivery slip printing for all users.
Original PR description
This reverts [1] since it breaks the delivery slip To reproduce the issue: (Need `stock`) 1. Configure the document layout as DIN 5008 2. Create and validate a delivery order 3. Print the delivery slip Error: Some information have disappeared (order, shipping date, and so on) Reverting [1] since it's a recent commit, its use case is neither important nor urgent, and it impacts several customers. [1] 8d588f8198d9057311304e596c009a0795ca6ec7 OPW-6250072 OPW-6260066 OPW-6249926 OPW-6264966 Forward-Port-Of: odoo/odoo#268475
This update fixes an error in the German localization (l10n_de) module where the title of a specific section was incorrect. Specifically, two lines of data related to credit notes were being reported negatively, which has now been corrected to accurately reflect revenue. This ensures accurate financial reporting within the Odoo system.
Original PR description
title of the B section is wrong. 2 lines need to be multiplied by -1 because they come from credit note but must be reported positively since they are revenue. Source https://www.odoo.com/odoo/documents/tPsLeM-TT--tTeztKJYzmAo4ae27b opw-6204994 Forward-Port-Of: odoo/odoo#267759
This update resolves a permission issue that prevented users from correctly sorting fiscal positions when they were linked to companies outside their authorized access. The fix ensures that access checks are performed correctly, preventing errors and improving data accuracy. This change enhances the stability and reliability of the accounting module.
Original PR description
_get_first_matching_fpos() sorts fiscal positions by company specificity using `f.company_id.parent_ids`. The `parent_ids` field on `res.company` is compute_sudo=True, but `convert_to_record` still builds the resulting recordset in the caller's environment and then calls `filtered('active')` on it. When the fiscal position belongs to a child company whose parent is outside the current user's allowed companies, reading `active` on the parent company record raises an AccessError.
opw-6266568
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#268619
Forward-Port-Of: odoo/odoo#267747This update resolves an issue where a payrun would unexpectedly be marked as cancelled after removing a single payslip. Previously, removing a payslip could disrupt the payrun's status, even if other employees were still associated with it. This fix ensures payruns remain in the correct state after individual payslip removal.
Original PR description
Fixes the following bug in payruns: - create a payrun, leave it in draft - create a single payslip, add it to the previously created payrun. The payslip employee will appear in the payrun employee list - for the previously created payslip, remove it from the payrun - go back to payruns kanban view, the payrun will results as cancelled even if there still were other employee entries in it (the one defined at start) task: 6237460
This update resolves an issue preventing users from editing the short description of new partners within the website interface. The change re-enabled necessary styling and formatting to allow for text input, improving the partner management experience. It also includes a minor fix to preserve placeholder attributes for improved usability.
Original PR description
Steps to reproduce: 1. Create a new partner with any level. 2. Click on the Go to Website button and publish it. 3. Now go to the /partners page and activate editor. 4. Now try to edit the short…
Steps to reproduce: 1. Create a new partner with any level. 2. Click on the Go to Website button and publish it. 3. Now go to the /partners page and activate editor. 4. Now try to edit the short description of the partner. Current behavior: The short description is not editable in the frontend. This is due to the changes made in the editor, before the changes, the o_editable class was getting added additional properties to give it a minimum height and width, along with making it an inline-block element. But now, these properties has been removed, which is causing an issue for users adding new partners and trying to edit the short description in the website. Solution: We brought back the crm_partner_assign.scss and added the properties back to the o-editable element inside our specific partner short description. Also added a placeholder to the short description to make the interaction more intuitive for users. opw-5955922 Forward-Port-Of: odoo/odoo#266211 Forward-Port-Of: odoo/odoo#253097
The appearance of the portal chatter message delete dialog has been corrected. This change addressed a visual issue caused by a recent update that lacked the necessary styling for the dialog's size and content, specifically related to HTML formatting within messages. This ensures a consistent and professional user experience for portal users.
Original PR description
The delete message dialog in the portal chatter has been visually broken since #247708, which replaced the generic `MessageConfirmDialog` (size="xl") with a dedicated `MessageDeleteDialog` (size="md"). The md size triggers the `o_modal_design_minimal` design path in `dialog.js`, whose styles are defined in `dialog.scss`. Additionally, message content may contain html_editor-formatted elements (blockquote in thi scase) whose styles come from `html_editor.assets_editor`. Neither was included in `portal.assets_chatter_style`. This change adds those missing styles to the portal chatter shadow DOM. **Before:** <img width="637" height="290" alt="image" src="https://github.com/user-attachments/assets/2dae0e72-383d-4277-94e7-ef23a01ea53b" /> **After:** <img width="637" height="317" alt="image" src="https://github.com/user-attachments/assets/ca36bc51-3cc9-43c6-bcf2-30c03498353c" /> Forward-Port-Of: odoo/odoo#268233
This update fixes a visual misalignment issue with the alert content displayed in the Odoo portal. The change was a result of a previous fix, and we've simplified the styling to ensure alerts appear correctly. This improves the overall user experience and consistency.
Original PR description
The alert content is misaligned these changes are side effects of commit[1], the `h5` and `p` in the alert have margin that creates whitespace in the alert. Commit[2] addressed a misalignment issue and alignment issue due to nested `row` but these became irrelevant with commit[1]. This is why we remove the styling. task-5262108 [1]: odoo/odoo@513931a5e540f22f37e317f80fd131701cbbc8f0 [2]: odoo/odoo@d64dbaadcb1bef27d89a89e9d42bdb38890c73e0 | Before | After | |--------|--------| | <img width="1029" height="523" alt="image" src="https://github.com/user-attachments/assets/ff3f827b-652a-4a84-ad7e-205200cf3256" />| <img width="1022" height="486" alt="image" src="https://github.com/user-attachments/assets/b86163d8-bedd-4cb6-a950-ba36a6b401ee" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268249 Forward-Port-Of: odoo/odoo#267776
This update resolves a technical error that prevented users from correctly configuring billing targets within the timesheet settings. The fix ensures that the system accurately retrieves necessary data for billing calculations, improving the reliability of timesheet reporting. This change was triggered by a necessary update to a core component of the timesheet functionality.
Original PR description
… of employees Prerequisites to reproduce: - Enable `Billing Rate Indicators` in timesheets. - Change timesheet access of user to `User: all timesheets` - Remove Employee access Steps to Reproduce: - In Timesheets app, from configuration go to `Billing Time Targets` - Click on view button on any row Issue: - A traceback breaking the flow. Reason: - We use `hr_presence_status` widget which requires `work_location_type` field, change made from https://github.com/odoo/odoo/commit/0496ed10636c7b2dfde7038a43494d4edbd9f95b. - Thus unavailability of field causing the traceback. Fix: - Add a related field for work_location_type from which we get the value. Forward-Port-Of: odoo/enterprise#97502
A recent update to the enterprise modules caused a minor issue with Odoo's menu loading tests. This change has been fixed by adjusting the expected query counts in the tests to match the new system behavior. This ensures the tests continue to run successfully and accurately reflect performance.
Original PR description
Due to fix in enterprise modules introduced an additional query during menu loading. As a result, the menu loading tests started failing because their expected query counts are hard coded. Update the affected tests by increasing the expected query count by one. task-6236300
This update resolves a bug that prevented users from creating new social media posts when no social account was configured. The fix ensures the system handles scenarios where the message field is read-only, preventing a crash related to measuring the textarea's dimensions. This improves the reliability of the social media posting feature.
Original PR description
Steps to reproduce: 1. Install social module 2. Keep no social account set 3. Create a new post by social media > posts menu > new Issue: We got a traceback saying: `OwlError: An error occured in the owl lifecycle (see this Error's "cause" property) TypeError: Cannot read properties of null (reading 'getBoundingClientRect')` Cause: When no social account is set, the message field renders in read-only mode, so the <textarea> is never mounted, and textareaRef.el is null. The useEffect tracking the textarea's width fires and crashes. https://github.com/odoo/enterprise/blob/77be4285785f9d8a462b99b23185a9aefeae4482/social/views/social_post_template_views.xml#L37-L41 Solution: Add a null guard on textareaEl inside the useEffect callback so that the width computation is skipped when the textarea is not present in the DOM. opw-6218431
This update fixes a technical error that was preventing warning messages from being logged correctly in the IoT module. The issue stemmed from how data was being passed to logging functions, and this change ensures all warning messages are properly recorded for monitoring and troubleshooting.
Original PR description
Error: ``` TypeError: Logger._log() got an unexpected keyword argument 'ip' ``` Cause: - The `**new_iot_record` unpacks the dictionary into keyword arguments for `Logger._log()` instead of supplying it as the value for the third `%s` placeholder in the warning message, causing the error because `_log()` doesn't accept keywords such as `version` or `ip`. sentry-7522168864 Forward-Port-Of: odoo/enterprise#119494
This update resolves a technical error that was preventing the POS HR module from functioning correctly in certain situations. The change replaces a problematic data source with a more reliable one, ensuring consistent performance and stability for users. This fix addresses a potential issue that could have caused errors and disruptions.
Original PR description
`pos.config.current_session_id` is a computed field from the backend. In some cases, it's possible that we don't have this field causing the following error
```
TypeError: undefined is not an object
(evaluating 'this.config.current_session_id.id')
```
task: https://www.odoo.com/odoo/project/1737/tasks/6253422
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#267225
Forward-Port-Of: odoo/odoo#266858A technical issue preventing leave requests created on weekends was fixed. This update ensures that leave requests are correctly processed regardless of the day of the week, improving the reliability of the HR system. The fix addresses a test failure related to weekend scheduling.
Original PR description
Fix a test that creates a leave to ensure this leave is created. During week-ends, the test would fail as it was out of the employee's schedule runbot error 242476
This update resolves a technical issue that caused delays during Odoo's initial startup process. By optimizing how reference units are fetched, the system now loads more reliably and efficiently, reducing potential startup problems. This change also minimizes unnecessary network requests, improving performance and stability, especially in offline environments.
Original PR description
…race The `setup()` lifecycle hook executes synchronously, meaning the initial `orm.searchRead()` calls to fetch the reference unit and rounding digits could not be awaited. As a result, the component would finish rendering before the RPC responses arrived, which could lead to timing issues during initialization. Additionally, `onWillUpdateProps` would refresh the reference unit on product property updates even outside of an active search context, leading to extra RPC traffic. In offline scenarios, this could result in unexpected blocking behavior for non-cached network requests. To streamline this process, the fetch logic has been moved into `search()` so the reference unit is resolved only when required. We also switch to `orm.read()` since the target IDs are already available, and cache the `decimal.precision` results to minimize redundant RPCs.
This update resolves an issue where activity labels in the chatter interface weren't showing correctly when the default summary was removed. The fix ensures that activity labels now consistently pull from the 'display_name' field, providing accurate and complete labels for all activity updates. This improves the user experience and ensures consistent information display.
Original PR description
Before this commit: --- - Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get…
Before this commit: --- - Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get the display name. - If `summary` was empty, it fell back to [`display_name`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L44). - However, `_to_store` only [stored](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/models/mail_activity.py#L680) `summary`. - As a result, nothing was shown when `summary` was empty, even though `display_name` was set. Steps to reproduce: --- - Create an activity in chatter - Remove the default summary if set. - Observer the title. https://github.com/user-attachments/assets/1684feb7-02d0-4ac1-9c00-d2aaae88e045 After this commit: --- - Added `display_name` to `_to_store` along with `summary`. - Chatter activity now correctly falls back to `display_name`. - Users can now see the correct activity label in chatter. OPW: 6212976 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267555 Forward-Port-Of: odoo/odoo#266706
A bug was preventing users without Live Chat access from viewing visitor reports. This was caused by a misconfiguration in how the system checks user permissions for accessing Live Chat data. This fix ensures that users without Live Chat access can still access basic visitor reports.
Original PR description
**Steps to Reproduce** 1. Open a database in version 19.2 with demo data. 2. Install the `website` and `im_livechat` modules. 3. Login with another user who has access to the Website application but…
**Steps to Reproduce**
1. Open a database in version 19.2 with demo data.
2. Install the `website` and `im_livechat` modules.
3. Login with another user who has access to the Website application but does not have access to the Live Chat application.
4. Navigate to: **Website → Reporting → Visitors**
5. An `AccessError` is raised with the traceback below.
**Issue:**
The traceback is caused by the following [commit](https://github.com/odoo/odoo/pull/240778/changes#diff-580c2ced97a218f926605037b31c4fd2d01253eb1b4f290038f251f9ef31be3b) introduced in v19.2.
In this commit, a new [computed field](https://github.com/odoo-dev/odoo/blob/381aede4fde0f871b51df41911c28be3153cd489/addons/website_livechat/models/website_visitor.py#L32) `current_livechat_agent_ids` was added on `website.visitor`.
Inside this compute, data from `im_livechat.channel.member.history` is accessed using `_read_group`.
However, `im_livechat.channel.member.history` is only accessible to users belonging to the following group: `im_livechat.im_livechat_group_user`
At the same time, the Website Visitors menu is accessible to normal Website users through the Website module [ACLs](https://github.com/odoo/odoo/blob/006a6a1cc6e50bd8b328d0cabb7abbcf610e34bb/addons/website/security/ir.model.access.csv#L30)
The issue occurs because the same `website.visitor` views/actions are reused from multiple menus (Website, Social Marketing, Live Chat), but the compute method assumes that the current user has Live Chat access.
As a result, when a user without Live Chat permissions opens: **Website → Reporting → Visitors**
the compute of `current_livechat_agent_ids` triggers an `AccessError`.
**Solution:**
To fix this issue, a group access added on the field `current_livechat_agent_ids`
**Traceback:**
```python
File "/home/odoo/src/odoo/saas-19.2/addons/
website_livechat/models/website_visitor.py", line 32, in
_compute_current_livechat_agent_ids
self.env["im_livechat.channel.member.history"]._read_group(
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 1933, in
_read_group
self.browse().check_access('read')
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 3373,
in check_access
raise result[1]()
odoo.exceptions.AccessError: You are not allowed to access
'Keep the channel member history' (im_livechat.channel.member.history) records.
This operation is allowed for the following groups:
- Live Chat/User
Contact your administrator to request access if necessary.
```
opw : 6169395
upg : 4286153, 4286493, 4283345
tbg : 2676
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#265534This update fixes a potential error in the payment authorization process. It prevents issues that could arise when entering excessively long addresses during credit card payments via Authorize.net, ensuring data compatibility with the payment gateway's requirements. This improves the reliability of payment processing.
Original PR description
Steps to reproduce: - install payment_authorize module; - complete a credit card payment using Authorize.net with more than 60 characters on any other field than first name, last name or company; - confirm the payment. Issue: An error message appears. Cause: The Authorize.net API define the max length of information. It is possible that some information exceeds the maximum length. (https://apitest.authorize.net/xml/v1/schema/AnetApiSchema.xsd) Solution: Truncate information if the number of character is too large. opw-6141441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262154
This update resolves a problem where the size of country flags on the Visitors reporting page was changing unexpectedly, particularly after installing the livechat app. The fix also ensures that flags set through Studio remain visible and responsive to size adjustments, preventing them from disappearing.
Original PR description
The website.visitor.view.kanban view uses the o_country_flag class which is not defined anywhere besides livechat_channel_info_list.scss. This causes unintended behavior where the flag size for the kanban view on ' Website > Reporting > Visitors ' changes when installing the livechat app. Additionally, the image_url_field.js file does not address cases when height/width are not set. This results in the flags (or any other image using 'widget="image_url"' disappearing (being set to a 'width: 0px') whenever their Size is set via Studio. This change makes it so that the flags don't disappear when altered in Studio (but does not make them actually respond to size changes) Related tickets: opw-5962151, opw-5995004 Forward-Port-Of: odoo/odoo#251618
This update resolves an issue where enabling the 'Sales Credit Limit' setting caused an access error when creating new users. The problem stemmed from a default value being incorrectly applied to a restricted field due to inheritance within the system. This fix ensures the system functions correctly with the new setting enabled.
Original PR description
# How to reproduce - Install the Accounting module - In the settings, enable "Sales Credit Limit" - Remove the Accounting access rights of the current user - Try to create a new user # The issue An…
# How to reproduce - Install the Accounting module - In the settings, enable "Sales Credit Limit" - Remove the Accounting access rights of the current user - Try to create a new user # The issue An access error is raised on the field `credit_limit` # Cause Enabling the "Sales Credit Limit" setting will create an `ir.default` for the `credit_limit` field. This field is restricted to a specific group : https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/account/models/partner.py#L515-L518 When creating a record, we check field permissions before adding default values, so the creation of the user is fine. However, since `res.users` inherits from `res.partners`, a new partner will also be created, but this time with the default values in `vals_list`, which will trigger an access right error. # Proposed solution Back port of this commit : https://github.com/odoo/odoo/pull/267193 Access right checks when creating a record were introduced in 18.3 by : https://github.com/odoo/odoo/commit/15132342960df76fcefd3284a9eff2d4d3273150 opw-6240494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268303 Forward-Port-Of: odoo/odoo#268039
This update resolves a technical error that could occur when calculating rental availability for products with start and return dates. Specifically, it prevents a traceback when dates are incompatible, ensuring accurate availability information is displayed to customers on product pages. This improves the overall rental booking experience.
Original PR description
Preventing traceback on incompatible dates between the cart and the product page. How to reproduce: 1. Add to cart a product with periodicity Hours/Days with a start date = return date (e.g.: Projector). 2. Go to the product page of a product configured with Pickup > Return (e.g.: Premium Bike, Luxury Room) 3. Traceback, as we try to get the availabilities on a negative period. start date > end date, as both dates are equals and the time is set from the Pickup and Return fields. Forward-Port-Of: odoo/enterprise#119480
This update fixes a missing translation for the 'Count LoC' report within Odoo's technical menu. Adding this translation ensures consistent and accurate reporting across all supported languages, improving the user experience for international customers.
Original PR description
Before this commit, the technical menu for the 'Count LoC' report was never translated. This commit adds it to the translated terms.
This update resolves an issue preventing Odoo from correctly validating Turkish VAT invoices when using GİB placeholder VAT numbers. Turkish regulations permit these placeholders for specific invoice types, and this change ensures Odoo accepts them while maintaining existing VAT validation rules and test environment exceptions. This improves compliance for Nilvera users in Turkey.
Original PR description
- Turkish regulations allow the usage of special placeholder identifiers for invoices issued to non-taxpayer end consumers and overseas customers, where providing a real TCKN/VKN is not mandatory. - Although Odoo already referenced these identifiers in the VAT format help message (`11111111111` for TCKN and `2222222222` for VKN), they were still rejected by the Turkish VAT validation logic because they do not pass the standard `stdnum` checks. - This commit extends the Turkish VAT validation to explicitly allow these GİB-approved placeholder identifiers while preserving the existing standard VAT validation behavior and Nilvera test environment exceptions. taskID-6237629
This update resolves an issue where Spanish users were incorrectly interpreting durations entered with decimal separators (e.g., "0,5"). The code was adjusted to properly handle the order of replacing decimal and thousand separators, ensuring durations are now recognized accurately in Spanish. This improves the usability of the Timesheet feature for Spanish-speaking users.
Original PR description
Issue: ---------------------------------------- In Spanish, inputting "0,5" as a duration is recognized as 5 hours instead of 30 minutes. Steps to reproduce: ----------------------------------------…
Issue:
----------------------------------------
In Spanish, inputting "0,5" as a duration is recognized as 5 hours instead of 30 minutes.
Steps to reproduce:
----------------------------------------
- Install Project and Timesheet
- Switch the user language to Spanish
- Open a task, in the "Timesheet" page, create a new line
- Input "0,5" as duration
Cause:
----------------------------------------
In the parser, the value is transformed according to the language decimal point and thousands separator:
```js
value = value
.replaceAll(localization.decimalPoint, ".")
.replaceAll(localization.thousandsSep, "");
```
In Spanish `decimalPoint` is "," and `thousandsSep` is ".". So the first `replaceAll()` changes "0,5" into "0.5", then the second one deletes the point.
Solution:
----------------------------------------
We need to invert the two `replaceAll()`.
As the `thousandsSep` is just removed, this will not create a new issue in another language.
opw-6263523
Forward-Port-Of: odoo/odoo#268461This update corrects a previous issue that limited product options when creating sale orders on mobile devices. It now allows users to add products with `sale_ok=False` and non-rental products to rental orders, expanding flexibility. This change resolves a regression introduced in a prior update.
Original PR description
This commit reverts 6e8a2d9c2d80044f6ee33c96871accf0aa83f4eb which introduce regression by ignoring product domain from `_domain_product_id`. Due to this issue, you can add products with `sale_ok=False` in SOL using a phone. Also you could add non-rental product in rental orders. opw-6218312 Forward-Port-Of: odoo/odoo#268331
This update resolves an issue where the activity rate for Swiss payroll calculations was incorrectly tied to individual employees instead of the Odoo Enterprise version. This change ensures accurate reporting and compliance with Swiss tax regulations by basing the rate on the correct Odoo version.
Original PR description
…ployee Forward-Port-Of: odoo/enterprise#119658
This update corrects tax calculations and closing logic for split payments in Italy (l10n_it). Specifically, it removes redundant tax data and ensures accurate tax reporting within the split payment process, leading to more reliable financial records.
Original PR description
with this commit:- - Removing unnecessary 'SP Pos.' taxes. - Adopted correct tax data for 'SP' taxes so that it works correctly in Split Payment case. - By these changes, tax closing entries will become hermetic. task-6116304 Forward-Port-Of: odoo/odoo#268747 Forward-Port-Of: odoo/odoo#264336