Daily updates from Odoo
Monday, June 8, 2026
146 changes
23 changes
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
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
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#265534Code 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
26 changes
Enhancements to existing features
This update adjusts the default VAT reporting frequency for Odoo's Norwegian accounting module to bi-monthly (every two months). This change aligns with the most common VAT reporting practice in Norway, simplifying the process for Norwegian businesses using Odoo. It ensures compliance and reduces potential reporting discrepancies.
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
Resolved issues and error corrections
A bug was preventing users without Live Chat access from viewing visitor reports. This was caused by a misconfigured access check within the website reporting feature. This update corrects this issue, ensuring all users can access visitor data.
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-prThis update fixes a calculation error in online orders using UrbanPiper, ensuring that the displayed price (Tax Included) accurately reflects the total cost, including GST. Previously, the system incorrectly calculated the price, leading to discrepancies. This change ensures accurate pricing and a better customer experience.
Original PR description
Steps to reproduce: --- - Configure Point of Sale with UrbanPiper credentials. - Sync a product priced at 100 with a 5% GST (tax type = Tax Included). - Place a test order. Issue: --- - Wrong calculation in order line: - unit_price: 95.24 - Tax Excl. price: 90.70 - Tax Incl. price: 95.24 - Expected: - unit_price: 100 - Tax Excl. price: 95.24 - Tax Incl. price: 100 Cause: --- - While computing the unit_price with Tax Included, the tax amount was not added back. Fix: --- - Ensure unit_price includes the tax amount when tax type is Tax Included. task-5031196 Forward-Port-Of: odoo/enterprise#119314 Forward-Port-Of: odoo/enterprise#92854
This update resolves an issue where users were unintentionally able to select properties within the field selector widget. The fix adds a new option to the widget, allowing for proper property selection, and includes a corresponding test to ensure functionality. This improves the user experience and prevents potential data entry errors.
Original PR description
- Backporting this [commit], for adding the `allow_properties` option to `field_selector` widget in `saas-18.2` for using the functionality in linked enterprise commit. - Also, added a test for `allow_properties` option. - For forward ports, only the test will be merged, as `allow_properties` is already included in the original commit. [commit]: https://github.com/odoo/odoo/pull/215767/changes/7cd18c07b5e008bff072d10375c908eb77434fde sentry-7378769090 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268471 Forward-Port-Of: odoo/odoo#257833
This update resolves an issue where users were encountering errors when attempting to use property fields within auto-fill fields in the Sign module. The fix restricts property field selection, ensuring stability and preventing errors during data entry. This improves the user experience when configuring sign items.
Original PR description
Currently, an error occurs when user tries to select a property field in auto field. Steps to replicate: - Install `sale_management` and `sign`. - Open Sales > Products > Products > Open any product.…
Currently, an error occurs when user tries to select a property field in auto field.
Steps to replicate:
- Install `sale_management` and `sign`.
- Open Sales > Products > Products > Open any product.
- From the Gear icon, Click Edit Properties and save the record.
- Enable Debug mode if you are using a version lower than 19.0 .
- Open Sign > Configuration > Field Types.
- Create a new Field > Give a name > Select model as `Product`.
- Select Field as `Property > Property 1` and click save.
Error:
- saas-18.3 and later:
```
File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py', line 57, in _check_auto_field_exists
auto_field_value = record.mapped(sign_type.auto_field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5472, in mapped
field = records._fields[field_name]
^^^^^^^^^^^^^^^
AttributeError: 'Property' object has no attribute '_fields'. Did you mean: 'field'?
```
- saas-18.2:
```
File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py, line 41, in _check_auto_field_exists
auto_field_value = record.mapped(sign_type.auto_field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5744, in mapped
if len(records) > PREFETCH_MAX:
^^^^^^^^^^^^
TypeError: object of type 'bool' has no len()
```
Cause:
- As the user gave auto fill field as a Property field the [line] called `mapped()` to access its value, this caused the error to occur.
- This occurs because `mapped()` expects a `recordset` (models.Model), but instead it receives a Property object, which does not have `_fields`.
Solution:
- Using `'allow_properties': 'False'`, the property fields wont appear in the list of field selection.
[line]: https://github.com/odoo/enterprise/blob/cdaeb79e1f623831fffa553dbb658698367c7e19/sign/models/sign_item_type.py#L41
sentry-7378769090
Forward-Port-Of: odoo/enterprise#119493
Forward-Port-Of: odoo/enterprise#113091This update ensures all date displays within the stock accounting module use Odoo's standard date format, regardless of the user's device settings. Previously, the system relied on local device settings, leading to inconsistent date representations. This change improves clarity and accuracy for all users.
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
This update resolves an issue that prevented proper testing of the German POS certification module when duplicating databases. The code now safely removes identifying information (client_id and tss_id) during duplication, allowing for accurate testing in neutralized database environments. This ensures the module functions correctly and reliably.
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
A recent update has fixed an issue where portal users were redirected to the wrong folder when accessing documents. This was due to a technical oversight in how folder permissions were handled. Now, links to documents will reliably take users to the intended folder.
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 update corrects a bug where Spanish users were incorrectly interpreting durations entered with decimal separators (e.g., "0,5"). The fix reverses the order of replacements in the parsing process, ensuring that the decimal point is correctly identified and handled. This ensures accurate duration input and calculation in Spanish.
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-6263523This update fixes an error in the German localization (l10n_de) module where the title of a specific section was incorrect. Specifically, two lines related to credit notes were being reported negatively, which has now been corrected to accurately reflect revenue. This ensures accurate financial reporting for German-speaking customers.
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 addresses a potential issue where lengthy address fields during credit card payments via Authorize.net could cause errors. The system now automatically limits address field lengths to comply with the Authorize.net API, ensuring smoother payment processing. This change improves payment reliability and reduces potential disruptions for our customers.
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 corrects a visual issue in the POS control panel. Previously, a split button was always displayed, even when bill splitting was disabled within the restaurant module. This change ensures the button is only visible when bill splitting is enabled, improving the user experience and preventing unnecessary clutter.
Original PR description
The Split button in the POS control panel was rendered whenever the restaurant module was active, without checking the `iface_splitbill` config flag. opw-6248177 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267359 Forward-Port-Of: odoo/odoo#266654
This update fixes a potential 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 a smoother experience for users adding rental items to their carts. This improves reliability and prevents disruptions during the booking process.
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 resolves an issue where a confusing time slot selection popup appeared unexpectedly when using order presets in the restaurant POS. The fix ensures that the preset selection flow is properly exited after an order is merged and deleted, preventing the popup and associated errors. This improves the overall user experience for restaurant staff.
Original PR description
pos*: point_of_sale, pos_restaurant Steps to reproduce: - Configure a preset identified by name and managed by time. - Open the restaurant POS. - Create a direct order and set a tab for it. - Return to the floor screen and create another direct order. - Select the configured preset and choose the previously created order from the order name popup. Issue: - The time slot selection popup appears unexpectedly. - Selecting a time slot triggers a traceback. Cause: - When selecting an existing order, the current order is merged into the selected order. - However, the time slot selection flow remains active for the merged order, which has already been deleted. Fix: - Exit the preset selection flow when the order is merged and deleted. Task-6032880 Forward-Port-Of: odoo/odoo#268546 Forward-Port-Of: odoo/odoo#253586
A technical issue preventing users from configuring billing targets in the Timesheets app has been resolved. This fix ensures that users can correctly set billing rates for employee timesheets, improving the accuracy of billing data. The underlying cause was a missing field required by a core component of the Timesheets 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
This update ensures receipts can now be prepared and printed offline, regardless of whether the order was synced. Previously, synced orders caused errors, preventing offline receipt generation. This enhancement improves the user experience by allowing for offline operations.
Original PR description
Preparation receipts could be printed offline only if the order was not synced. If orders were synced, the `ConnectionLostError` were preventing the call to be executed. Forward-Port-Of: odoo/odoo#268570
This update corrects a technical error that prevented email notifications from being sent correctly within the planning module. The fix ensures that email actions function consistently across Odoo Enterprise, opening the standard email composer for sending messages. This resolves a minor disruption to workflow.
Original PR description
the used action name for the Send Email action was false its supposed to be action_send and not action_send_email task: 6244506
This update corrects a technical issue where archived delivery carrier records were being unintentionally passed through the system. This prevented users from selecting the correct carriers when creating orders. By ensuring only active carriers are used in the context, this fix improves order processing accuracy and reliability.
Original PR description
Issue: property_delivery_carrier_id on res.partner can hold an archived delivery.carrier record. Meaning that we pass an archived record to the context and that we can select the archievd delivery.carrier in the choose.delivery.carrier wizard. Solution: Only pass active records through the context. opw-6125792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264945 Forward-Port-Of: odoo/odoo#263819
This update resolves a previous issue that prevented users from successfully exporting records with properties from kanban and list views. Now, records containing properties can be exported to spreadsheets and exported data dialogs, ensuring a more complete and reliable data export process. This enhancement simplifies data analysis and reporting.
Original PR description
**Before this commit:** - Exporting records with properties from the kanban view caused a `Client Error`. - Inserting records with properties from the kanban view into a spreadsheet caused a `Client Error`. - Individual properties were not exported by default in list views (even when optionally displayed) or in kanban views. **After this commit:** - Records containing properties can be exported from the kanban view. - Records with properties can be inserted into a spreadsheet without errors. - Individual properties that are optionally displayed are listed by default in `Fields to Export`. enterprise: https://github.com/odoo/enterprise/pull/118913 task-6123524 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264267
This update ensures that all relevant data, including sub-properties, is now included when records are inserted into spreadsheets. This change aligns the spreadsheet export with other views (kanban, list) and improves data consistency across Odoo.
Original PR description
* = [documents_spreadsheet] Since `Insert in Spreadsheet` already supports sub-properties from saas-19.2 onwards, this change aligns the export behavior across kanban, list, and spreadsheet views by including sub-properties in the exported record data. community: https://github.com/odoo/odoo/pull/264267 task-6123524 Forward-Port-Of: odoo/enterprise#118913
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 the logging function, and this change ensures that warnings are now consistently recorded without errors.
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 issue that was causing errors in the POS HR module, specifically related to how session information was accessed. By using the standard session ID instead of a backend-calculated field, the system is now more reliable and less prone to errors. This ensures smoother operation for users.
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#266858This update resolves an issue where activity labels in the Chatter interface weren't displaying correctly when the default summary was removed. The fix ensures that activity labels now consistently use the 'display_name' when the summary is empty, providing accurate and consistent information for users. This improves the overall usability of the Chatter feature.
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
This pull request addresses a technical issue within the HR module related to how contract version overlaps were calculated. The fix ensures more accurate reporting and prevents potential errors in version management, particularly concerning employee contracts. This improves the reliability of HR data.
This update resolves an issue where the Balance Sheet report's XLSX export was incorrectly including all accounts instead of just the selected ones when using the date filter. The fix removes a filtering step that was unintentionally introduced, ensuring the report accurately reflects the user's date selection criteria.
Original PR description
Steps: - Open Balance Sheet report and unfold lines - Open the General Ledger from a line with an account - On GL report, change date filter - Export XLSX report -> We export all accounts instead of the one selected in the search bar Cause: Since f8dceec74e44ffe4aef67655be8811c96da91eba we filter out the filter if a default account is defined in the context which is the case in the `caret_option_open_general_ledger` method Fix: Remove the filtering as the behavior that was fixed by the mentioned commit does not happen anymore. opw-6234427 Forward-Port-Of: odoo/enterprise#119547 Forward-Port-Of: odoo/enterprise#119156
This update resolves a problem where users attempting to access archived documents through specific methods (like widgets or direct URLs) would incorrectly display a 'not found' message. This fix ensures that archived documents are correctly accessed, improving the user experience and preventing frustrating errors. It's a follow-up to previous related tasks.
Original PR description
When a user tries to access an archived document via * a many2one widget * `/odoo/documents.document/<id>` * a discuss notification they end up in "All" with a toast specifying that the document was not found. Follow-up of Task-6068437 (follow up of Task-5386466). Task-6214488 Forward-Port-Of: odoo/enterprise#119463 Forward-Port-Of: odoo/enterprise#117229
17 changes
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 reflects the most common reporting practice in Norway, simplifying the process for our Norwegian customers and ensuring compliance. It improves the accuracy and efficiency of financial reporting for these companies.
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
Resolved issues and error corrections
This update fixes an issue where online orders with tax included were incorrectly calculating prices. The fix ensures that the unit price and total tax-inclusive price accurately reflect the product's price with tax, resolving a discrepancy in order line calculations. This improves the accuracy of online sales transactions.
Original PR description
Steps to reproduce: --- - Configure Point of Sale with UrbanPiper credentials. - Sync a product priced at 100 with a 5% GST (tax type = Tax Included). - Place a test order. Issue: --- - Wrong calculation in order line: - unit_price: 95.24 - Tax Excl. price: 90.70 - Tax Incl. price: 95.24 - Expected: - unit_price: 100 - Tax Excl. price: 95.24 - Tax Incl. price: 100 Cause: --- - While computing the unit_price with Tax Included, the tax amount was not added back. Fix: --- - Ensure unit_price includes the tax amount when tax type is Tax Included. task-5031196 Forward-Port-Of: odoo/enterprise#119314 Forward-Port-Of: odoo/enterprise#92854
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 reporting and data display. 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
This update resolves an issue where duplicating a database would cause errors during testing of the German POS certification module. The code now safely removes identifying information (client_id and tss_id) during duplication, allowing for proper testing in neutralized database environments. This ensures consistent and reliable testing of the module.
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. This was caused by a minor oversight in how folder IDs were handled.
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 update resolves a technical error that prevented users from successfully attaching PDF invoices when using the Nilvera e-invoice system. The change ensures that the system correctly handles the raw PDF data returned by the Nilvera client, aligning with Python 3.14's stricter data validation requirements. This ensures invoices with PDFs are now processed without errors.
Original PR description
This commit resolves an error encountered when running on Python 3.14, which enforces stricter base64 validation. When adding a PDF to the invoice, the PDF is fetched using the Nilvera client. This client performs an HTTP request and returns a raw binary response, not a base64 representation. However, the Attachment interface handles raw binary data via the 'raw' field, whereas the 'datas' field strictly expects base64-encoded values. runbot-938173 Forward-Port-Of: odoo/odoo#266718
This update adjusts the sequence of the ‘Configuration’ menu item within the Contracts module. Previously, a low sequence value caused conflicts with other modules, disrupting Odoo’s standard menu organization. This change ensures the Contracts menu remains in its intended last position, maintaining a consistent and predictable user experience.
Original PR description
## Description of the issue/feature this PR addresses The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other…
## Description of the issue/feature this PR addresses The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other modules (e.g. [OCA](https://github.com/OCA/partner-contact/pull/2202/files)) add menu items in the same section. This affects not only external modules but also internal ones that add menu items under *Contacts*. ## Current behavior before PR When other modules add new menu items to *Contacts*, the *Configuration* menu moves out of its intended last position, breaking Odoo’s default menu hierarchy. <img width="467" height="148" alt="Behavior before PR:" src="https://github.com/user-attachments/assets/4cb6e3bb-00c0-4636-87de-c51b572dc42c" /> ## Desired behavior after PR is merged The sequence of the *Configuration* menu item is adjusted so that it always remains last, aligning with Odoo’s default menu hierarchy and avoiding friction between modules. <img width="467" height="148" alt="Behavior after PR is merged" src="https://github.com/user-attachments/assets/314c2556-5f2b-403d-af8d-ab550bff41a9" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234909
This update fixes an error in the German localization (l10n_de) module where the title of a section was incorrect. Specifically, two lines related to credit notes were being reported negatively, which has now been corrected to accurately reflect revenue. This ensures accurate financial reporting.
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 ensures that Cashdro payments are properly cancelled when a payment is manually 'forced' through the POS system. Previously, a forced payment would leave the Cashdro machine stuck waiting for a payment that couldn't be cancelled, causing delays. This fix prevents this issue and streamlines the payment process.
Original PR description
Since the Cashdro machine has no way for the user to cancel the payment through its interface, if a payment was forced the machine would remain waiting for a payment that could no longer be cancelled from the POS. To fix this, we now send a cancel request whenever a payment is forced. task-6276665 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268496
This update enhances the way properties are exported from records when using the spreadsheet edition. Previously, sub-properties weren't supported, but this fix ensures that all record properties are now included in the export. This change is designed to align with existing functionality in newer Odoo versions and maintain a consistent user experience.
Original PR description
* = [documents_spreadsheet] When exporting properties from records in the web kanban and list views, sub-properties created within a record were previously not supported. Support for exporting these sub-properties has now been added. However, in spreadsheet this should only be enabled from saas-19.2 onwards (where it is already available). To keep the behavior aligned with the usual flow on earlier versions, this filters out the sub-properties exported from the record in `spreadsheet_edition`. community: https://github.com/odoo/odoo/pull/264267 task-6123524 Forward-Port-Of: odoo/enterprise#118913
This update corrects a visual issue in the POS system where a split button was always displayed, even when bill splitting was disabled for a restaurant. The fix ensures the button is hidden when the restaurant module is active, aligning the user interface with the current bill splitting configuration. This improves the user experience by removing unnecessary options.
Original PR description
The Split button in the POS control panel was rendered whenever the restaurant module was active, without checking the `iface_splitbill` config flag. opw-6248177 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267359 Forward-Port-Of: odoo/odoo#266654
A technical issue preventing users from accessing billing targets within the timesheet feature has been resolved. This fix ensures a smoother workflow for employees and managers managing billable time. The change addresses a problem related to a required field within the timesheet configuration.
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
This update corrects a technical issue where archived delivery carriers were being unintentionally included in the carrier selection process. Previously, the system would pass information about inactive carriers, leading to incorrect choices in the delivery wizard. This change ensures that only active carriers are considered, improving the accuracy and reliability of delivery options.
Original PR description
Issue: property_delivery_carrier_id on res.partner can hold an archived delivery.carrier record. Meaning that we pass an archived record to the context and that we can select the archievd delivery.carrier in the choose.delivery.carrier wizard. Solution: Only pass active records through the context. opw-6125792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264945 Forward-Port-Of: odoo/odoo#263819
This update ensures receipts can now be prepared and printed offline, regardless of whether the order was synced. Previously, syncing orders caused errors, preventing offline receipt generation. This change improves the user experience by allowing for offline operations without disruption.
Original PR description
Preparation receipts could be printed offline only if the order was not synced. If orders were synced, the `ConnectionLostError` were preventing the call to be executed. Forward-Port-Of: odoo/odoo#268570
This update automatically populates expense descriptions using the names of uploaded receipts. Previously, expenses created from receipts lacked descriptions, making it difficult to track them. This change simplifies expense identification and reporting, especially when multiple receipts are uploaded.
Original PR description
When creating expenses from uploaded receipts, the generated expense description wasn't set. This made it hard to identify expenses after uploading several receipts at once. Use the uploaded document name as the default expense description instead. task-6272164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where sale order prices were incorrectly displayed in invoicing reports. The change ensures that the price shown reflects the actual price set on the sale order line, rather than the product's base price. This improves the accuracy of financial reporting and invoicing.
Original PR description
Steps to reproduce: - - Create a Sale Order with two sale order lines for the same product. - Set different prices on each SOL (e.g. 20 and 40). - Open the related project and go to the Invoicing tab. - Search for the Sale Order Lines. Issue: - Displayed price uses the product price instead of the SOL price. Cause: - The display name formatting used `product_id.lst_price`. Solution: - Use `price_unit` from the sale order line to show the correct price. task-5966799
This update fixes an issue where the ICP export generated inconsistent XML reports by pulling data from multiple company contexts. The change ensures a single, reliable company context is used, reusing precomputed values and preventing unintended overwrites. This results in more accurate and understandable ICP export data.
Original PR description
Description of the issue this commit addresses: The ICP export could mix values from different company contexts. In some cases, the main identifier and the fiscal entity division value did not come from the same source, which could create confusing or inconsistent XML output. --- Desired behavior after this commit is merged: This commit makes the ICP export use one consistent company context for identifier values, reuses precomputed values when available, and avoids overwriting them with unrelated defaults. --- task-6065382 Forward-Port-Of: odoo/enterprise#119455 Forward-Port-Of: odoo/enterprise#112995
3 changes
Resolved issues and error corrections
This update resolves an issue that prevented proper testing of the l10n_de_pos_cert module when duplicating databases. Specifically, the commit removes client and tss identifiers during duplication, allowing for seamless testing in neutralized database environments. This ensures consistent and reliable testing of the module's 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 corrects a setting that was automatically generating CFDI invoices for all orders placed through the e-commerce website. Previously, invoices weren't automatically generated for e-commerce orders, which is now the intended behavior. This change ensures that invoices are only created when a customer provides their information.
Original PR description
There is no reason why we would always cfdi to public when creating orders from the e-commerce. When the customer give all their info, the invoice should not be cfdi to public. opw-6180766 Forward-Port-Of: odoo/enterprise#119442 Forward-Port-Of: odoo/enterprise#116061
This update simplifies how spreadsheet documents are managed within Odoo, reducing unnecessary data and improving performance. By disabling versioning for spreadsheets and frozen spreadsheets, we prevent duplicate history and document creation. This change ensures a smoother and more efficient experience for users working with these file types.
Original PR description
Spreadsheet documents already manage their own history through spreadsheet revisions. Running generic Documents versioning on top of that creates unnecessary history attachments and additional documents when spreadsheet data is written or when a spreadsheet is copied. Keep the default Documents versioning behavior for regular documents, but allow spreadsheet and frozen spreadsheet documents to opt out of Documents versioning. Also hide the Manage Versions action for those records. This PR combines: * a backport of enterprise commit 0e319d063ae868d6e48e9fd6741caf5156308eae disabling Documents versioning for spreadsheets; * a follow-up change hiding the Manage Versions action for spreadsheet records. Task: 6236496 Forward-Port-Of: odoo/enterprise#118484
5 changes
New functionality added to Odoo
This update adds support for the Hacienda Foral de Navarra tax agency within Odoo's SII invoicing system. It addresses a specific requirement for explicit XML namespace declarations, ensuring correct invoice submission to the Navarra SII system. This expands Odoo's compliance with Spanish tax regulations.
Original PR description
The Hacienda Foral de Navarra uses the same SII XML format as AEAT but sends invoices to a different endpoint. Additionally, Navarra requires explicit XML namespace declarations in the SOAP envelope header, which the standard zeep serializer does not include by default. This adds the Navarra tax agency as a new option in the company SII configuration, defines its production and test endpoints, and injects the required namespaces in the request header when the Navarra agency is selected. task-5946583 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263048
Resolved issues and error corrections
This update resolves an issue that prevented Odoo from correctly duplicating databases used for testing the German POS certification module (l10n_de_pos_cert). Specifically, the system was removing key identifiers during duplication, leading to errors. This change ensures proper functionality during database duplication, improving testing and development processes.
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 resolves an issue that prevented users from successfully attaching PDF invoices when using the Nilvera e-invoicing client. The fix ensures that the system correctly handles binary PDF data, addressing a compatibility problem with Python 3.14's stricter base64 validation rules. This ensures invoices with attachments are processed correctly.
Original PR description
This commit resolves an error encountered when running on Python 3.14, which enforces stricter base64 validation. When adding a PDF to the invoice, the PDF is fetched using the Nilvera client. This client performs an HTTP request and returns a raw binary response, not a base64 representation. However, the Attachment interface handles raw binary data via the 'raw' field, whereas the 'datas' field strictly expects base64-encoded values. runbot-938173 Forward-Port-Of: odoo/odoo#266718
This update resolves a technical issue where the ‘Configuration’ menu item within the Contracts module was being incorrectly positioned due to a low sequence number. This caused conflicts with other modules and disrupted the standard Odoo menu structure. The change ensures the Contracts menu remains in its intended last position, maintaining a consistent and predictable user experience.
Original PR description
## Description of the issue/feature this PR addresses The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other…
## Description of the issue/feature this PR addresses The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other modules (e.g. [OCA](https://github.com/OCA/partner-contact/pull/2202/files)) add menu items in the same section. This affects not only external modules but also internal ones that add menu items under *Contacts*. ## Current behavior before PR When other modules add new menu items to *Contacts*, the *Configuration* menu moves out of its intended last position, breaking Odoo’s default menu hierarchy. <img width="467" height="148" alt="Behavior before PR:" src="https://github.com/user-attachments/assets/4cb6e3bb-00c0-4636-87de-c51b572dc42c" /> ## Desired behavior after PR is merged The sequence of the *Configuration* menu item is adjusted so that it always remains last, aligning with Odoo’s default menu hierarchy and avoiding friction between modules. <img width="467" height="148" alt="Behavior after PR is merged" src="https://github.com/user-attachments/assets/314c2556-5f2b-403d-af8d-ab550bff41a9" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234909
This update corrects a technical issue where archived delivery carriers were being unintentionally included in the carrier selection process. Previously, the system would pass information about inactive carriers, leading to incorrect choices in the delivery wizard. This change ensures only active carriers are considered, improving data accuracy and usability.
Original PR description
Issue: property_delivery_carrier_id on res.partner can hold an archived delivery.carrier record. Meaning that we pass an archived record to the context and that we can select the archievd delivery.carrier in the choose.delivery.carrier wizard. Solution: Only pass active records through the context. opw-6125792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264324 Forward-Port-Of: odoo/odoo#263819
3 changes
Resolved issues and error corrections
This update resolves an issue where the commission report displayed empty groups for inactive commission plans. By filtering out these plans during the report generation, the report now shows only relevant, populated data, improving the accuracy and clarity of sales performance insights. This ensures sales teams see the most up-to-date commission information.
Original PR description
Steps to reproduce: 1. create a commission plan 2. invoice an SO with the linked salesperson to the plan to progress towards the target 3. Archive the commission plan 4. Go to Sales > Commissions > Commissions 5. Remove all filters The `sale.commission.report` includes empty groups for `sale.commission.achievement.report` that are linked to inactive commission plans By excluding said plans from the initial join, the report would display populated groups only without the clutter. opw-6177132 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 DATEV exports incorrectly populated EU-specific fields for customers outside the European Union. The change ensures that the correct country information is used, aligning with DATEV's data format requirements and improving data accuracy for reporting. This ensures compliance and accurate reporting for all customers.
Original PR description
### Issue: In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled However, these fields must only be used for EU countries…
### Issue: In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled However, these fields must only be used for EU countries For non-EU countries, the `Land` field should be filled instead, and is required whenever the country is not Germany https://developer.datev.de/en/file-format/details/datev-format/format-description/debitorskreditors ### Cause: `_l10n_de_datev_get_partner_list` did not distinguish between EU and non-EU countries As a result, any partner with a VAT number could populate `EU-Land` and `EU-UStID`, even if the country was outside the EU Greece also requires a special case: its VAT prefix is `EL` so the `EU-Land` too, while the country code used in `Land` must remain `GR` ### Steps to reproduce: - Install `l10n_de_reports` and switch to the DE company - Create a customer in Switzerland with a valid VAT number - Create and confirm an invoice for that customer - Go to Accounting → Audit Reports → General Ledger - Select the full year - From the gear menu, export DATEV DATA (zip) - Open the `EXTF_customer_accounts` file ### Before the fix: `EU-Land` and `EU-UStID` are filled for the Swiss customer, while `Land` is empty ### After the fix: `EU-Land` and `EU-UStID` are empty for non-EU countries such as Switzerland, while `Land` is correctly filled `Land` is filled using the following priority: 1. Partner country_code 2. Country extracted from the VAT number 3. Empty opw-5902565 Forward-Port-Of: odoo/enterprise#113835
10 changes
New functionality added to Odoo
This update introduces a new system for employees to request approvals linked to specific templates. By adding request categories, employees can now more accurately specify the type of approval they need, streamlining the sign-off process. This improves the efficiency and clarity of approval workflows within the system.
Original PR description
adding a request category that make employee able to request a sign to a template Task: 5095647
This update adds a new option to display appointment reminders as pop-up notifications for all appointments. Previously, these notifications were only sent via email. This change enhances user convenience and ensures clients receive timely appointment reminders regardless of their preferred communication method.
Enhancements to existing features
This update aligns the default VAT reporting frequency for Norwegian businesses in Odoo Enterprise to bi-monthly (every two months). This change reflects the most common reporting practice in Norway, simplifying the process for our Norwegian customers and ensuring accurate financial reporting.
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 simplifies the selection of employee types within the Belgian payroll system. The 'Worker' employee type is now the second option after 'Employee' in the employee type list, making it easier for users to find and select. This change improves usability and streamlines the payroll process for Belgian businesses.
Original PR description
Update sequence order for employee type in Belgium, move worker as the second options after employee in Employee Type, makes users easier to find it task:6280177
Resolved issues and error corrections
This update introduces a new wizard that allows administrators to revert previously generated payslips. This provides greater flexibility in correcting payroll errors and ensures accurate record-keeping for Belgian companies using the Odoo Enterprise HR Payroll module. The change improves data accuracy and compliance.
Original PR description
Task: 6117478
This update prevents Odoo from crashing when the Barcode Lookup API returns a broken image URL. Previously, an invalid URL would cause an error. Now, the system safely ignores these errors, ensuring the 'Get Pictures from Barcode Lookup' action continues to function without interruption.
Original PR description
[FIX] product_barcodelookup: avoid crash on invalid image URLs **Steps to Reproduce:** - Install Sales module. - Configure a valid Barcode Lookup API key. - Create a product without an image. - Set a…
[FIX] product_barcodelookup: avoid crash on invalid image URLs
**Steps to Reproduce:**
- Install Sales module.
- Configure a valid Barcode Lookup API key.
- Create a product without an image.
- Set a barcode whose returned image URL is broken or returns HTTP 404
(e.g. `8426904171073`).
- Select the product and trigger the server action:
`Action -> Get Pictures from Barcode Lookup`
Issue:
**During image fetching:**
- Barcode Lookup API successfully returns product data and image URLs.
- `_get_image_from_url()` attempts to download the image.
- The image URL responds with HTTP 404.
- `barcode_lookup_request()` returns a dict for non-200 responses.
- `_get_image_from_url()` assumes the response is always a `requests.Response`
object and directly accesses: `response.status_code`
- This causes: `AttributeError: 'dict' object has no attribute 'status_code'`
**Root Cause:**
- `barcode_lookup_request()` returns inconsistent response types:
- `requests.Response` for successful requests
- `dict` for failed requests
- _get_image_from_url() does not handle the dict response before accessing
response attributes.
**Solution:**
- Make barcode_lookup_request() always return a One Response
object.
- Move the response validation to the callers instead of returning custom
dict objects.
**Result:**
- No RPC crash when image URLs are invalid or return 404.
- Broken image URLs are safely ignored.
**OPW-6200749**
Forward-Port-Of: odoo/enterprise#116925This update resolves an issue that occurred when duplicating Odoo databases used for testing the German POS certification module. Specifically, the system now correctly handles the removal of identifying information (client_id and tss_id) during database duplication, preventing errors and ensuring proper functionality in test environments. This ensures consistent and reliable testing of the module.
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 simplifies the tour selector within Web Studio. The previous logic was no longer needed due to a change in how the Kanban dropdown toggle is displayed. This adjustment ensures the tour selector functions correctly and efficiently, streamlining the user experience.
Original PR description
Since the visibility of the kanban dropdown toggle is now always visible when the media query 'pointer: fine' isn't met, in the case of this tour, it is no longer useful to check for the non visibility of the element in the selector. task-6259816
This update ensures consistent behavior across Odoo by adapting how live chat and VoIP features are initialized. The change aligns with recent community updates, streamlining the process and improving the reliability of these core services.
Original PR description
The community counterpart of this PR removed the `onStarted` method as overrides should all use `initialize`. This commit adapts the enterprise modules. community: https://github.com/odoo/odoo/pull/267160
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. This was caused by a technical oversight in updating folder references.
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
5 changes
Resolved issues and error corrections
This update resolves an issue that prevented successful testing of the l10n_de_pos_cert module when duplicating databases. Specifically, the commit removes identifying information (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 resolves a technical problem preventing the correct display of the daily report title in POS reports. The change ensures compatibility with a related reporting module and corrects a previous bug where the report would render without a title when the Colombian tax module was not enabled. This improves the user experience and report accuracy.
Original PR description
The daily report template was replacing `//h2[@id='daily_report_title']` entirely, removing the node from the XML source. This caused `pos_hr.single_employee_sales_report` (a primary template that applies its own xpaths against the same patched base) to crash at compile time since its xpaths could no longer find that node. Switch from `position="replace"` to `position="attributes"` + `position="after"`: the h2 stays in the XML source at all times so pos_hr's xpaths always resolve, while the original title is hidden at render time via t-if when CO EDI is enabled and the Colombian content is inserted as a sibling after it. As a side effect, this also fixes a pre-existing bug where installing the module with DIAN disabled would render the daily report with no title at all. opw-6265637
This update corrects a previous issue where website orders automatically generated CFDI invoices publicly. Now, invoices are only created publicly when a customer provides all necessary information through the e-commerce platform, aligning with standard business practices. This ensures compliance and avoids unnecessary public invoice disclosures.
Original PR description
There is no reason why we would always cfdi to public when creating orders from the e-commerce. When the customer give all their info, the invoice should not be cfdi to public. opw-6180766 Forward-Port-Of: odoo/enterprise#119442 Forward-Port-Of: odoo/enterprise#116061
This update resolves a technical issue that was preventing users from accessing billing targets within the Timesheets module. The fix addresses a problem caused by a missing field required by a core component of the Timesheets functionality. Enabling billing rate indicators and specific user access configurations were necessary to trigger this issue, and the update ensures a smoother workflow for managing billable time.
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
This update optimizes the way Odoo recalculates styles in large tables, like the Accounting > Balances Sheets. By removing unnecessary selectors, it reduces the time needed for these recalculations, leading to faster performance during scrolling, resizing, and sorting.
Original PR description
Adapt selector to remove the :has value since it not needed to have the effect applied. This reduces work during the "Recalculate Style" phase (for example when hovering rows in large tables such as the Accounting > Balances Sheets). It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. This commit is a follow up of https://github.com/odoo-dev/enterprise/commit/8aa63b3c726d825e68430bb0a64a54c1b58d6af7 Note: We also fixes the scss button variable not correctly overided
4 changes
Resolved issues and error corrections
This update resolves an issue that prevented PDFs from being attached to invoices when using the Nilvera e-invoicing client. The change ensures compatibility with Python 3.14's stricter base64 validation, allowing the system to correctly handle the raw PDF data.
Original PR description
This commit resolves an error encountered when running on Python 3.14, which enforces stricter base64 validation. When adding a PDF to the invoice, the PDF is fetched using the Nilvera client. This client performs an HTTP request and returns a raw binary response, not a base64 representation. However, the Attachment interface handles raw binary data via the 'raw' field, whereas the 'datas' field strictly expects base64-encoded values. runbot-938173 Forward-Port-Of: odoo/odoo#266718
This update fixes a misleading error message displayed when a shift template's start time was set after its end time. The message has been corrected to accurately state that the start time must precede the end time, improving clarity for users creating shift templates.
Original PR description
Before this commit, when the user set a start hour after end hour, the error message raised said: "The start hour cannot be before the end hour for a one-day shift template.". Which does not make sense since the start hour has to be before the end hour to be valid. This commit fixes the error message to say the start hour cannot be after the end hour.
This update prevents placeholder images from being sent during menu synchronization. Now, only the actual image URL is included when a product or category has a defined image, resulting in more efficient data transfer and a cleaner menu display. This resolves an issue where unnecessary image data was being transmitted.
Original PR description
This commit prevents placeholder images from being included in the menu sync payload and only sends `img_url` when an actual image is configured on the product or category. Task-6251430
This update fixes an issue where grouped payments were incorrectly linking older payments to new, unrelated invoices. The fix ensures that payments are accurately associated with the invoices they cover, resolving a potential reporting discrepancy. This improves the reliability of payment reconciliation.
Original PR description
Steps to reproduce --- 1. Register a grouped customer payment over several invoices, leaving one of them only partially paid. 2. Register a second grouped payment over two invoices: the partially…
Steps to reproduce --- 1. Register a grouped customer payment over several invoices, leaving one of them only partially paid. 2. Register a second grouped payment over two invoices: the partially paid one and a brand new invoice. 3. Open the first payment, its "Reconciled Invoices" smart button now lists the new invoice from the second payment, which it never paid. Issue --- The smart button is built from the stored `invoice_ids` many2many, which shares its relation table with `account.move.matched_payment_ids`. After reconciling, the register wizard links the payment to its invoices with `lines.move_id.matched_payment_ids += payment` at https://github.com/odoo/odoo/blob/f726393267a28cedd5febd2106de17ae3838f3ff/addons/account/wizard/account_payment_register.py#L1212. When the payment groups several invoices, `lines.move_id` is a multi-record recordset. Reading `matched_payment_ids` on it returns the union of the payments already linked to all those invoices, and `+=` writes that union back to every invoice as a `(6, 0, ...)` replace command. So an invoice already paid by an earlier payment spreads that earlier payment onto every other invoice grouped in the new one, including brand new invoices, which then wrongly appear on the earlier payment. opw-6188013 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
4 changes
Resolved issues and error corrections
This update resolves a test failure caused by incorrectly passing raw PDF data as base64 encoded information. The fix ensures that the correct base64 format is used, preventing errors during testing. This improves the reliability of the payroll accounting tests.
Original PR description
This commit fixes an error when running the `test_employee_job_change` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw PDF content was being passed when a base64 representation was actually expected (which is obviously invalid base64). runbot-938173
This update addresses a warning related to how Odoo uses the PyPDF library to merge pages in PDF documents. The change ensures stability and prevents potential errors by adjusting the order of operations when modifying PDF pages, improving the reliability of PDF generation.
Original PR description
In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors. This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow: 1. Add the unmodified source page directly to the `PdfFileWriter`. 2. Retrieve the newly created, writable output page. 3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page. [^1]: https://github.com/py-pdf/pypdf/pull/3638 [^2]: https://github.com/py-pdf/pypdf/pull/3669
This update fixes an issue where users without HR access rights on the timesheet grid view were seeing a placeholder image instead of their avatar. The fix ensures that all users can see their avatar in the timesheet grid, improving the user experience and visual consistency.
Original PR description
Steps to reproduce: ------------------- - Install the hr_timesheet module - Create a user without HR access rights - Create a timesheet - Log in with the above user - Open the kanban view Issue: ------- Instead of showing the employee's avatar, a placeholder image is displayed. Reason: ---------- The user does not have access to the hr.employee model. Fix: ----- In this commit, if the user does not have access to hr.employee,we fetch the image from the hr.employee.public model. task: 4461272
This update fixes a bug that occurred when adding recurring products to confirmed sales orders without a linked subscription plan. The fix prevents a traceback error by validating the subscription plan before generating recurring tasks, improving the user experience and preventing data inconsistencies.
Original PR description
Steps to reproduce: - Go to Sales → Products. - Create a Service product and enable the Recurring option. - Open an already confirmed Sales Order that does not contain any recurring products. - Add the newly created recurring product to the confirmed order. - Click Save. - Observe that a traceback occurs. Cause: - When adding a recurring product without a subscription plan to a confirmed Sale Order, _timesheet_create_task() attempts to compute a start date using order.next_invoice_date, which is not set. - This leads to a TypeError when `order.next_invoice_date` receives `False`. Solution: - Add a validation to prevent adding recurring products without a subscription plan and raise a proper `UserError` instead of allowing the code to reach task generation logic. task-5932700