Monday, June 8, 2026
34 changes · saas-19.2
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
This update enhances the way Odoo handles errors when connecting to serial devices like scales. Instead of generating excessive error logs, the system now logs warnings with detailed information, reducing unnecessary alerts and improving system performance. This change prevents overwhelming monitoring tools and ensures a smoother user experience.
Original PR description
Instead of logging an exception or an error on probe failure for serial devices, we now log a warning with stack info. This avoids spamming sentry with error logs that only are probe attempts. e.g. if the device plugged is a scale, we will probe for belgian + swedish blackbox first, causing two errors three times (as we retry 3x). see odoo/enterprise#119683
This update adjusts the certification checksum to align with recent changes to the scale driver. The goal is to maintain the integrity and accuracy of our certification process, ensuring continued compliance. This change was necessary due to a streamlining of exception handling within the scale driver.
Original PR description
As we updated the scale driver to reduce the amount of exception caught, we need to update the certification checksum. see odoo/odoo#268796
This update corrects how Italian taxes are calculated and processed during split payments. Specifically, unnecessary tax codes have been removed and the correct tax data is now used, ensuring accurate tax closing entries. This improves the reliability of Italian accounting within the Odoo system.
Original PR description
with this commit:- - Removing unnecessary 'SP Pos.' taxes. - Adopted correct tax data for 'SP' taxes so that it works correctly in Split Payment case. - By these changes, tax closing entries will become hermetic. task-6116304 Forward-Port-Of: odoo/odoo#264336
This update resolves a bug where the size of country flags on the Visitors reporting page would unexpectedly change after installing the Livechat app. Additionally, the system was incorrectly removing image sizes set in Studio, now flags correctly respond to size adjustments. This ensures consistent and accurate flag display.
Original PR description
The website.visitor.view.kanban view uses the o_country_flag class which is not defined anywhere besides livechat_channel_info_list.scss. This causes unintended behavior where the flag size for the kanban view on ' Website > Reporting > Visitors ' changes when installing the livechat app. Additionally, the image_url_field.js file does not address cases when height/width are not set. This results in the flags (or any other image using 'widget="image_url"' disappearing (being set to a 'width: 0px') whenever their Size is set via Studio. This change makes it so that the flags don't disappear when altered in Studio (but does not make them actually respond to size changes) Related tickets: opw-5962151, opw-5995004 Forward-Port-Of: odoo/odoo#251618
This update resolves an issue where the timesheet assistant wouldn't function correctly if a rule was created without a template. The fix ensures that all rules now require a template, preventing errors and improving the accuracy of timesheet display names. This enhancement ensures the timesheet assistant operates reliably.
Original PR description
## [FIX] timesheet_grid: make template field required in AW rule Before this commit, the template field in AW rule was not required and if one rule without any template is set, timesheet assistant will not be able to work correctly to build the display name for the key events found. This commit makes sure the template field is required. ## [FIX] timesheet_grid: ignore rules without template defined Before this commit, when the user creates a rule without any template set, the timesheet assistant will no longer work because it assumes the template is required. This commit adds a condition in the domain when we fetch all AW rules, to ignore the ones without template set. Forward-Port-Of: odoo/enterprise#119411
This update corrects a previous issue that limited product options when creating sale orders on mobile devices. It now allows users to add products with `sale_ok=False` and non-rental products to rental orders, expanding flexibility. This change resolves a reported regression.
Original PR description
This commit reverts 6e8a2d9c2d80044f6ee33c96871accf0aa83f4eb which introduce regression by ignoring product domain from `_domain_product_id`. Due to this issue, you can add products with `sale_ok=False` in SOL using a phone. Also you could add non-rental product in rental orders. opw-6218312 Forward-Port-Of: odoo/odoo#268331
This update resolves a technical error that prevented PDFs from being attached to invoices when using the Nilvera e-invoice system. The fix ensures that the system correctly handles the raw PDF data returned by the Nilvera client, aligning with how invoices are processed. This ensures invoices with PDF attachments are correctly generated.
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 potential issue where state deductions exceeding employee gross income could result in incorrect, negative taxable income calculations on payslips. The change ensures that taxable income defaults to zero in these scenarios, preventing misinterpretations and ensuring accurate payroll reporting. This improves the reliability of US payroll data.
Original PR description
This commit simply defaults the computed taxable income amount to 0 in case the state deductions are greater than their gross income. Otherwise our payslips would imply that these employees are owed money by the state opw-5137280 Forward-Port-Of: odoo/enterprise#104093 Forward-Port-Of: odoo/enterprise#98114