Thursday, April 10, 2025
13 changes · 18.0
Resolved issues and error corrections
This fix avoids posting extra purchase order messages when quantities are effectively unchanged but look slightly different due to decimal rounding. It reduces confusing chatter updates for users working with unit conversions such as kilograms to tons.
Original PR description
To reproduce: Use a product that has a purchase uom in kg and a base uom in tons. Create a purchase order and deliver 1656 kg of the product. This will save as 1.6560000000001 due to python arithmetic. If you save the value again, another message will be posted even though the value does not change. To fix this, I changed the condition for posting a new message from using a '!=' operator to using float_compare which circumvents the issue. OPW-4631076 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where clicking at the start of a formatted link in the HTML editor could cause an error. Users can now place the cursor before formatted links normally, making text editing more reliable.
Original PR description
**Current behavior before PR:** - Clicking at the start of a link which has some format applied on it would trigger a traceback error. **Desired behavior after PR is merged:** - Now, Clicking at the start of the formatted link will now correctly display the cursor before the link. task:4699778
The download link for Quote Builder PDF examples now points to the correct Odoo 18.0 file. This prevents users from seeing a 404 error when downloading example files from quotation templates.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Open a quotation template; 2. open the Quote Builder tab; 3. click "Download examples". Issue ----- 404 not found Cause ----- For product: - When commit 3e58523 updated the versions of documentation links from 17.0 to 18.0, it overlooked changing the hash part of the url for `pdfquotebuilderexamples.zip`. For sale_pdf_quote_builder: - The version in the url gets added by the `documentation_link` widget, but it doesn't update the hash part of the download link. Solution -------- Change it so it links to https://www.odoo.com/documentation/18.0/_downloads/c2c6ce32294dfddffcfefcf2775f7a09/pdfquotebuilderexamples.zip opw-4680248
Reference fields now display long selection values without overlapping the related field next to them. This improves readability and prevents confusing visual overlap when users edit records such as Marketing Card recipients.
Original PR description
This commit fixes a miss-alignment between the first select and the following many2one field in a reference field. When choosing a longer value in the first select, it overlaps with the many2one field. Steps to reproduce: - Open Marketing Card app - Click to open a record - Choose a longer value in the first select in the Recipients field => overlap between the select's value and the following many2one field task-4387904 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 fix restores a validation check to ensure spreadsheet data attachments are saved as valid JSON files. It helps prevent invalid spreadsheet data from being accepted, reducing the risk of errors when users open or work with spreadsheets.
Original PR description
In https://github.com/odoo/odoo/pull/188792 we mistakenly removed the check that ensured the spreadsheet_data attachment was a valid JSON file. Task-4657990 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
Restaurant point-of-sale users can now refund paid floating orders even when the floor has no tables configured. The fix prevents an error by creating the refund as a floating order instead of looking for a table that does not exist.
Original PR description
Steps to reproduce: ------------------------ - Install pos_restaurant. - Open a restaurant session without any table on the floor. - Create an order from floating order & pay it. - Go to orders apply paid filter and try to refund the order. Issue: -------- - We will have a tb on clicking on refund. Cause: ---------- - We were trying to access the orders of the selected table (order's table or the first table of the restaurant). Fix: ----- - We will check if table exists or not if not than it will create a floating refund order without any tb. Task - 4658258
Fixed an issue where printing a delivery order could fail for kit products whose bill of materials used a product template and packaging quantity. This prevents an error message and allows warehouse documents to print correctly in that scenario.
Original PR description
When printing a delivery order with a kit product that has a BoM with a product template (not a product_id) and a packaging quantity, we encounter a traceback due to the conversion of the quantity…
When printing a delivery order with a kit product that has a BoM with a product template (not a product_id) and a packaging quantity, we encounter a traceback due to the conversion of the quantity from the product's UoM to the order line's UoM. This happens because the product's UoM is not defined.
Steps to reproduce the bug:
- Create a storage “P1”:
- UoM: Kg
- Create a storable “Kit 1”:
- UoM: unit
- BoM:
- set only the product template field (not the product_id)
- 1 Kg of P1
- Create a delivery order for 1 unit of Kit 1
- Mark it as to do
- Set the quantity of P1 to 1kg
- try to print
Problem:
A traceback is triggered because we try to convert 1kg to an undefined uom
```
Error while render the template
UserError: The unit of measure Units defined on the order line doesn't
belong to the same category as the unit of measure False defined on
the product. Please correct the unit of measure defined on the order
line or on the product. They should belong to the same category.
```
opw-4619140The New Zealand localization now reports GST-only import taxes in Box 13 instead of Box 11, aligning with IRD GST reporting rules. This helps businesses avoid misclassified GST return figures for customs-billed import GST.
Original PR description
Current set up under the tax concerned is "BOX 11" which is incorrect as according to the IRD GST report, BOX 11 excludes the amount of imported goods. The tax in consideration is used when the NZ Customs bills the user only for the GST amount based on the purchase value of the goods. Therefore, the tax grids for this tax need to changed to "BOX 13". task-3926151
This fix restores the expected secondary color styling for table headers in report layouts. It keeps report tables visually consistent with previous versions and improves readability for users viewing generated documents.
Original PR description
Before version 18.0, the secondary color was applied to `<thead><th>`. However, after this commit https://github.com/odoo/odoo/commit/d492a35b3d070c997ceb9ba4a9d9617eb11fa21d, the secondary color was not applied properly for layouts. Current visual result: | Before fix | After fix | | --- | --- | | | | - OPW: 4649140 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
Odoo Studio no longer shows the Colombian Daily Journal report in its report editor, preventing an error when users open it from customer invoices. This avoids a confusing crash for businesses using Colombian accounting reports while keeping the report available through the intended accounting reporting flow.
Original PR description
**Step to reproduce** 1. createdb with installing l10n_co_reports in 18.0 2. and install web_studio 3. open studio in customer invoice menu and tap on Daily Journal report **Below mentioned traceback…
**Step to reproduce**
1. createdb with installing l10n_co_reports in 18.0
2. and install web_studio
3. open studio in customer invoice menu and tap on Daily Journal report
**Below mentioned traceback is rasing**:
for fixing it adding in blacklist report so it won't show in studio as I have checked in this [commit](https://github.com/odoo/enterprise/commit/e7efdb09742c434f1f72ec9c8f619038c470b464) the purpose this report to show the report using accounting report
```
Traceback (most recent call last):
File "/home/odoo/odoo/odoo/18.0/odoo/http.py", line 1963, in _transactioning
return service_model.retrying(func, env=self.env)
File "/home/odoo/odoo/odoo/18.0/odoo/service/model.py", line 156, in retrying
result = func()
File "/home/odoo/odoo/odoo/18.0/odoo/http.py", line 1930, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/odoo/odoo/18.0/odoo/http.py", line 2178, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/odoo/odoo/18.0/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/odoo/odoo/18.0/odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/odoo/enterprise/18.0/web_studio/controllers/report.py", line 499, in load_report_editor
report_qweb = self._get_report_qweb(report)
File "/home/odoo/odoo/enterprise/18.0/web_studio/controllers/report.py", line 636, in _get_report_qweb
render_context = report_safe_cr._get_rendering_context(report_safe_cr, [0], {"studio": True})
File "/home/odoo/odoo/enterprise/18.0/web_studio/models/ir_actions_report.py", line 44, in _get_rendering_context
ctx = super()._get_rendering_context(report, docids, data)
File "/home/odoo/odoo/odoo/18.0/addons/account/models/ir_actions_report.py", line 94, in _get_rendering_context
data = super()._get_rendering_context(report, docids, data)
File "/home/odoo/odoo/odoo/18.0/odoo/addons/base/models/ir_actions_report.py", line 1105, in _get_rendering_context
data.update(report_model._get_report_values(docids, data=data))
File "/home/odoo/odoo/enterprise/18.0/l10n_co_reports/report/libro_diario_report.py", line 17, in _get_report_values
report = self.env['account.report'].browse(options['report_id'])
TypeError: 'NoneType' object is not subscriptable
```
opw-4608924
upg-2733166This fix restores the reconnect option for disconnected credit card journals that already have transactions. It helps users resume online synchronization without manual workarounds, reducing disruption in credit card reconciliation.
Original PR description
Currently, when a credit card journal gets disconnected, and has some transactions, the reconnect button won't appear. This is caused by the condition for `display_connect_bank_in_dashboard` added in ae3ec22b6ec64f4600b5a11db2ffda5256bb75fd to omit the 'credit' type journal. Changing this condition to account for 'credit' type journals allows the reconnect button to appear on credit journals that have transactions. opw-4654051
Fixes an issue that could cause errors when retrieving contact details from a point-of-sale order in the WhatsApp POS integration. This keeps the existing standard behavior and helps avoid interruptions in related messaging workflows.
Original PR description
Before this commit, calling `_mail_get_partners` on a `pos.order` record would raise an error due to the missing `introspect_fields` argument in the overridden method. Additionally, overriding this method was unnecessary, as the parent implementation already provides the correct behavior. opw-4713552
Users can now find existing contacts by typing part of their email address when sharing documents. This makes it easier to select the right recipient and avoids failed sharing attempts when the contact name does not match the email being searched.
Original PR description
Reproduce: 1. Create a partner with name "TEST" and email "bob@there.com". 2. Try to share a document using "bob" to find the partner. 3. It doesn't show up, you can't select them. Partners should be findable by their email when trying to share documents with them. Task-4656596