Daily updates from Odoo
Wednesday, April 15, 2026
110 changes
21 changes
Resolved issues and error corrections
This update corrects a minor issue in the Batch Payment report. Previously, the report would incorrectly display placeholder values ('ABC Holder Name' and 'Demo Ref') when the Account Holder Name field was left blank. This fix ensures the report accurately reflects the payment details, providing a cleaner and more professional output for users.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113515This update resolves a test failure related to inter-company stock transfers. The test required demo data to function correctly, which is no longer needed. By removing the dependency on demo data, the test now passes consistently in a standard Odoo environment.
Original PR description
*: sale_purchase_stock_inter_company_rules ### Steps to reproduce: - Create a DB without demo data - Install stock_dropshipping, sale_purchase_stock_inter_company_rules - Run the test `test_08_dropship_inter_company_vendor_to_customer` ### Issue: The test `test_08_dropship_inter_company_vendor_to_customer` fails here: https://github.com/odoo/enterprise/blob/fd3c9d894d8821ed1d1a110cdffb5e16fb54590a/sale_purchase_stock_inter_company_rules/tests/test_inter_company_po_to_so.py#L497-L501 since the `lot_ids` are only visible for users with the `stock.group_production_lot` group: https://github.com/odoo/odoo/blob/544961c1c6db254c4292d88096bdf9363e35f0bc/addons/stock/views/stock_picking_views.xml#L310-L318 And this group is only implied with demo data: https://github.com/odoo/odoo/blob/544961c1c6db254c4292d88096bdf9363e35f0bc/addons/stock/data/stock_demo.xml#L190-L193 opw-6085811 Forward-Port-Of: odoo/enterprise#113120
This update fixes an issue where the payroll warning date incorrectly jumped to the next month when the system date was set before the closing day. The fix ensures the warning remains in the current month until the closing day has passed, improving payroll accuracy and reducing potential user confusion.
Original PR description
steps to reproduce: - install `hr_payroll` - set closing day as "5th of next month" (via schedule warning) - set system date as <5 of the month - notice that the warning date jumped to next month description: - it should stay in the current month until closing day has passed cause: - there was no check for if the closing day has passed while in the next month scenario fix: - jump to next month only if today has passed closing date. (also fixed a wrong docstring) [task#6084911](https://www.odoo.com/odoo/project/1251/tasks/6084911)
This update fixes a calculation issue related to canteen costs in the payroll module for Belgium (l10n_be_hr_payroll). Previously, the system didn't accurately calculate canteen costs when there were no recorded workdays. This change ensures that canteen costs are now correctly simulated within the payroll configuration.
Original PR description
We add simulation context in the canteen cost condition, since we dont have worked day lines in that case
This update corrects inaccurate titles and links within the Phone dashboard. The changes ensure that users are presented with the correct information and navigation, improving the overall user experience. This fix was implemented as part of a larger effort to maintain dashboard accuracy.
Original PR description
This commit fixes two titles (and links) in the Phone dashboard. Task: 6120857
This update streamlines the loading of data for self-ordering point-of-sale systems. By limiting the fields loaded, the system now performs more efficiently, reducing loading times and improving the overall user experience. This optimization enhances the speed and responsiveness of self-ordering transactions.
Original PR description
This commit optimizes pos_config and pos_session data loading by only loading the fields required for self-ordering. X-original-commit: ce78609b368e541a70c17141ee5b51543c73c1d0 Forward-Port-Of: odoo/enterprise#113661
This update resolves a technical issue that could cause errors when generating sale commission reports. The fix prevents a specific error related to date formatting, ensuring the reports run smoothly and accurately. This improves the reliability of our sales reporting functionality.
Original PR description
Before this commit, the following traceback could occurs when filtering the current period in achievements.
File "/home/arj/PycharmProjects/worktree/saas-19.1/enterprise/sale_commission/report/achievement_report.py", line 79, in _search
date_to_list = date_to_domain and [datetime.strptime(d[2], '%Y-%m-%d') for d in date_to_domain if len(d) == 3 and d[2]]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/_strptime.py", line 554, in _strptime_datetime
tt, fraction, gmtoff_fraction = _strptime(data_string, format)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/_strptime.py", line 333, in _strptime
raise ValueError("time data %r does not match format %r" %
ValueError: time data 'today' does not match format '%Y-%m-%d'
Forward-Port-Of: odoo/enterprise#112981This update simplifies the user interface by renaming the 'Audit Report' to 'Annual Report'. This change eliminates potential confusion for users regarding reporting terminology, improving clarity and ease of use. This is a routine improvement to enhance the user experience.
Original PR description
The user interface currently uses both the terms "Audit Report" and "Annual Report", which can be confusing for users. To eliminate this confusion, "Audit Report" will be renamed to "Annual Report". backport of https://github.com/odoo/enterprise/commit/c2fc5a1643f2e005007437f7ae655d2329ac49ad [feeback-6088379](https://www.odoo.com/odoo/project.task/6088379) Forward-Port-Of: odoo/enterprise#113191 Forward-Port-Of: odoo/enterprise#112989
This update resolves an issue preventing Point of Sale (PoS) users from accessing the sinvoice symbol. By adding the necessary access rights, this change ensures PoS users can utilize this important feature, improving operational efficiency. The fix was part of a larger update related to Odoo version 19.2.
Original PR description
Add access right for sinvoice symbol so that PoS user can access to it. Forward-Port-Of: odoo/odoo#259045
This update fixes a potential issue where website tours could incorrectly proceed due to a faulty check for an empty chat window. The change implements a more reliable method to confirm the chat window is truly empty before allowing the tour to continue, ensuring a smoother user experience.
Original PR description
The previous negative assertion could pass prematurely during fast tour execution. Switching to a specific text based assertion ensures the step only proceeds once the empty conversation is explicitly confirmed. Forward-Port-Of: odoo/odoo#258921
This update fixes an issue where icons were removed when creating links from selections within the HTML editor. The change ensures icons are treated like images during link creation, maintaining their appearance in the final output. This improves the user experience and consistency of links.
Original PR description
Problem: When a selection contains both text and an icon, creating a link removes the icon from the content. Cause: Icons should be treated the same way as images during link creation. If an icon is present in the selection but not handled like an image, it gets removed when the link is applied. Solution: Handle icons in the same way as images when processing selections for link creation, ensuring they are preserved. Steps to reproduce: - Add text "abc" followed by an icon. - Select both the text and the icon. - Create a link. - Observe that the icon is removed and only the text remains. opw-6066195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256631 Forward-Port-Of: odoo/odoo#256002
This update fixes a visual issue on the self-order combo screen where product images were distorted. We've adjusted the image styling to ensure all images, regardless of their aspect ratio, display correctly and consistently. This improves the user experience and presentation of products on this screen.
Original PR description
Before this commit, the product image shown in the header of the combo screen in the self order interface was squished to fit the container, resulting in distortion for non-square images. After this commit, we add the `object-fit: cover` style to match the how the images are displayed elsewhere in self order. Before the change: <img width="595" height="536" alt="image" src="https://github.com/user-attachments/assets/fb90167c-8c28-46c9-9ab5-3ac472299c67" /> After the change: <img width="597" height="538" alt="image" src="https://github.com/user-attachments/assets/44d5c5a6-037b-46e2-8a28-5ef9df4d5e58" /> Product screen for reference (no change): <img width="561" height="143" alt="image" src="https://github.com/user-attachments/assets/4ee20d8c-9cde-4cc8-bcf1-8179f878a517" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257489
This update resolves a validation error that occurred when the partner autocomplete feature attempted to use incorrectly formatted VAT numbers. The fix automatically ignores invalid VAT values returned during autocomplete, ensuring data integrity and a smoother user experience. This change requires the `base_vat` module to be installed.
Original PR description
### Issue: When autocompleting some partners, the returned VAT could be in an invalid format, leading to a validation error You need `base_vat` installed to get the issue ### Cause: The partner autocomplete feature relies on IAP credits for full data retrieval When no credits are available, only the VAT is returned if it was already fetched before In some cases, this VAT value is incorrectly formatted, which triggers a validation error when applied to the partner ### Fix: Invalid VAT values returned by the autocomplete are now ignored to prevent errors Since the correct VAT cannot be retrieved without IAP credits, the value is simply removed ### Steps to reproduce: - Install `l10n_cy` (we need a localization to enable base_vat) - Create a new partner from an invoice - Enter TONYO 360 and select the autocomplete suggestion Before the fix: The VAT field is filled with an invalid value, causing a validation error opw-6030164 Forward-Port-Of: odoo/odoo#255476
This update resolves an issue where uploading an empty PDF file caused a system crash. The fix adds a validation check to ensure uploaded file content is valid, preventing TypeErrors and ensuring stable operation when users attempt to upload invalid files.
Original PR description
Issue: - Uploading an empty PDF triggered a stack trace. - The uploaded file content sometimes returned False instead of bytes. - Passing this value to io.BytesIO() raised a TypeError. Fix: - Added a check to ensure the content is valid. Impact: - Prevents crashes when users upload empty or invalid PDF files. TaskID-6004471 Forward-Port-Of: odoo/odoo#252208
This update resolves an issue where the Sales/Purchase Tax Report was displaying incorrect, doubled amounts for import VAT taxes. The fix eliminates redundant tax tag definitions, ensuring accurate reporting of untaxed and VAT amounts for imported goods. This improves the reliability of financial reporting.
Original PR description
The Sales/Purchase Tax Report showed doubled untaxed amounts and VAT amounts for bills using import VAT group taxes (e.g. "Imported VAT 10%").
The root cause: the Form 01/GTGT report (line C.I.1 "Purchased Goods and Services") defined its own tax_tags expressions for import VAT tags (e.g. tax_purchase_import_10_base), while the child line C.I.a ("Including: imported Goods and Services") referenced the exact same tags. This created two rows per import VAT tag in account_report_expression.
Fix: remove the redundant tag expressions from line C.I.1 and replace them with aggregation references to C.I.a (23a24a.amount_untaxed and 23a24a.balance). Each import VAT tag now has exactly one expression, so the JOIN produces one row per line, so no more doubling.
task-6083697This update fixes a problem where multiple email aliases could lead to duplicate records being created when emails were processed concurrently. The change uses a locking mechanism to ensure that only one record is created for each email, regardless of how many aliases receive it. This improves data accuracy and reliability.
Original PR description
Concurrent processing of emails with the same `Message-Id` can create duplicate records. ### Steps to reproduce 1. Configure multiple mail aliases (e.g., two helpdesk teams). 2. Send one email with…
Concurrent processing of emails with the same `Message-Id` can create duplicate records. ### Steps to reproduce 1. Configure multiple mail aliases (e.g., two helpdesk teams). 2. Send one email with both aliases as recipient. The Mail Transfer Agent may invoke `odoo-mailgate.py` once per recipient, resulting in concurrent processing of the same email in separate transactions. We expect one record per alias/team, but duplicates may be created. ### Cause This is a race condition in the `Message-Id` deduplication logic, caused by concurrent transactions and PostgreSQL snapshot isolation. Odoo uses the `REPEATABLE READ` isolation level. This means that each transaction takes a snapshot of the database at its first query and cannot see changes committed by other concurrent transactions. When two concurrent transactions process the same email: 1. Both enter `message_process` and take their snapshot. 2. Both search for the `Message-Id`. Because their snapshots don't include each other's work, both find nothing. 3. Both create records. Even if one transaction commits before the other performs the check, the second transaction still uses its original stale snapshot and create duplicates. ### Fix After the initial duplicate check, attempt to acquire a transactional advisory lock on a hash of the `Message-Id` using `pg_try_advisory_xact_lock`. If another transaction is already processing the same email and holds the lock, the call returns false and the email is treated as a duplicate. If the lock is acquired, processing continues as normal. opw-5116492 Forward-Port-Of: odoo/odoo#258847 Forward-Port-Of: odoo/odoo#250027
This update ensures that attachments uploaded to cloud storage retain their original file type. Previously, the system was incorrectly guessing file types, which could lead to issues with how files were handled. This fix improves the reliability of cloud storage uploads and prevents potential data inconsistencies.
Original PR description
When uploading an attachment to cloud storage via `_post_add_create(cloud_storage=True)`, the attachment's original `mimetype` is guessed even if we specify it. With this commit we explicitly preserve given mimetype Discovered during task-5153790 Forward-Port-Of: odoo/odoo#258251 Forward-Port-Of: odoo/odoo#257979
This update fixes an issue where the color picker preview didn't accurately reflect gradient backgrounds applied to the header theme. The fix ensures the preview correctly displays gradient styles by utilizing CSS variables, addressing a discrepancy between the targeted editing element and the actual applied styles.
Original PR description
### Issue: Color picker preview not showing correctly when a theme with a gradient background is applied to the header. ### Steps to reproduce: 1. Go to the Theme tab and open the color presets…
### Issue: Color picker preview not showing correctly when a theme with a gradient background is applied to the header. ### Steps to reproduce: 1. Go to the Theme tab and open the color presets dropdown. 2. Select any preset and set its background to a gradient. 3. Apply this theme to the header. ### Reason: - The color picker preview relies on `getComputedStyle` of the current editing element to determine what background to show. - For the header, the targeted editing element is `#wrapwrap > header`, but the actual gradient styles are applied to its inner `<nav>` elements (e.g., via `customizeWebsiteColorAction`). - Since the `background-image` property is never applied directly to the header element itself, computing its style does not capture the gradient defined on its inner elements, resulting in an incorrect or missing preview. ### Fix: - Avoid depending strictly on the computed style of the main editing element for generating the preview. - Ensure the preview accurately reflects the applied styles by utilizing CSS variables, even when certain builder actions apply those styles to inner elements rather than the primary targeted element, as demonstrated in the header example with `customizeWebsiteColorAction`. task-[6075788](https://www.odoo.com/odoo/project/974/tasks/6075788) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256566
This update corrects how image sizes are displayed in the website builder, specifically addressing issues with CORS-protected images. It now accurately reflects the actual image size and prevents incorrect size displays when images are blocked due to CORS restrictions. This ensures consistent image handling across the platform.
Original PR description
[FIX] html_builder, *: hide the size of CORS-protected images *: html_editor Steps to reproduce: - Add an image on the website. - Replace it with a CORS-protected image. -> The image options display…
[FIX] html_builder, *: hide the size of CORS-protected images *: html_editor Steps to reproduce: - Add an image on the website. - Replace it with a CORS-protected image. -> The image options display a size, but it is incorrect. The problem is that it is not the real size of the image but the size of a default image (due to it, if you replace the image by another CORS protected one, you'll see that the size of the image remains the same). Indeed, the size of an image (in bytes) is computed from the length of the raw b64 content of the image, on which a ratio of 3/4 is applied. Because the image is CORS protected, we can not retrieve the raw b64 of the image so the image size should not be displayed. This commit hides the size of CORS protected image as it is impossible to retrieve. Note: example of a CORS protected image: https://tinyjpg.com/images/social/website.jpg task-5405262 --------------------------------------------------------------------------------------------------------------------------------------------- [FIX] html_builder, *: correctly determine image mimetype *: html_editor The goal of this commit is to improve the way the mimetype of an image is determined if the information is not in the DOM. Before this commit, the system relied on the extension of the image source to determine its mimetype. This is not really robust and it is easily trickable. For example, in `html_editor`, if an image in a html field comes from an attachment, its `src` attribute will end by the attachment name. If a user changes the attachment name extension, the next time the image is added on the DOM, the extension is changed but the mimetype of the image is unchanged. To solve the problem, the mimetype of the image is determined thanks to the headers of the http request to the `src` of the image. That way, the information comes from the server hosting the image. task-5405262 --------------------------------------------------------------------------------------------------------------------------------------------- [FIX] html_builder, website: enable the quality change on shaped img This commit improves [this one] by adding a test (this commit was created before [this one] was merged). [this one]: https://github.com/odoo/odoo/commit/738d5fb5ae2154e1f6993817fab5471d2d4384fa task-5405262 --------------------------------------------------------------------------------------------------------------------------------------------- [FIX] html_builder, *: hide shape option for CORS-protected images *: website Steps to reproduce the problem: - Add an image on the page. - Replace the image by a CORS protected one. - Try to apply a shape on the image. -> Traceback The goal of this commit is to hide the "Shape" option if the "original image" of an image is not retrievable. Indeed, in this case, the option will fail to apply correctly. task-5405262 --------------------------------------------------------------------------------------------------------------------------------------------- [FIX] html_builder, *: avoid displaying options that are not compatible *: html_editor, website Few options like filter, quality, format and cropping rely on canvas to work. The problem is that it does not work correctly for mimetypes like `svg` or `gif`. Indeed, if an image modification is done on such images, it will automatically be transformed into a `png` by default. To avoid it, this commit hides the options that rely on a canvas manipulation when clicking on a `svg` or `gif` image. The process image function has also been adapted to not try to transform an image if its mimetype is not compatible with a canvas transformation. Instead, those images are directly transformed into `b64` images without any transformation. Thanks to it, a shape can be applied on a `svg` or a `gif`. task-5405262 --------------------------------------------------------------------------------------------------------------------------------------------- [FIX] html_builder, *: apply shape on replaced svg and gif images *: website Steps to reproduce the problem: - Add a "Text-Image" snippet on the page and add a shape on the image. - Replace the image by a svg or a gif. -> A shape is displayed on the image options but the shape is not applied on the image. task-5405262 --------------------------------------------------------------------------------------------------------------------------------------------- [FIX] html_builder, *: avoid copying options on new incompatible images *: html_editor, website Steps to reproduce: - Add an image on the website. - Add a shape on the image. - Replace the image by a CORS-protected one. -> The image still has the shape data attributes on its HTML element while it should not as it does not have the prerequisites to have a shape (it does not have an original source). The same problem exists with the hover effect. This commit moves the logic that transfers the shape and hover effect on replaced images from `html_editor` to the responsible plugins in `html_builder` and `website`. It also adds a check to verify that the replaced image is eligible to have a particular option before transferring its data information. task-5405262 Forward-Port-Of: odoo/odoo#259032 Forward-Port-Of: odoo/odoo#251703
This update streamlines the loading of data for the self-ordering point-of-sale system. By only retrieving the necessary information, we've reduced the system's load and improved its responsiveness. This results in a smoother and faster experience for users placing self-orders.
Original PR description
This commit optimizes pos_config and pos_session data loading by only loading the fields required for self-ordering. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258744 Forward-Port-Of: odoo/odoo#257865
A previous error caused a blank page when users clicked the 'Check the sample button' in the sales module. This was due to a change in the link to the sample quotation PDF. This update provides a working link, resolving the issue and ensuring users can access the sample.
Original PR description
Currently, a 404 error is occurring when the user clicks on the Check the sample button. **Steps to produce:** - Install sales module without demo data. - Click on the check a sample. its clean! button. **Issue:** - A 404 error occurs with a blank page. **Cause:** - This issue is occurring because the link to open the sample quotation pdf was changed in the Odoo documentation. **Solution:** - Give a valid link to open the sample quotation pdf. - similar fix already did [here1] & [here2]. [here1]: https://github.com/odoo/odoo/commit/38431f3aef57c5b91644b4c5241f226beb917b12 [here2]: https://github.com/odoo/odoo/commit/610cea89c37454a4ddb68939333b4b363f2f81a2 opw-6099641 opw-6074953 Forward-Port-Of: odoo/odoo#259150 Forward-Port-Of: odoo/odoo#258003
21 changes
Resolved issues and error corrections
This update corrects a minor issue in the Batch Payment report. Previously, the report would incorrectly display placeholder text ('ABC Holder Name' and 'Demo Ref') when the Account Holder Name field was left blank. This change ensures the report accurately reflects the payment details, providing a cleaner and more professional output.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113515A recent change in the sign request process caused a technical error that prevented users from accessing sign requests. This fix ensures that the system correctly checks for the existence of sign items before attempting to compare their types, resolving the underlying issue. This improves the reliability of the sign request functionality.
Original PR description
This issue occurs because, in the recent [commit], `sign_request` was changed to `sign_item`, but the `sign_item.exists()` check is performed after the type comparison, resulting in a `TypeError`.…
This issue occurs because, in the recent [commit], `sign_request` was changed to `sign_item`, but the `sign_item.exists()` check is performed after the type comparison, resulting in a `TypeError`.
Traceback:
```py
File "/home/odoo/src/odoo/saas-19.2/odoo/addons/base/models/ir_http.py", line 415, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/saas-19.2/odoo/http/routing_map.py", line 207, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/enterprise/saas-19.2/sign/controllers/main.py", line 708, in get_sign_request_items
if not sign_request.exists() or not consteq(sign_item.access_token, token) or not sign_item.exists() or not sign_item.signer_email:
TypeError: unsupported operand types(s) or combination of types: 'bool' and 'str'
```
Solution:
We first perform the existence check and then compare the types.
[commit]: https://github.com/odoo/enterprise/pull/111786/changes/f40082f4e6f50dccbfa639edbef08428868cb31d
sentry-7376866293
Forward-Port-Of: odoo/enterprise#112659This update resolves a test failure related to inter-company stock transfers. The test required demo data to function correctly, which is no longer present. This change ensures the test runs reliably in a production environment without relying on the demo database.
Original PR description
*: sale_purchase_stock_inter_company_rules ### Steps to reproduce: - Create a DB without demo data - Install stock_dropshipping, sale_purchase_stock_inter_company_rules - Run the test `test_08_dropship_inter_company_vendor_to_customer` ### Issue: The test `test_08_dropship_inter_company_vendor_to_customer` fails here: https://github.com/odoo/enterprise/blob/fd3c9d894d8821ed1d1a110cdffb5e16fb54590a/sale_purchase_stock_inter_company_rules/tests/test_inter_company_po_to_so.py#L497-L501 since the `lot_ids` are only visible for users with the `stock.group_production_lot` group: https://github.com/odoo/odoo/blob/544961c1c6db254c4292d88096bdf9363e35f0bc/addons/stock/views/stock_picking_views.xml#L310-L318 And this group is only implied with demo data: https://github.com/odoo/odoo/blob/544961c1c6db254c4292d88096bdf9363e35f0bc/addons/stock/data/stock_demo.xml#L190-L193 opw-6085811 Forward-Port-Of: odoo/enterprise#113120
This update simplifies the user interface by standardizing the term 'Audit Report' to 'Annual Report'. Previously, the inconsistent use of both terms created confusion for users. This change improves clarity and ease of use within the accounting module.
Original PR description
The user interface currently uses both the terms "Audit Report" and "Annual Report", which can be confusing for users. To eliminate this confusion, "Audit Report" will be renamed to "Annual Report". backport of https://github.com/odoo/enterprise/commit/c2fc5a1643f2e005007437f7ae655d2329ac49ad [feeback-6088379](https://www.odoo.com/odoo/project.task/6088379) Forward-Port-Of: odoo/enterprise#112989
This update fixes an issue where subscription invoices were being incorrectly set to a future date due to upsell orders. The change prevents the calculation from considering upsell order lines, ensuring accurate and timely invoice generation. This improves billing accuracy and reduces potential invoicing delays.
Original PR description
When we compute the next invoice date of a subscription, we are checking all account move lines of the invoices linked to the subscription. But if we have an upsell with a deffered date higher than the next invoice date that should be calculated, it will set a too high next invoice date. To avoid this issue, we don't take into account the invoice lines linked to upsell to compute the next invoice date
This update resolves an issue preventing Point of Sale (PoS) users from accessing the ‘sinvoice’ symbol within the Odoo system. By granting the necessary access rights, this change ensures PoS users can utilize this feature, improving operational efficiency. This fix was implemented as part of a larger effort to enhance functionality for retail operations.
Original PR description
Add access right for sinvoice symbol so that PoS user can access to it. Forward-Port-Of: odoo/odoo#259045
This update resolves a visual bug where the HTML editor incorrectly applied a gradient background when using solid text colors. The fix ensures that gradients are properly removed regardless of how the text color is applied (inline style or class), resulting in consistent and accurate text display.
Original PR description
Steps to reproduce: - Go to a To-do note - Select a word - Apply a gradient as the text color - Re-open the color picker - From the Solid tab, select the primary color (o-color-1) Description of the issue: - The gradient is not removed and ends up being displayed as a background color Cause: - In the `colorElement` method, the gradient is removed when applying a text color via inline styles. However, when applying a color via class (e.g., text-*), the gradient is not properly cleared. Only the text-gradient class is replaced, while the gradient style remains, causing it to appear as a background color. Solution: Ensure the gradient is removed in both cases: - when applying a color via class and when applying a color via inline styles in `colorElement`. task-6045533 Forward-Port-Of: odoo/odoo#257045 Forward-Port-Of: odoo/odoo#254654
This update fixes a potential issue where website tours could incorrectly proceed if the chat feature was temporarily empty. The change implements a more reliable check to ensure the chat is truly empty before the tour continues, enhancing the overall user experience. This ensures tours run smoothly and consistently.
Original PR description
The previous negative assertion could pass prematurely during fast tour execution. Switching to a specific text based assertion ensures the step only proceeds once the empty conversation is explicitly confirmed. Forward-Port-Of: odoo/odoo#258921
This update fixes an issue where icons were removed when creating links from selections within the HTML editor. The change ensures icons are treated like images during link creation, maintaining their appearance in the final linked content. This improves the user experience and consistency of the HTML editor.
Original PR description
Problem: When a selection contains both text and an icon, creating a link removes the icon from the content. Cause: Icons should be treated the same way as images during link creation. If an icon is present in the selection but not handled like an image, it gets removed when the link is applied. Solution: Handle icons in the same way as images when processing selections for link creation, ensuring they are preserved. Steps to reproduce: - Add text "abc" followed by an icon. - Select both the text and the icon. - Create a link. - Observe that the icon is removed and only the text remains. opw-6066195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256631 Forward-Port-Of: odoo/odoo#256002
This update fixes an issue where employees with past department assignments were incorrectly appearing in holiday reports. The change now only considers current department assignments, ensuring more accurate reporting of employee holiday availability. This improves the reliability of time-off data.
Original PR description
Reproduce the issue: - Create an employee linked to a user with department A - Create a second employee with 2 versions: - a past one with department A - a current one with department B - create a leave for both employees - go to Time Off > Overview, keep the group by employee and select the filter "My department" - both employee appear Before this commit, the search on "member_of_department" was looking for all versions with a similar department (same or child of) regardless of the version validity. This commit limits that search to current versions only task-6076014
This update fixes a visual issue on the self-order combo screen where product images were being distorted. We've adjusted the image styling to ensure all images, regardless of their aspect ratio, display correctly and consistently. This improves the overall user experience and presentation of products on this screen.
Original PR description
Before this commit, the product image shown in the header of the combo screen in the self order interface was squished to fit the container, resulting in distortion for non-square images. After this commit, we add the `object-fit: cover` style to match the how the images are displayed elsewhere in self order. Before the change: <img width="595" height="536" alt="image" src="https://github.com/user-attachments/assets/fb90167c-8c28-46c9-9ab5-3ac472299c67" /> After the change: <img width="597" height="538" alt="image" src="https://github.com/user-attachments/assets/44d5c5a6-037b-46e2-8a28-5ef9df4d5e58" /> Product screen for reference (no change): <img width="561" height="143" alt="image" src="https://github.com/user-attachments/assets/4ee20d8c-9cde-4cc8-bcf1-8179f878a517" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257489
This update resolves a validation error that occurred when the partner autocomplete feature attempted to use incorrectly formatted VAT numbers. The fix automatically ignores invalid VAT data returned during autocomplete, ensuring a smoother user experience. This change requires the `base_vat` module to be installed.
Original PR description
### Issue: When autocompleting some partners, the returned VAT could be in an invalid format, leading to a validation error You need `base_vat` installed to get the issue ### Cause: The partner autocomplete feature relies on IAP credits for full data retrieval When no credits are available, only the VAT is returned if it was already fetched before In some cases, this VAT value is incorrectly formatted, which triggers a validation error when applied to the partner ### Fix: Invalid VAT values returned by the autocomplete are now ignored to prevent errors Since the correct VAT cannot be retrieved without IAP credits, the value is simply removed ### Steps to reproduce: - Install `l10n_cy` (we need a localization to enable base_vat) - Create a new partner from an invoice - Enter TONYO 360 and select the autocomplete suggestion Before the fix: The VAT field is filled with an invalid value, causing a validation error opw-6030164 Forward-Port-Of: odoo/odoo#255476
The color picker preview was previously inaccurate when applying gradient backgrounds to header themes. This update fixes a technical issue where the preview didn't reflect the actual gradient styles, ensuring a correct preview for all theme options.
Original PR description
### Issue: Color picker preview not showing correctly when a theme with a gradient background is applied to the header. ### Steps to reproduce: 1. Go to the Theme tab and open the color presets…
### Issue: Color picker preview not showing correctly when a theme with a gradient background is applied to the header. ### Steps to reproduce: 1. Go to the Theme tab and open the color presets dropdown. 2. Select any preset and set its background to a gradient. 3. Apply this theme to the header. ### Reason: - The color picker preview relies on `getComputedStyle` of the current editing element to determine what background to show. - For the header, the targeted editing element is `#wrapwrap > header`, but the actual gradient styles are applied to its inner `<nav>` elements (e.g., via `customizeWebsiteColorAction`). - Since the `background-image` property is never applied directly to the header element itself, computing its style does not capture the gradient defined on its inner elements, resulting in an incorrect or missing preview. ### Fix: - Avoid depending strictly on the computed style of the main editing element for generating the preview. - Ensure the preview accurately reflects the applied styles by utilizing CSS variables, even when certain builder actions apply those styles to inner elements rather than the primary targeted element, as demonstrated in the header example with `customizeWebsiteColorAction`. task-[6075788](https://www.odoo.com/odoo/project/974/tasks/6075788) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256566
This update fixes an issue where the 'Back to edit mode' link in the land portal invoice was incorrectly directing users to the wrong app (like Website). Switching to the correct Invoicing app ensures users always access the intended invoice editing functionality. This improves the user experience and prevents errors.
Original PR description
The "Back to edit mode" link used action_move_out_invoice_type, which isn't bound to any menu, so the backend fell back to whichever app happened to match (e.g. Website when installed) instead of Invoicing. Switch to action_move_out_invoice (the one referenced by the Invoicing menu) so the webclient resolves the correct app automatically. task-5882256 Forward-Port-Of: odoo/odoo#257841
This update resolves an issue where uploading an empty PDF file caused a crash in the accounting module. The fix adds a validation check to ensure uploaded file content is valid, preventing errors and improving system stability. This ensures users can consistently upload documents without experiencing unexpected application failures.
Original PR description
Issue: - Uploading an empty PDF triggered a stack trace. - The uploaded file content sometimes returned False instead of bytes. - Passing this value to io.BytesIO() raised a TypeError. Fix: - Added a check to ensure the content is valid. Impact: - Prevents crashes when users upload empty or invalid PDF files. TaskID-6004471 Forward-Port-Of: odoo/odoo#252208
This update fixes an issue where dropdown menus in the Odoo interface appeared cramped due to missing vertical spacing. The change restores natural spacing by adjusting margins on the menu items, ensuring a cleaner and more user-friendly experience. This improves the visual consistency of the application.
Original PR description
Recent structural changes added `p-0` to the menu class, removing the vertical padding from the dropdown. Rather than padding the scroll container directly (which would conflict with sticky group headers), apply `margin-top/bottom` on the first/last children of `.o_select_menu-choices` so the spacing scrolls naturally without creating a gap items could bleed through when a group header is stuck. task-6095912
This update ensures that negative discount values are consistently displayed in both the Sale Order preview (portal view) and the generated PDF reports. Previously, the PDF displayed negative discounts while the portal preview did not, creating a discrepancy. This fix aligns the reporting output for a more accurate representation of sales data.
Original PR description
Steps to produce: --- - Install the `Sales` module. - Enable discounts from settings. - Create a Sale Order with a negative discount on an order line. - Preview the Sale Order and click on the view…
Steps to produce: --- - Install the `Sales` module. - Enable discounts from settings. - Create a Sale Order with a negative discount on an order line. - Preview the Sale Order and click on the view details button. Issue: --- - Negative discount values are not shown in the preview (portal view), but they are displayed in the generated PDF. Root cause: --- - At [1], the portal template includes a condition to display discounts only when they are greater than 0, while the report templates lack this check, leading to inconsistent behavior. Solution: --- - Applied the same condition in the report templates to align the PDF output with the portal preview behavior. Before: --- <img width="787" height="136" alt="image" src="https://github.com/user-attachments/assets/d32311be-4aec-4d6f-b905-d5e52f712ba4" /> After: --- <img width="775" height="139" alt="image" src="https://github.com/user-attachments/assets/2614a8ad-dca6-49ca-b720-5c234aa91cf6" /> [1]https://github.com/odoo/odoo/blob/0f463fd247d2f5da79d6ec2b6bec18774f6f600b/addons/sale/views/sale_portal_templates.xml#L539 Enterprise PR: https://github.com/odoo/enterprise/pull/111916 opw-6061568 Forward-Port-Of: odoo/odoo#258981 Forward-Port-Of: odoo/odoo#255735
This update streamlines the color picker interface for website design options like icons, snippets, and scroll buttons. Previously, irrelevant tabs were displayed, but now the color picker only shows options directly related to each design choice, creating a cleaner and more intuitive user experience.
Original PR description
This commit ensures the correct tabs are displayed in the color picker for Icon, Snippet Tabs and Scroll Button options. The Theme tab was previously shown for these options, although it was not relevant in this context. The color picker now only displays the tabs that make sense for each option. 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#258954 Forward-Port-Of: odoo/odoo#249419
A previous error caused a blank page when users clicked the 'Check the sample button' in the sales module. This was due to a change in the link to the sample quotation PDF. This update provides a valid link, resolving the issue and ensuring users can access the sample.
Original PR description
Currently, a 404 error is occurring when the user clicks on the Check the sample button. **Steps to produce:** - Install sales module without demo data. - Click on the check a sample. its clean! button. **Issue:** - A 404 error occurs with a blank page. **Cause:** - This issue is occurring because the link to open the sample quotation pdf was changed in the Odoo documentation. **Solution:** - Give a valid link to open the sample quotation pdf. - similar fix already did [here1] & [here2]. [here1]: https://github.com/odoo/odoo/commit/38431f3aef57c5b91644b4c5241f226beb917b12 [here2]: https://github.com/odoo/odoo/commit/610cea89c37454a4ddb68939333b4b363f2f81a2 opw-6099641 opw-6074953 Forward-Port-Of: odoo/odoo#259150 Forward-Port-Of: odoo/odoo#258003
This update resolves an issue where product images weren't consistently being removed from the website. The fix ensures the image is fully loaded in the browser before the removal button can be clicked, improving the user experience. This prevents potential display glitches related to product images.
Original PR description
With this commit, we fix tours: - website_sale.remove_main_product_image_with_variant - website_sale.add_and_remove_main_product_image_no_variant where we want to remove the product image. This fix add a step to ensure the image is in DOM before clicking on the remove button. error-runbot-id~237766 Forward-Port-Of: odoo/odoo#252810 Forward-Port-Of: odoo/odoo#244544
This update fixes an issue where task history dates were incorrectly displayed due to timezone differences. Previously, the date shown in the history dialog was shifted based on the user's local time, leading to inaccurate revisions. Now, task dates are consistently displayed in UTC, ensuring accurate tracking of changes.
Original PR description
Description of the issue/feature this PR addresses: The record's `create_date` from `orm.read` is a naive datetime string in UTC, but `DateTime.fromFormat` without a zone option interprets it in the browser's local timezone. This causes the initial revision's date to be shifted by the user's UTC offset in the history dialog. Current behavior before PR: 1) Create a task 2) Change/Add description in it 3) Check the version history 4) the task is having wrong date/date & time in the 1st revision (in my case -5:30 hours) <img width="749" height="515" alt="image" src="https://github.com/user-attachments/assets/e9480570-7458-4e0a-9bba-6514d6b1aacf" /> Desired behavior after PR is merged: <img width="751" height="483" alt="image" src="https://github.com/user-attachments/assets/ff9d1c95-fc8e-40bb-8cf8-bab39c9cd59b" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256653
4 changes
Resolved issues and error corrections
This update corrects a minor issue in the Batch Payment reports. Previously, the report would incorrectly display default 'demo' values (like 'ABC Holder Name') when a customer's name wasn't provided. Now, the report correctly leaves these fields blank, ensuring accurate and professional-looking payment documents.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113515This update corrects a discrepancy in the sale and purchase journal dashboards. Previously, receipt data wasn't included, leading to inaccurate counts. Now, receipts are incorporated, ensuring dashboard metrics align with actual sales and purchase records for a more reliable view of business activity.
Original PR description
- The sale and purchase journal dashboards excluded receipts while the action view included them, causing a mismatch between counts and displayed records. Include receipts in the dashboard query to ensure consistency. Related PR:https://github.com/odoo/odoo/pull/254295 taskID-6040828 Forward-Port-Of: odoo/enterprise#111142
This update fixes a previous error that prevented invoice settlement when the associated customer information wasn't fully loaded. The change streamlines the process by directly using the customer's ID, ensuring smoother invoice processing and preventing disruptions to the payment workflow. This improves reliability and efficiency.
Original PR description
Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice. This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID. opw-6023150 Forward-Port-Of: odoo/enterprise#111957
This update resolves an issue where the 'Create a Payslip' button was unresponsive when no payslips existed in the W2 report. The fix corrects a technical error in the system's data handling, ensuring the button now functions as intended and allows users to create new payslips when needed. This improves the usability of the W2 report generation process.
Original PR description
1.Install l10n_us_hr_payroll 2 Navigate to Payroll>Reporting>W2 Report. 3.Open/Create W2 form and try to add payslip by clicking "Add a line". 4."Create a payslip" button appears if their are no valid payslips. 5.Click it, it won't work! Root cause: - `onAdd` bind was missing in the controller - Renderer applied an additional `.bind(...)`, breaking the callback Fix: - Pass a dedicated `createNewPayslip` action from controller - Remove double binding in renderer - Forward callback directly to helper component task-[5928770](https://www.odoo.com/odoo/project/1251/tasks/5928770)
9 changes
Resolved issues and error corrections
This update resolves an issue preventing Point of Sale (PoS) users from accessing the sinvoice symbol. By granting the necessary access rights, this change ensures PoS users can properly utilize the feature as intended. This improves functionality for retail operations.
Original PR description
Add access right for sinvoice symbol so that PoS user can access to it. Forward-Port-Of: odoo/odoo#259045
This update resolves an issue where the Batch Payment report incorrectly displayed default 'demo' values (Account Holder Name and Memo) when customer information was missing. The fix ensures that these fields are blank in the report, presenting accurate and clean payment details for users. This improves the clarity and professionalism of the printed reports.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113515This update fixes a potential issue where website tours could incorrectly proceed if the chat feature was temporarily empty. The change implements a more reliable check to ensure the tour only continues when the empty chat is definitively confirmed, improving the overall user experience. This ensures tours function consistently and reliably.
Original PR description
The previous negative assertion could pass prematurely during fast tour execution. Switching to a specific text based assertion ensures the step only proceeds once the empty conversation is explicitly confirmed. Forward-Port-Of: odoo/odoo#258921
This update fixes a discrepancy in the 'To Pay' dashboard by ensuring it accurately reflects all outstanding payments, including receipts, alongside invoices and refunds. Previously, the dashboard only considered invoices, leading to an inaccurate count and amount. This change ensures dashboard metrics align with the detailed records available in the action view.
Original PR description
- The "To Pay" section in the purchase/sales dashboard was only considering invoices(`in_invoice` and out_invoice) and refunds(`in_refund` and `out_refund`) when computing the number and amounts to pay. - However, the corresponding action view includes receipts (`in_receipt` and `out_receipt`), leading to an inconsistency where the dashboard count and amount did not match the records shown after clicking. - This commit updates the dashboard query to also include receipts, ensuring consistency between the displayed metrics of the coreesponding purchase/sales dashboard and the action view. Related PR: https://github.com/odoo/enterprise/pull/111142 taskID-6040828 Forward-Port-Of: odoo/odoo#254295
This update corrects a discrepancy in the sale and purchase journal dashboards. Previously, receipt data wasn't included, leading to inaccurate record counts. Now, receipts are incorporated, ensuring dashboard metrics align with the actual data for a more reliable view of financial activity.
Original PR description
- The sale and purchase journal dashboards excluded receipts while the action view included them, causing a mismatch between counts and displayed records. Include receipts in the dashboard query to ensure consistency. Related PR:https://github.com/odoo/odoo/pull/254295 taskID-6040828 Forward-Port-Of: odoo/enterprise#111142
This update fixes an issue where the 'Back to edit mode' link in the land portal invoice was incorrectly directing users to the wrong Odoo app. By switching to the correct action, the webclient now consistently directs users to the Invoicing app, ensuring accurate invoice management. This improves the user experience and prevents incorrect navigation.
Original PR description
The "Back to edit mode" link used action_move_out_invoice_type, which isn't bound to any menu, so the backend fell back to whichever app happened to match (e.g. Website when installed) instead of Invoicing. Switch to action_move_out_invoice (the one referenced by the Invoicing menu) so the webclient resolves the correct app automatically. task-5882256 Forward-Port-Of: odoo/odoo#257841
This update fixes a problem where multiple email aliases could lead to duplicate records being created when emails were processed concurrently. The fix uses a locking mechanism to ensure that only one record is created for each email, regardless of how many aliases receive it. This improves data accuracy and prevents potential issues with reporting and analysis.
Original PR description
Concurrent processing of emails with the same `Message-Id` can create duplicate records. ### Steps to reproduce 1. Configure multiple mail aliases (e.g., two helpdesk teams). 2. Send one email with…
Concurrent processing of emails with the same `Message-Id` can create duplicate records. ### Steps to reproduce 1. Configure multiple mail aliases (e.g., two helpdesk teams). 2. Send one email with both aliases as recipient. The Mail Transfer Agent may invoke `odoo-mailgate.py` once per recipient, resulting in concurrent processing of the same email in separate transactions. We expect one record per alias/team, but duplicates may be created. ### Cause This is a race condition in the `Message-Id` deduplication logic, caused by concurrent transactions and PostgreSQL snapshot isolation. Odoo uses the `REPEATABLE READ` isolation level. This means that each transaction takes a snapshot of the database at its first query and cannot see changes committed by other concurrent transactions. When two concurrent transactions process the same email: 1. Both enter `message_process` and take their snapshot. 2. Both search for the `Message-Id`. Because their snapshots don't include each other's work, both find nothing. 3. Both create records. Even if one transaction commits before the other performs the check, the second transaction still uses its original stale snapshot and create duplicates. ### Fix After the initial duplicate check, attempt to acquire a transactional advisory lock on a hash of the `Message-Id` using `pg_try_advisory_xact_lock`. If another transaction is already processing the same email and holds the lock, the call returns false and the email is treated as a duplicate. If the lock is acquired, processing continues as normal. opw-5116492 Forward-Port-Of: odoo/odoo#258847 Forward-Port-Of: odoo/odoo#250027
This update corrects a flaw in how appointment booking capacities are calculated, ensuring resources are accurately reserved rather than reserving full party sizes. This fix improves the reliability of appointment scheduling and prevents overbooking issues. The change was driven by a bug fix and includes updated testing.
Original PR description
The current logic inside the appointment google reserve controller to compute reserved and used capacity per resource was incorrect. It was reserving the full party size for each resource instead of properly computing how much spots we are reserving for each. The code was fixed and a test was adapted for proper coverage. Task-6120016 Forward-Port-Of: odoo/enterprise#113805
This update resolves an issue where empty or missing attachments in invoices could cause the system to crash during import. The fix now gracefully falls back to default journal and move type settings, ensuring invoices are created and any errors are logged. The underlying cause of the empty attachments is still being investigated.
Original PR description
Empty attachments (ex: False/None) could crash parsing during import, this commit falls back on default journal and move type in case of error, allowing the invoice to be created and the issue logged properly. Root cause of empty XML remains unclear, likely a 3rd party error. opw-6113211 Forward-Port-Of: odoo/odoo#259294
2 changes
Resolved issues and error corrections
This update resolves an issue where the Batch Payment report incorrectly displayed default 'demo' values (Account Holder Name and Memo) when customer information was missing. The fix ensures that these fields are blank in the report, providing accurate and clean payment details for customers without specified account holder names.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113515This update corrects a discrepancy in the sale and purchase journal dashboards. Previously, receipt data wasn't included, leading to inaccurate counts. Now, receipts are properly incorporated, ensuring dashboard metrics align with the actual recorded transactions for a more reliable view of business activity.
Original PR description
- The sale and purchase journal dashboards excluded receipts while the action view included them, causing a mismatch between counts and displayed records. Include receipts in the dashboard query to ensure consistency. Related PR:https://github.com/odoo/odoo/pull/254295 taskID-6040828 Forward-Port-Of: odoo/enterprise#111142
23 changes
Resolved issues and error corrections
This update removes a restriction that prevented users from accessing tax returns when the GST e-filing feature was disabled. Previously, a warning forced users to enable this feature, which wasn't always necessary. Now, users can access all tax returns regardless of the GST e-filing setting.
Original PR description
BEFORE: - Before this commit, when we disable the gst e-filing feature from the configuration and try to access the tax return view, we are getting blocked by the redirect warning, which suggests…
BEFORE: - Before this commit, when we disable the gst e-filing feature from the configuration and try to access the tax return view, we are getting blocked by the redirect warning, which suggests enabling the gst e-filing feature from the configuration. - Which is not desirable, as there might be some returns that are not related to gst e-filing, which should be accessible by the user. AFTER: - After this commit, removed the RedirectWarning when accessing the tax return view with gst e-filing feature disabled. So now the user can access tax returns without enabling gst e-filing feature. - At the time of setting the fiscal year(generating/refreshing returns automatically), the GSTR returns will not be created. - And at the time of manual GSTR return creation, we are raising UserError to instruct the user about enabling the gst e-filing feature. Related Com PR: https://github.com/odoo/odoo/pull/247216 Task-5486586 Forward-Port-Of: odoo/enterprise#113741 Forward-Port-Of: odoo/enterprise#105983
This update resolves a test failure related to currency discrepancies in DIAN move detection. The system now ensures that all test moves use the same currency, correcting a previous configuration that caused the test to fail. This ensures accurate duplicate move detection for Colombian tax reporting.
Original PR description
Following [PR](https://github.com/odoo/odoo/pull/248421), duplicate move detection now also checks the currency of both moves. Consequently, the `test_validate_duplicate_cufe` test case is failing because the moves in the test use different currencies. This commit ensures both moves use the same currency to fix the test. task-5916255
This update resolves an issue where overridden group names within the accounting module weren't being correctly translated into Odoo's internationalization files (POT). By adding specific XMLIDs to the `account_accountant` module, the system now accurately exports these group names for consistent translation across all Odoo languages. This ensures accurate translations for users in different regions.
Original PR description
The `account_accountant` module overrides the English name of several `res.groups` records owned by `account`. Without `account_accountant`-scoped XMLIDs for those records, the overridden names are never exported into this module's POT file. At runtime, `account`'s translations are loaded instead, which no longer match the overridden English source strings. We fix this by registering additional XMLIDs under `account_accountant` so the overridden names get translated independently. Forward-Port-Of: odoo/enterprise#113470 Forward-Port-Of: odoo/enterprise#112898
This update fixes a discrepancy in the Board of Accountancy (BOA) generation tests for the Philippine version of Odoo. The tests were failing due to a recent change in the Philippine Chart of Accounts (COA). The commit updated the test assertions to accurately reflect the new account codes and names, ensuring the reports generate correctly.
Original PR description
The expected account codes and names in the BOA (Board of Accountancy) generation tests were failing due to a recent update in the Philippine Chart of Accounts (COA). This commit updates the hardcoded CSV test assertions to reflect the new account codes and names so the tests pass successfully. Key account mapping updates in the tests: * 110000 Accounts Receivable -> 103010 Accounts Receivable - Trade * 110201 Input VAT 12% -> 106010 Input VAT 12% * 200000 Accounts Payable -> 201010 Accounts Payable - Trade * 200300 Output VAT 12% -> 206010 Output VAT 12% * 430400 Sales/Revenues -> 401010 Sales/Revenues * 620000 Admin Expense -> 603090 Miscellaneous Expenses Task-5916666 CE PR: https://github.com/odoo/odoo/pull/254973
This update fixes an issue where vendor bills created in the Documents module incorrectly defaulted to the company's currency instead of the vendor's. Now, when a vendor is selected in the Documents module, the bill automatically uses the vendor's currency, ensuring accurate financial reporting. This improves the reliability of vendor billing transactions.
Original PR description
**Issue:** When creating a vendor bill or vendor refund through the Documents module after selecting a supplier, the currency defaults to the company's currency instead of the vendor's. However, if the supplier is selected later in the Accounting module, the correct supplier currency is applied. **Steps to reproduce:** - In Documents, upload a bill. - Click on the bill and assign a vendor (whose supplier currency is different from the company's currency). - Click on "Create Vendor Bill". The used currency isn't that of the supplier. opw-4406074 Forward-Port-Of: odoo/enterprise#100846 Forward-Port-Of: odoo/enterprise#78380
A recent change to the Hong Kong Payroll module's employee view caused an installation error. This fix removes a dependency on a now-unnecessary field, restoring the module's ability to install correctly. It also addresses a related issue with data labeling within the payroll process.
Original PR description
See https://github.com/odoo/odoo/commit/3259a7fae4ca4ee98f7e02da5109c43cd9e77f69 This commit changed the employee view and removed the departure date, which was used in the inherited view in the Hong Kong Payroll. This causes the module to no longer be installable, requiring this fix. Also fixes another issue from the same task, which made the l10n_hk_leaving_hk in `hr.employee.departure` to end up at the wrong place and without label. task-6119117
This update fixes an issue where 'All Day' appointments were incorrectly displayed with inflated durations (e.g., 1 day 7 hours). The change ensures that 'All Day' slots now accurately show the duration in days, aligning with how these appointments are intended to be represented. This improves the clarity and accuracy of booking information.
Original PR description
Enabling the "All Day" option on a slot (e.g. 14 Feb, 10:00–17:00) shifts the `end_datetime` by +1 day internally, turning the slot into a longer duration (e.g. 31 hours). Currently, the duration is computed by adding the delta between start and end while assuming the end falls at midnight, which incorrectly increases the effective duration. This caused the booking details page to display an inflated duration for all-day slots (e.g. 1 day 7 hours). Since all-day slots semantically represent calendar days rather than hour spans, the displayed duration is now computed using the date span between start and end. In short, when `allday` is enabled, duration is shown strictly in days. Normal slots continue to display duration in hours. Task-5386301
A recent update caused a technical error when checking sign requests, preventing users from accessing the sign functionality. This fix ensures that type checks are performed correctly before comparisons, resolving the error and restoring normal sign request processing. This change improves the reliability of the sign process.
Original PR description
This issue occurs because, in the recent [commit], `sign_request` was changed to `sign_item`, but the `sign_item.exists()` check is performed after the type comparison, resulting in a `TypeError`.…
This issue occurs because, in the recent [commit], `sign_request` was changed to `sign_item`, but the `sign_item.exists()` check is performed after the type comparison, resulting in a `TypeError`.
Traceback:
```py
File "/home/odoo/src/odoo/saas-19.2/odoo/addons/base/models/ir_http.py", line 415, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/saas-19.2/odoo/http/routing_map.py", line 207, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/enterprise/saas-19.2/sign/controllers/main.py", line 708, in get_sign_request_items
if not sign_request.exists() or not consteq(sign_item.access_token, token) or not sign_item.exists() or not sign_item.signer_email:
TypeError: unsupported operand types(s) or combination of types: 'bool' and 'str'
```
Solution:
We first perform the existence check and then compare the types.
[commit]: https://github.com/odoo/enterprise/pull/111786/changes/f40082f4e6f50dccbfa639edbef08428868cb31d
sentry-7376866293
Forward-Port-Of: odoo/enterprise#112659This update resolves an issue where clicking the 'Details' button during the signing process caused an error. The fix ensures the button is hidden when the system is in signing mode, preventing the error and improving the user experience. This change ensures a smoother signing workflow for internal users.
Original PR description
Version: - saas-19.2 Steps to reproduce: - Create sign request for internal user. - Open document. - Start Signing and click on 'Details' button in contoll panel. Issue: - Clicking this button during signing causes a traceback error. Cause - The button is defined in `sign.SignRequestControlPanel` and is always rendered. In signing mode, the template is reused via XML inheritance (sign.SignSignableRequestControlPanel), but the corresponding JS component (SignableRequestControlPanel) does not implement the openFormView method. As a result, clicking the button leads to a runtime error. Solution - Control the visibility of the "Details" button using a getter. The getter returns true in SignRequestControlPanel (normal mode) and false in SignableRequestControlPanel (signing mode), ensuring the button is hidden when the required method is not available. task-6074593 Forward-Port-Of: odoo/enterprise#112299
This update eliminates a brief, distracting flash of a confirmation button on user messages in the Odoo Enterprise app. The fix ensures the button only appears on genuine agent confirmation messages, improving the user experience and reducing visual noise. This was a minor cosmetic issue.
Original PR description
#### Issue The optimistic user message briefly becomes newestMessage without a subtype, so the “Let’s do it!” button flashes for a few milliseconds on the user’s own message before it gets posted. That looks distracting. #### Fix Guarding on subtype_id in both the message action and isActive logic to make sure the button only appears on real tool-confirmation messages. task-id-6060262
This update fixes a recurring error that occurred when refreshing the Payslips list within the payroll module. The issue stemmed from a system signal causing components to be destroyed prematurely, leading to crashes. The fix prevents components from making calls when destroyed, ensuring a stable and reliable Payslips experience.
Original PR description
Bug: Payroll > Payslips refresh couple of times -> error (componenet is destroyed) Cause: A signal from the controller to re-render before mounting the first one, creates another component and calls for the destruction of the first, yet the first component can make calls and cause a crash. Fix: Prevent the component from making calls if it's destroyed. Task#6067771
This update corrects a bug in the web_studio report editor that was causing unwanted spacing to appear in generated reports. The fix prevents automatic insertions between layout sections, ensuring reports print correctly. This improves the overall quality and consistency of reports created within web_studio.
Original PR description
… sections Before this commit, the html_editor automatically put placeholders between hearder, article and footer nodes (identified with classes) This is caused by odoo/odoo@edf7f7bb0c62978640c181eccb4934855d5d872d. This caused issues because at print time those cracks are not printed because of base/ir_actions_report.py:def _prepare_html (which separates header, footer, and articles to pass them to wkhtmltopdf) After this commit, those placeholders are not present in those cracks. opw-6048955 Forward-Port-Of: odoo/enterprise#113800 Forward-Port-Of: odoo/enterprise#112458
This update resolves a test failure related to inter-company stock transfers. The test required access to specific lot IDs, which were only available when using the Odoo demo database. This fix ensures the test runs correctly in a standard, non-demo environment.
Original PR description
*: sale_purchase_stock_inter_company_rules ### Steps to reproduce: - Create a DB without demo data - Install stock_dropshipping, sale_purchase_stock_inter_company_rules - Run the test `test_08_dropship_inter_company_vendor_to_customer` ### Issue: The test `test_08_dropship_inter_company_vendor_to_customer` fails here: https://github.com/odoo/enterprise/blob/fd3c9d894d8821ed1d1a110cdffb5e16fb54590a/sale_purchase_stock_inter_company_rules/tests/test_inter_company_po_to_so.py#L497-L501 since the `lot_ids` are only visible for users with the `stock.group_production_lot` group: https://github.com/odoo/odoo/blob/544961c1c6db254c4292d88096bdf9363e35f0bc/addons/stock/views/stock_picking_views.xml#L310-L318 And this group is only implied with demo data: https://github.com/odoo/odoo/blob/544961c1c6db254c4292d88096bdf9363e35f0bc/addons/stock/data/stock_demo.xml#L190-L193 opw-6085811 Forward-Port-Of: odoo/enterprise#113120
This update resolves a visual issue where text in the benefit configuration section would split and misalign with checkboxes when viewed on different screen sizes. The fix ensures all text remains on a single line, improving the user experience and preventing layout problems. This change improves the clarity and usability of the benefit setup process.
Original PR description
Step to reproduce: play with the width of the window, at some point text splits and item are unaligned. Cause: with some window width, the text is splitted on 2 lines, which makes it unaligned with the checkbox. Solution: force text on same line using style="white-space: nowrap". Task: 6069017 Forward-Port-Of: odoo/enterprise#113570 Forward-Port-Of: odoo/enterprise#113386
This update resolves a visual issue where non-internal users were seeing a 'No IM status available' icon in the WhatsApp channel. The fix ensures the icon only appears when status information is actually available. Additionally, a new category has been added to the channel member list for users without status updates.
Original PR description
Since [1], non-internal users don't receive the IM status of other users. This leads to the "No IM status available" icon to be shown to non-internal users. This commit fixes the issue by only showing the icon when the value is available. This commit also adds a category in the channel member list for users missing status information. [1] https://github.com/odoo/odoo/pull/251938
This update simplifies the way vendor bills are viewed and managed within Odoo Enterprise. It reverts a previous change that disrupted the bill form and list views, restoring the original functionality. This ensures users can easily access and work with vendor bill information.
Original PR description
This reverts commit 509ca37eef3a6dc9d148f0a11f350d41704eb02f.
This update reverts a recent change that incorrectly relied on document sequence editability for predictive name suggestions in the accounting module. The system now correctly uses the established `quick_edit_mode` logic, ensuring accurate and reliable name suggestions for users. This resolves a potential issue impacting the usability of the accounting features.
Original PR description
In https://github.com/odoo/enterprise/commit/4a61583b77835a648279bff492173469f2329a46 the condition in `_onchange_name_predictive` was updated to use `document_sequence_editable` instead of `quick_edit_mode`. However, the predictive logic is based on `quick_edit_mode`, not sequence editability. So this commit reverts that change.
This update corrects a display issue in the batch payment reports. Previously, the report would show default 'demo' values (like 'ABC Holder Name') when an account holder name wasn't specified. Now, the report correctly leaves these fields blank when no account holder information is provided, ensuring accurate reporting.
Original PR description
**Steps to reproduce:** - Install the `account_batch_payment` module. - Navigate to Invoicing > Customers > Payments. - Create a new payment with `Payment Type: Send` and select a customer without…
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113891
Forward-Port-Of: odoo/enterprise#113515This update resolves a technical issue that prevented users from generating sale commission reports when filtering by the current period. The fix corrects a formatting error in the report's data processing, ensuring accurate reporting and preventing a system error. This improves the reliability of sales performance analysis.
Original PR description
Before this commit, the following traceback could occurs when filtering the current period in achievements.
File "/home/arj/PycharmProjects/worktree/saas-19.1/enterprise/sale_commission/report/achievement_report.py", line 79, in _search
date_to_list = date_to_domain and [datetime.strptime(d[2], '%Y-%m-%d') for d in date_to_domain if len(d) == 3 and d[2]]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/_strptime.py", line 554, in _strptime_datetime
tt, fraction, gmtoff_fraction = _strptime(data_string, format)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/_strptime.py", line 333, in _strptime
raise ValueError("time data %r does not match format %r" %
ValueError: time data 'today' does not match format '%Y-%m-%d'
Forward-Port-Of: odoo/enterprise#112981This update corrects a bug where the payroll warning date incorrectly jumped to the next month when the system date was set before the closing day. The fix ensures the warning remains in the current month until the closing day has passed, preventing confusion and ensuring accurate payroll calculations. A related documentation error was also addressed.
Original PR description
steps to reproduce: - install `hr_payroll` - set closing day as "5th of next month" (via schedule warning) - set system date as <5 of the month - notice that the warning date jumped to next month description: - it should stay in the current month until closing day has passed cause: - there was no check for if the closing day has passed while in the next month scenario fix: - jump to next month only if today has passed closing date. (also fixed a wrong docstring) [task#6084911](https://www.odoo.com/odoo/project/1251/tasks/6084911) Forward-Port-Of: odoo/enterprise#112597
This update corrects a display issue in predefined filters within Odoo Enterprise, replacing the "Invalid Datetime" error with the correct smart date options. This improves the user experience when editing filters for tasks and messages, ensuring accurate date range selections. A related change also updates date range logic for certain filters, such as excluding today's date in some cases.
Original PR description
In many predefined custom filters (eg. `Project > All tasks > Search Bar > Closed On > Last 30 days`), when editing the filter (eg. click on the label), the editor opens on "Invalid Datetime". This…
In many predefined custom filters (eg. `Project > All tasks > Search Bar > Closed On > Last 30 days`), when editing the filter (eg. click on the label), the editor opens on "Invalid Datetime". This PR makes the predefined filters that match an existing smart date land on the smart dates instead of "Invalid Datetime". WHY: The way the date ranges are coded in the python files does not match the expected structure of the smart dates. FIX: By reformatting the domain of the predefined filter the search model is able to interpret that as smart ranges and displays the correct label and dropdown option when editing the filter. NOTE: - The reformatting of the domain sometimes also changes the logic (ie which records that are displayed). Notably in the IM livechat the "Last 7 days", "Last 30 days" ... filters now exclude today. This was asked by the framework PO (CTH) and I double checked with the discuss PO (FHE). - The task also include making a new relative range filter, but was split in 2 so that this part can be merged before the freeze (see odoo/odoo#252484) - We also change the smart date "Last 12 months" to "Last 365 days" as this is clearer from a user perspective and last 365 days was more used in arch filters. (previously when applying last 12 months smart date the range was set to the the 1st of 12 months ago to the 1st of the current month) - I also added some helpers to the test files to make them more readable and shorter. Community PR: odoo/odoo#257914 task#5959944
This update fixes an issue where rental product prices were incorrectly shown as list prices in search results. The change ensures that users see the accurate rental price, improving the shopping experience and preventing pricing discrepancies. This was a result of recent searchbar refactoring.
Original PR description
After the searchbar refactoring in [1], In the search results, rental product prices were incorrectly replaced by their list price. Ensure the correct rental price is displayed instead of the list price. task-6105283
This update corrects inaccurate titles and links within the Phone dashboard. The changes ensure users are directed to the correct information, enhancing the clarity and usability of this key reporting tool. This fix was made to improve the overall user experience.
Original PR description
This commit fixes two titles (and links) in the Phone dashboard. Task: 6120857 Forward-Port-Of: odoo/enterprise#113828
5 changes
Resolved issues and error corrections
This update resolves an issue where very small order weights (under 1kg) weren't being correctly converted to grams before being sent to the shipping carrier. Previously, the system treated these as zero, leading to rejected orders. Now, all non-zero lightweight orders are accurately converted, ensuring shipments meet carrier minimum weight requirements.
Original PR description
Before this commit, `sendcloud_convert_weight()` used the source UoM rounding to short-circuit zero values. On databases where the weight UoM is `kg` with a rounding of `1.0`, any weight below 1kg was treated as zero and returned unconverted. For example, 0.23kg stayed 0.23 instead of being converted to 230g, `int()` turned it into 0, and Sendcloud rejected the order as being below the carrier minimum weight. This commit ensures that non-zero lightweight orders are properly converted before Sendcloud weight checks are applied. opw-6014572
This update resolves an issue where the Batch Payment report incorrectly displayed default 'demo' values (Account Holder Name and Memo) when customer information was missing. The fix ensures that these fields are blank in the report, providing accurate and clean payment details for users. This improves the clarity and professionalism of the printed reports.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113515This update adds a specific line item to the CH balance sheet report to accurately reflect Treasury Shares (account 2980). Previously, this account was handled differently, and this change corrects a previous omission, ensuring accurate equity reporting for Swiss clients. The change improves the report's precision and aligns with accounting standards.
Original PR description
This commit adds a dedicated report line for account 2980 (Treasury shares) to the CH balance sheet report. Account 2980 was previously included in the Legal reserves report line via the old formula:…
This commit adds a dedicated report line for account 2980 (Treasury shares) to the CH balance sheet report.
Account 2980 was previously included in the Legal reserves report line via the old formula:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2991'), ('account_id.account_type', '!=', 'equity_unaffected')]
```
In recent commit https://github.com/odoo/enterprise/pull/102247/changes/81bcf433e909ce6ec56af484e9dd59a47fc87c98 the formula was narrowed down to :
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2970')]
```
And account 2980 was no longer considered.
Rather than adding it to the Legal reserves formula, a dedicated Treasury shares report line (CH_290_C) has been added under report line CH_290. New line as account 2980 represents a correction of equity (negative item) and is conceptually distinct from legal reserves. The parent line aggregation formula has been updated accordingly:
```py
CH_290_A.balance + CH_290_B.balance + CH_290_C.balance
```
see affected account: https://github.com/odoo/odoo/blob/19.0/addons/l10n_ch/data/template/account.account-ch.csv#L108This update corrects a technical issue impacting delivery processing for Colombia. Previously, the system incorrectly formatted zip codes, leading to inaccurate data sent to Envia. Now, the system uses Envia's geocoding service to ensure correct zip code formatting, improving delivery reliability.
Original PR description
For Colombia, Envia expects the municipality/DANE-style code in the address payload, not the raw postal code. When `l10n_co_edi` was not installed, the Envia integration fell back to the partner zip code and padded it locally before sending it as both `postalCode` and `city`. This produced incorrect values such as turning the Ibagué zip code `730001` into `73000100`, while Envia geocodes resolves that zip code to `73001000`. Use Envia geocodes to resolve the Colombia zip fallback and retrieve the `stat_8digit` code expected by Envia instead of deriving it locally. opw-6083181
This update resolves an issue where POS users with limited access rights were unable to fully close their Fiskaly VAT resolution sessions, requiring administrator privileges. The fix simplifies the process by removing unnecessary checks for API credentials, ensuring a smoother user experience for POS users working with the Germany + Fiskaly setup. This improves usability and avoids requiring specialized user permissions.
Original PR description
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager)…
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager) rights. Steps to reproduce: ------------------- * Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly * Use a user with POS rights only (no Access Rights) * Open POS, sell, then close the session from the POS UI > Observation: A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read). Why the fix: ------------ The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials. Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required; this change fixes unnecessary reads of protected fields in the tax helper, not the security model of the credentials themselves. opw-6074960 Forward-Port-Of: odoo/enterprise#112618
13 changes
Resolved issues and error corrections
This update fixes an error in how Odoo calculates depreciation for companies with non-standard fiscal years. Previously, depreciation entries were missed for certain months, particularly at the beginning of the next fiscal year. The fix ensures accurate depreciation calculations based on the company's actual fiscal year start date.
Original PR description
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next…
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely. Step to reproduce: - Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025) - Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method - Compute the board and observe that entries from January to April 2026 are missing Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal. opw-6016834 Forward-Port-Of: odoo/enterprise#113521
This update resolves an issue where barcode quantities were displayed with slight rounding errors due to how JavaScript handles decimal numbers. The fix ensures accurate quantity representation in the barcode interface, preventing discrepancies in inventory tracking. This improves data reliability for stock management operations.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to Settings and enable: * Storage Locations (Warehouse). * Batch, Wave & Cluster Transfers. * Create a Product and set its on-hand quantity to…
**Steps to reproduce:**
* Install `stock` module.
* Go to Settings and enable:
* Storage Locations (Warehouse).
* Batch, Wave & Cluster Transfers.
* Create a Product and set its on-hand quantity to 60.
* Go to Inventory → Configuration → Operation Types and create a new operation type:
* Set Type of Operation to Internal Transfer.
* In the Barcode App tab, enable Group batch lines.
* Go to Inventory → Operations → Internal Transfers and create a new transfer:
* Select the newly created Operation Type.
* Add the created Product with quantity 4.4.
* Mark the transfer as To Do.
* Create another Internal Transfer with the same configuration:
* Select the same Operation Type.
* Add the same Product with quantity 48.8.
* Mark the transfer as To Do.
* Open the Internal Transfers list view.
* Select both created transfers.
* Click Action → Add to Wave Transfer.
* Choose A new Wave Transfer and confirm.
* In the popup, select both transfers and add them to the wave.
* Open the Barcode application.
* Open the created operation and select the Batch on the right side
to open the wave transfer in the barcode interface.
**Observed behavior:**
- The grouped line quantity is displayed as 53.99999996 instead of
the expected value(53.2).
**Cause:**
- When the Barcode app loads data,` _createState()` is executed,
which calls `groupLines()`.
- Inside this method, quantities are aggregated using standard
JavaScript floating-point addition:
https://github.com/odoo/enterprise/blob/08d0a7f480046bb489ca69e7b3535e99cb20eee5/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L204-L205
- Since JavaScript stores numbers as binary floating-point values,
decimals like 4.4 and 48.8 cannot be represented exactly.
Repeated additions accumulate precision errors, producing results
like 53.99999996 instead of 53.2.
**Fix:**
- Aggregate quantities using `formatFloat` with the barcode precision
before converting them back to floats
- `formatFloat` rounds the value according to the configured precision
of the barcode model, ensuring the intermediate result is normalized
after each addition. Converting the formatted value back with
`parseFloat` guarantees the stored number respects the expected
decimal precision and prevents floating-point accumulation errors.
---
opw-5932329This update resolves an issue where negative numbers in accounting reports (like customer statements) were incorrectly split across lines, making them difficult to read. The fix ensures that negative numbers are displayed as a single line, maintaining proper formatting and clarity in printed reports. This improves the user experience when reviewing financial data.
Original PR description
When printing accounting reports such as customer statements, a negative number may be split across two lines, leaving the minus sign on the first line and the amount on the second. Steps to reproduce: - Make an invoice for [Partner] with a total of 10.0 - Make another invoice for [Partner] with a total of 100.0 - Create a credit note for this last invoice - Open the customer statement report for [Partner] - Print PDF Issue: The first line of the partner section has fewer digits than the amounts of the subsequent journal items. On pdf, the column width is based on the smaller line, causing the longer negative strings to wrap and separate the minus sign from the amount. opw-5951300
This update fixes an issue where the namespace for sending credit notes to DIAN was incorrectly configured. The change ensures the correct namespace is used, resolving potential errors when submitting credit notes to the Colombian tax authority. This prevents disruptions in financial reporting and compliance.
Original PR description
Issue: Incorrect `sts` namespace raises several issues when sent to dian Steps to reproduce: - On a Colombian company - Create a credit note - Send to DIAN Current Behavior: - Credit note have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1` while their Extension node has another `sts` namespace to `http://www.dian.gov.co/contratos/facturaelectronica/v1/Structures` Expected Behavior: - Only the top level Node should have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1`. It was forgotten that Credit Note were part of the Invoices in the last refactor. As it's the second time(odoo/enterprise#68619 3rd commit) it happens, I updated the test. opw-6077050
This update resolves an issue preventing the generation of session reports in the CO company setting for point-of-sale. The fix corrects a technical error that was causing a traceback when attempting to generate the report. Users can now reliably generate session reports after a sale is completed.
Original PR description
Currently when trying to generate the session report a traceback appears. Steps to reproduce: ------------------- * Install l10n_co_edi_pos * Switch to CO company * Open pos session * Make a sale * Close register * Generate session report > Traceback Why the fix: ------------ We get the sale details with: https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L429-L430 Where the config ids given to `get_sale_details` are given here https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L413-L414 From there we can't access any field from a list of number. opw-6049484
This update resolves a technical issue that caused an error when quickly reordering tasks within the Project module's Kanban view. The problem occurred due to a component being destroyed during a task movement process. The fix ensures this error is gracefully handled, preventing disruptions to task management.
Original PR description
Steps to reproduce: ---------------------------------------- 1. Install the Project module with the demo data 2. Go to Task > All Tasks> Kanban View 3. Move all the tasks to any one stage except one…
Steps to reproduce:
----------------------------------------
1. Install the Project module with the demo data
2. Go to Task > All Tasks> Kanban View
3. Move all the tasks to any one stage except one task
4. Now move that one task and quickly press (Alt + 1) to exit
Observation:
----------------------------------------
Traceback occurs:
```
Uncaught Promise > Component is destroyed
Occured on localhost:8069 on 2026-03-10 09:47:35 GMT
Error: Component is destroyed
```
Issue:
---------------------------------------
When dragging a record between groups, `moveRecord` calls `_resequence()`, which checks `canResequence()`
https://github.com/odoo/odoo/blob/f86baa6ba1c915145dbfe43b67de0eff13959e91/addons/web/static/src/model/relational_model/dynamic_list.js#L311-L314
For Project Tasks, `canResequence()` returns `true`, so the full async chain runs:
1. `rpc('/web/dataset/resequence')` — raw, unprotected call (succeeds)
2. `orm.read()` — protected by `useService` wrapper
If the user navigates away (ALT+1) between step 1 and step 2, the component is destroyed, and `orm.read()` throws Error('Component is destroyed') via `_protectMethod`
https://github.com/odoo/odoo/blob/f86baa6ba1c915145dbfe43b67de0eff13959e91/addons/web/static/src/core/utils/hooks.js#L106-L110
This error propagates up unhandled.
Solution:
---------------------------------------
Override `sortRecordDrop` in `ProjectTaskKanbanRenderer` to catch the 'Component is destroyed' error. Since the resequence RPC has already succeeded server-side, the follow-up `orm.read()` failure is harmless, the component is being destroyed anyway.
opw-5932085This update fixes an issue where incorrect pricing rules were being applied to products with multiple variants. The change ensures that the correct rule is selected based on the specific product variant, improving the accuracy of product pricing in the Point of Sale system. This resolves a potential discrepancy in sales pricing.
Original PR description
When a product has multiple variant, and each product.product has a specific rule in a pricelist. It was possible that the wrong rule is selected from `cachedPricelistRules` as it would contain all the rules for a product. Why the fix: ------------ We add a condition to make sure that the rule is linked to the specific product.product. runbot-108050
This update resolves an issue where empty attachments (like False/None) in PEPPOL invoices caused import errors and crashes. The fix now gracefully falls back to default journal and move type settings, ensuring invoices are created and any errors are logged. The underlying cause of the empty attachments is still being investigated.
Original PR description
Empty attachments (ex: False/None) could crash parsing during import, this commit falls back on default journal and move type in case of error, allowing the invoice to be created and the issue logged properly. Root cause of empty XML remains unclear, likely a 3rd party error. opw-6113211
This update fixes an issue where numbers in the domain selector and expression editor were not displayed correctly based on the user's locale settings. Now, numbers are formatted according to the user's chosen language, ensuring accurate data representation and a better user experience. This improves consistency and usability across different regions.
Original PR description
Before this commit, the domain selector (and expression editor) did not format numbers according to the localization parameters (decimal and thousands separators), while the parsing step did. After this commit, the value is displayed in the correct format to the user, while the expression remains unchanged. 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
This update corrects a technical error that prevented users from selecting stores when the store's address (city or street) was missing. The fix ensures the system handles empty address fields gracefully, preventing errors and improving the Click and Collect functionality. This resolves a bug reported in opw-6050137.
Original PR description
Issue: --- An owl error is raised in select store if the store's company location lacks city or street. Steps to reproduce: 1- Enable Click and Collect. 2- In pickup locations, set a company with an address with empty street or city. 3- Go to the shop. 4- Enable debug mode. 5- Select store. An owl error is raised due to not city and street not being string. opw-6050137
This update simplifies the process of reloading the chart of accounts by replacing a confusing error message with a direct guide to the relevant settings. The change provides clearer instructions for users, ensuring they can quickly update their localization apps and resolve potential issues.
Original PR description
Previously, when new taxes with new tax tags were introduced, reloading the chart of accounts would raise a generic UserError suggesting to update the localization app. This could be confusing for users, as it did not indicate which app needed to be updated. With this commit, the UserError is replaced by a RedirectWarning that guides users directly to the Apps menu with the relevant localization modules, making the resolution clearer and more user-friendly.
This update prevents issues caused by updating tax groups when associated accounts are modified. Specifically, it avoids triggering constraint errors related to account types, ensuring smoother tax group management. This change improves stability and reduces potential errors during chart updates.
Original PR description
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g.…
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g. account_type changed from an incompatible to a compatible type, the fact that the account is not updated will trigger constraints in the tax group when it is written. IOW, if the purpose of an account is not changed, its use should not be changed either. E.g.: 1f4710deb206736cd71580d8fd95552d9b7c8014 changed the value of `tax_payable_account_id` on tax group `tax_group_cofins_incl_goods` to `account_template_202011005` and the same commit changed the value of `account_type` on `account_template_202011005` from `liability_non_current` to `liability_payable`, triggering `_constrains_payable_receivable_account` (in 19.2: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/account/models/account_tax.py#L68). So here, we skip the update of relations to accounts on tax groups, if the account already exists.
This update resolves a visual inconsistency where styling applied to images (like rounded corners or shadows) was incorrectly carried over when the image was replaced with an icon. Now, icons will display without these image-specific styles, ensuring a cleaner and more consistent user experience.
Original PR description
### Steps to Reproduce: - Go to the To-do app and create a new task. - Upload an image. - Apply shape styling to the image (e.g., rounded, shadow, img-thumbnail). - Replace the image with an icon. ### Description of the issue/feature this PR addresses: - When an image had shape applied (such as rounded, rounded-circle, shadow, or img-thumbnail) and was replaced with an icon, those classes were carried over to the icon. ### Desired behavior after PR is merged: - Since these classes are specific to image shape styling, they are now removed when an image is replaced with an icon. task-6007631 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
This pull request addresses a bug in the Czech VAT reporting module (l10n_cz_reports_2025) that was preventing accurate summary reports. The fix corrects a calculation error, ensuring that VAT reports generated for Czech businesses align with local regulations. This update improves the reliability of financial reporting.
Original PR description
opw- 5979262
This update fixes a potential issue in the l10n_be_hr_payroll_sd_worx module where the report would incorrectly use the current year instead of the specified year. This prevented the report from generating correctly and caused test failures. The fix ensures the correct year is always referenced, improving report accuracy.
Original PR description
Making sure we set the reference year when exporting the sd_worx report as if not stated it will call the current year and this will cause the test failing in future builds runbot-242148