Daily updates from Odoo
Monday, June 8, 2026
51 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
This update changes the format of the DEP7 export from PDF to JSON, aligning with regulatory requirements for German tax reporting (BMF/RKSV). The new JSON format is machine-readable and optimized for compatibility with official tax tools, ensuring accurate and compliant data submissions.
Original PR description
In this commit: ------------------- - Updated the DEP7 export to generate a zip with JSON files instead of PDF, in compliance with BMF (RKSV) requirements. - The export now produces a valid JSON document containing the machine-readable data expected by the official BMF tools. - The filename format has also been adjusted to follow common conventions (e.g. `Name_Duration_DEP_KassenID.json`). Task: 6071034 Forward-Port-Of: odoo/enterprise#112276
Resolved issues and error corrections
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 partner names with '&' characters were being incorrectly formatted for SEPA bank exports, leading to file rejections. The fix ensures '&' is preserved in name and address fields, aligning with banking standards and preventing export failures. This improves data accuracy and streamlines payment processing.
Original PR description
Problem: The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name)…
Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.
As a result, a partner named "test & test GMBH" was exported as:
<Nm>test + test GMBH</Nm>
instead of the expected:
<Nm>test & test GMBH</Nm>
This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.
Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:
- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.
- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.
Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.
ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:
Forward-Port-Of: odoo/enterprise#118604
Forward-Port-Of: odoo/enterprise#115409This 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
This update fixes an issue where downpayments made in the Sale module weren't correctly reflected when processed through Point of Sale (PoS). The fix ensures that downpayments are calculated as a percentage of the remaining balance, improving the accuracy of PoS transactions. This prevents overcharging and ensures proper accounting for customer payments.
Original PR description
**Steps to reproduce:** - Make a quotation - Make a downpayment of 50% for it - Go to PoS, make a downpayment of 50% for it - It will be a downpayment for 50% of the total price, even though it should be 50% of what's left **Why the fix:** Since 2736cf99f8f5e42b294366252d903111764ec352 the amount is now calcultated with the account helpers. But the flow with a downpayment that was already added to the SO in the Sale module was not implemented, meaning the full price will be displayed in the case of a % downpayment in POS. The issue is that the price of a downpayment in the baseLines will be 0, because the qty of a downpayment is 0 in the Sale module, and it's imported as is. So we first set it to -1 to make sure we subtract the price from what's left to pay. opw-6087777 Forward-Port-Of: odoo/odoo#268235 Forward-Port-Of: odoo/odoo#259215
This update resolves an issue where kit products were incorrectly inflating inventory valuation reports. The fix ensures that kit products are accurately reflected in inventory history, preventing overestimation of total inventory value by excluding their total value calculation. This improves the accuracy of stock reporting.
Original PR description
Currently, when the user views the quantity history report, kit products are still visible, which leads to an incorrect stock valuation report. ## Steps to produce: * Install mrp_account without demo…
Currently, when the user views the quantity history report, kit products are still visible, which leads to an incorrect stock valuation report. ## Steps to produce: * Install mrp_account without demo data. * Create a product with inventory tracking enabled. * Create a BoM of type kit for that product. * Add component products with a defined cost and on-hand quantity greater than 0 to the BoM. * Recompute the kit product’s cost from its BoM on the product page. * Go to Inventory > Reporting > Stock > Inventory at date > Confirm ## Observed Behavior: Even though kits do not appear on stock valuation they still do appear the inventory history report. **Why kits should not appear on inventory history** For example, consider a kit product called 'Computer' that is composed of the following components: | Product | Quantity | Cost | |--------|--------|--------| | CPU | 1 | $300 | | Motherboard | 1 | $300 | The total cost of the Computer kit is therefore $600. Since the Computer is made up of the CPU and Motherboard, the total inventory value should be $600. However, the system is currently calculating the total inventory value at that particular date as $1,200, which is incorrect because it is counting both the kit and its components ## Root cause: This issue occurs when a user opens the inventory history for a specific date using the `Inventory at Date` option and clicks confirm. At that point, the `open_at_date` function is triggered, which filters products based on the `domain` defined in [1]. Since this domain only checks for tracking-enabled products and does not exclude kit products, kit products still appear. **Why doesn’t this issue occur in the normal stock view?** Because the domain is overridden at [2] to explicitly exclude kit products from the stock view. However, the quantity history report does not apply this same domain override, so kit products continue to appear there. [1]: https://github.com/odoo/odoo/blob/e2281b56d835d510903c6e6a6f84f67077fce99b/addons/stock/wizard/stock_quantity_history.py#L16-L38 [2]: https://github.com/odoo/odoo/blob/e2281b56d835d510903c6e6a6f84f67077fce99b/addons/mrp/views/product_views.xml#L164-L166 ## Solution: To ensure accurate total inventory valuation, kit products should be excluded from the valuation, and only their individual components should be considered. This can be achieved by modifying and overriding the domain to explicitly exclude kit products. This PR can be considered an extension of [3](https://github.com/odoo/odoo/commit/6d9c7165ec60ed0b871ac46d8d85ebbf082e8835). opw-6164547 Forward-Port-Of: odoo/odoo#262185
The configurator was incorrectly inflating the extra price of products, causing inaccurate sales order calculations. This fix prevents the configuration from repeatedly modifying the product price by cloning the relevant array, ensuring accurate price updates. This ensures correct pricing for customized products.
Original PR description
Steps to produce: --- - Install the `Sales` module, enable `Variants` in settings. - Create a product with an attribute, set the name as `Customization`, click `Create and Edit`, add value as…
Steps to produce: --- - Install the `Sales` module, enable `Variants` in settings. - Create a product with an attribute, set the name as `Customization`, click `Create and Edit`, add value as `Custom`, enable `Free Text`, set extra price to `25`, set variant creation to `Never`, and save. - Create a sales order, add the product > configurator opens. - Without saving, open and close the configurator repeatedly (using the pencil icon). Issue: --- - Product price keeps increasing on every open. Root cause: --- - After this [commit], `_getVariantPtavIds()` returns a direct reference to the live `currentIds` array. In edit mode, pushing `_getNoVariantPtavIds()` into it mutates the actual field value, so no-variant PTAV ids accumulate on every reopen, causing duplicate IDs and inflated price computation. Fix: --- - Clone the array to avoid mutating the live `currentIds`. [commit]: https://github.com/odoo/odoo/commit/bd4b6d02fed5fdc5ce628cb7d76df4cfdd2d1b3b opw-6267273 --- **Note:** Not adding a test because only tour test is possible here in this scenario with makes the execution process slow. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267991
This change reverts a recent update that was causing missing information (like order details) on the DIN 5008 delivery slip. The fix ensures the delivery slip prints correctly with all necessary data. This resolves an issue impacting multiple customers.
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
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 resolves an issue where the VAT record books generated for Spanish invoices with 'No Sujeto por reglas de localización' taxes (like PT VAT) incorrectly displayed '01' in the 'Clave de Operación' column. The fix ensures the correct '17' code is used, aligning with Spanish VAT regulations and SII reporting requirements. This improves the accuracy of VAT reporting.
Original PR description
**Steps to reproduce:** * Install the **l10n_es_edi_sii** module. * Create a **Portuguese customer**. * Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax…
**Steps to reproduce:** * Install the **l10n_es_edi_sii** module. * Create a **Portuguese customer**. * Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax mapping. * Create a customer invoice with a **"No Sujeto por reglas de localización"** tax (e.g. **23.0% PT VAT**). * Go to **Accounting → Reporting → Tax Report → OSS Sales**. * Export the **VAT Record Books (XLSX)** file and open it. **Observed behavior:** * The "Clave de Operación" column shows "01" for lines with no_sujeto_loc taxes instead of "17". * The SII JSON for the same invoice correctly shows "ClaveRegimenEspecialOTrascendencia": "17". **Cause:** * In `_l10n_es_libros_get_common_line_vals()`, `operation_code` was computed manually as `'02' if exempt_reason else '01'`, which only handled the E2 exempt case and defaulted everything else to "01". * This missed OSS/no_sujeto_loc taxes (e.g. FR VAT, PT VAT) that should produce "17" per the Spanish VAT regime code table. **Fix:** * Extract operation code computation into a new dedicated method `_l10n_es_libros_get_operation_code()`. * For customer invoices, delegate to the existing `_l10n_es_get_regime_code()` method already used by SII, which correctly returns "17" for OSS-tagged taxes, "02" for E2 exempt, and "01" otherwise. * For vendor bills, mirror the SII logic by checking whether the invoice taxes include tags from `mod_303_casilla_10_balance` or `mod_303_casilla_11_balance` (intra-community indicators), returning "09" if so and "01" otherwise. opw-6197141,6216485 Forward-Port-Of: odoo/enterprise#119467 Forward-Port-Of: odoo/enterprise#117236
This update ensures that Cashdro payments are automatically cancelled when a payment is manually 'forced' to complete. Previously, a forced payment would leave the Cashdro machine stuck waiting for a payment that could no longer be cancelled, causing delays and potential issues. This change prevents this scenario 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 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 resolves an issue preventing billing users from completing payment registrations for invoices in the Polish localization. The fix adjusts access permissions to allow standard billing users to correctly register payments and compute VAT verification information, improving the payment process for all users.
Original PR description
### Description of the issue/feature this PR addresses: This PR addresses an access control restriction where invoicing/billing users are blocked from completing payment registrations on Polish…
### Description of the issue/feature this PR addresses: This PR addresses an access control restriction where invoicing/billing users are blocked from completing payment registrations on Polish localization databases. Because the Access Control List (ACL) rule for l10n_pl.bank.account.verification was limited only to the "Show Full Accounting Features" group (account.group_account_user ), standard billing users who do not have full accounting features could not access or read verification records during payment registration. This PR modifies the read access rules to grant permissions to the Invoicing group ( account.group_account_invoice ). ### Current behavior before PR: • Users belonging only to the "Invoicing" group (without "Show Full Accounting Features" rights) receive an Access Denied error when attempting to register a payment for a confirmed invoice: │ You are not allowed to access 'PL Bank Account Verification' (l10n_pl.bank.account.verification) records. • This triggers a failure to write/compute the transient field account.payment.register.l10n_pl_bank_verification_ids during the payment wizard load, completely blocking billing users from processing payments. ### Desired behavior after PR is merged: • Standard Billing/Invoicing users ( account.group_account_invoice ) can successfully register payments for invoices. • The payment register wizard computes the l10n_pl_bank_verification_ids and displays warning banners regarding VAT verification without throwing security exceptions. • Full Accounting users ( account.group_account_user ) retain read access as they inherit all privileges from the Invoicing group. Closes #263938 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267992
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 fixes a bug that prevented payroll calculations from correctly generating worked day lines for employees using attendance-based work schedules. The change ensures that all employees, regardless of their flexible working arrangement, receive accurate wage calculations based on their attendance records. This improves payroll accuracy and reporting.
Original PR description
### **Steps to reproduce:** - Install Payroll and Attendance apps. - Create an employee with a flexible working schedule and work entry source as attendance. - Create an attendance record for this…
### **Steps to reproduce:** - Install Payroll and Attendance apps. - Create an employee with a flexible working schedule and work entry source as attendance. - Create an attendance record for this employee. - Create and compute a payslip for this employee. ### **Observed Behavior:** Worked Day lines are not generated, and Basic Wage is calculated as 0. ### **Expected Behavior:** Worked Day lines should be populated based on attendance records. ### **Root Cause:** During payslip computation, [_compute_worked_days_line_ids](https://github.com/odoo/enterprise/blob/4339010eb1e1633a67573d08e032f3922b0bec49/hr_payroll/models/hr_payslip.py#L1846) only generated work entries for versions having a `resource_calendar_id` at [1]. As a result, fully flexible employees without a working schedule were excluded from work entry generation, preventing worked day lines from being computed. [1]- https://github.com/odoo/enterprise/blob/4339010eb1e1633a67573d08e032f3922b0bec49/hr_payroll/models/hr_payslip.py#L1890-L1898 ### **Fix:** Remove the `resource_calendar_id` filter when calling `generate_work_entries` in `_compute_worked_days_line_ids` so work entries are also generated for fully flexible employees using attendance-based work entries. **opw-6146452**
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 resolves a payment issue that occurred in self-order mode within the Viva POS system. The previous change introduced an error because a required method wasn't available in self-order. This fix simply adds a fallback mechanism to ensure payments continue to process correctly.
Original PR description
The PR odoo/odoo#267280 changed the Viva class to use the `getCashier` method to determine the `cashRegisterId`, however this method does not exist in self order, so an error is always thrown. This commit fixes the issue by simply adding a `?` so that it falls back to the POS config name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268548
This update corrects an issue in the l10n_lu_reports module that caused incorrect balance sheet reports. Specifically, fields 2955 and 2956 must always be set to zero, as required by Luxembourg's eCDF reporting standards. Fixing this ensures reports are accepted by the eCDF, preventing rejection and guaranteeing accurate financial reporting.
Original PR description
Before this commit, fields 2955 and 2956 in the balance sheet could be incorrect. 2955 must always be blank (not exist) and 2956 must always be 0 per: https://ecdf-developer.b2g.etat.lu/ecdf/forms/popup/CA_PLANCOMPTA/2020/en/2/rules page 116 + 117 If they are not these values specifically, submitting the XML to eCDF results in the report being rejected. Steps to reproduce: - Install l10n_lu_reports - Create a journal entry for a closed year (2025) that debits account 142000 and credits another account that starts with a 1 - Go to the balance sheet for 2025 - Download the XML for the report - 2955 is present and 2956 is either not present or is not 0 (behavior varies between versions) Ticket [link](https://www.odoo.com/odoo/project.task/6246564) opw-6246564 Forward-Port-Of: odoo/enterprise#119193
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 IRN (Invoice Reference Number) wasn't being saved when sending invoices via e-invoicing with email in the Indian localization. The fix ensures the IRN is correctly recorded on the invoice after sending, improving compliance and reporting accuracy. This impacts users utilizing the e-invoicing feature for Indian businesses.
Original PR description
**Issue**: Sending invoice through e-invoicing with email in Indian localization will not save the IRN number on the invoice because of a cache issue on the attachment id. **Steps to reproduce**: Install l10n_in_edi_gstr module. Create an invoice and send it through e-invoicing with email option. The IRN number will not be saved on the invoice. **Causes**: When sending the invoice through e-invoicing with email option, the attachment id is not saved on the invoice before calling the method _l10n_in_edi_send_invoice(). This causes a cache issue and the IRN number is not saved on the invoice. **Fix**: Save the attachment id on the invoice after the creation of the attachement. opw-6243256 Forward-Port-Of: odoo/odoo#268595 Forward-Port-Of: odoo/odoo#268285
This update resolves an issue where applying discounts on products with different taxes caused an endless checkout reload. The fix ensures discount lines are grouped correctly, synchronizing the backend and frontend to prevent this frustrating user experience. It improves checkout stability and reliability for customers using varied product tax configurations.
Original PR description
**Step to reproduce :** 1. Create a deliverable product with a sales tax. 2. Create another product with a different sales tax. 3. Publish both products on the eCommerce website. 4. Create a discount…
**Step to reproduce :**
1. Create a deliverable product with a sales tax.
2. Create another product with a different sales tax.
3. Publish both products on the eCommerce website.
4. Create a discount program.
5. Add both products to the shopping cart.
6. Apply the discount code.
7. Proceed to checkout.
**Issue :**
Applying a discount on multiple products with different taxes causes an infinite reload cycle during checkout.
**Reason :**
The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.
https://github.com/odoo/odoo/blob/18.0/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24
After the fix introduced in:
https://github.com/odoo/odoo/pull/248215
However, when a discount is applied to products with different taxes, the corresponding reward lines are still categorized as `discounted_lines` instead of `groupable_lines`. As a result, they continue to be processed individually rather than being grouped by reward.
This leads to a mismatch between the backend, which generates one discount line per tax combination, and the frontend, which expects a single discount entry per reward. Consequently, the checkout page continuously reloads while attempting to synchronize both states.
**Solution:**
When a discount applies to products with different tax configurations, the corresponding reward lines should be included in `groupable_lines` rather than `discounted_lines`. This ensures that discount lines are grouped by
`reward_id` consistently on both the frontend and backend, preventing the checkout reload loop.
opw-6210411
Forward-Port-Of: odoo/odoo#265740This 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 fixes an issue in the Swiss payroll module (l10n_ch_hr_payroll) where the activity rate was incorrectly based on individual employee details. Now, the rate is determined by the Odoo version, ensuring accurate calculations and compliance with Swiss tax regulations. This change improves the reliability of payroll reporting.
Original PR description
…ployee Forward-Port-Of: odoo/enterprise#119658
This update strengthens security by restricting access to sensitive financial data within Odoo. Specifically, it prevents unauthorized users from viewing detailed expense information through reinvoicing and analytic distribution searches. Access to these views is now limited to users with appropriate sales, accounting, or invoicing permissions.
Original PR description
Some financial data were visible to users with no access rights through the customer to reinvoice advanced search and analytic distribution search when creating an expense. This commit ensures that these fields in customer to reinvoice advanced search are invisible if the user doesn't have sales nor accounting nor invoicing access rights, it also modifies the debit/credit/balance columns in the analytic distr bution to be visible to users with accounting or invoicing access rights only. task-5993099 Forward-Port-Of: odoo/odoo#262986
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 an issue where the ICP export generated inconsistent XML reports by potentially using values from multiple company contexts. The change ensures a single, consistent company context is used for identifier values, improving the accuracy and reliability of the reports. This resolves potential confusion and ensures compliance with Dutch tax regulations.
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#119549 Forward-Port-Of: odoo/enterprise#112995
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