Monday, October 14, 2024
9 changes · 17.0
Resolved issues and error corrections
This fix prevents Odoo Studio from trying to edit temporary analytic plan fields that are not part of the saved view structure. As a result, users can customize the Analytic Items list without hitting an XPath error.
Original PR description
Steps to reproduce ================== - Install web_studio,account_accountant - Enable Analytic accounts in Accounting - Navigate to Accounting > Analytic items - Open studio - Toggle show invisible - Edit the label of the last column => Xpath `/tree/field[17]` has no match Cause of the issue ================== - x_plan_* fields are dynamically added in get_views - Studio receives those fields and expect them to be part of the original arch. It assigns xpaths to them - When making an edit, studio create an inheriting view that is applied before the x_plan fields are added. => Xpaths do not match Solution ======== When in studio, don't add x_plan_* fields opw-4210657
A small formatting issue in a Point of Sale error message was corrected by adding a missing space. This prevents the message from appearing awkwardly when shown to users, improving clarity with no functional change.
Original PR description
There is a missing space in this error message causing a display issue when it is triggered. The space has simply been added back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now avoids treating URL paths that begin with an underscore as language codes when no page or controller matches. This prevents visitors from being redirected to the wrong language, improving reliability for unusual or invalid URLs.
Original PR description
Prior to this commit, when a URL started with an underscore (_) and didn’t match any existing controller, Odoo attempted to resolve the first part of the URL as a language code.
If the first segment started with an underscore and was not a valid language code, Odoo would split at the underscore and attempt to match the empty string (''), causing it to default to the first available language.
For example, accessing https://www.odoo.com/__NULL__ on odoo.com would result in the language being incorrectly set to Arabic, and a redirection to https://www.odoo.com/ar.Product pages now correctly show reference prices for each variant, even when one variant has a base unit price of zero. This prevents valid pricing information from disappearing for other variants, helping shoppers compare products accurately.
Original PR description
**Steps:** - Create a product with two variants (e.g., Steel & White and Aluminum & White). - Enable 'Product Reference Price' in the settings. - Set the base_unit_price of the 'Steel & White'…
**Steps:** - Create a product with two variants (e.g., Steel & White and Aluminum & White). - Enable 'Product Reference Price' in the settings. - Set the base_unit_price of the 'Steel & White' variant to 0. - Go to the product page on the website and observe that the base unit price disappears for all variants, even though it should be displayed for the other variants. **Issue:** - The base_unit_price for product variants was not being displayed when the base_unit_price of one variant was set to 0. This caused the price to disappear for all variants in the template, even when other variants had valid base_unit_price values. **Cause:** The condition in the template was relying on a falsy check, which incorrectly evaluated 0 as a falsy value and prevented the display of base_unit_price for all variants, including those with valid prices. **Fix:** The condition in the template was updated to check for the existence of base_unit_price explicitly using if condition effectively. This ensures that even when base_unit_price is 0, it will still be displayed, while preventing the field from disappearing for other variants. Affected Version: 17.0~master opw-4061530
This update adjusts an internal data label used by the Italian electronic invoicing module. It helps prevent future processing issues while keeping the user-facing experience unchanged.
Original PR description
This commit will add an underscore to a dict key to avoid any problem that might arise in the future. no task id Related commit: https://github.com/odoo/odoo/commit/2f2f5f63e8d0ab9729bffa25192a7ef9a2da5fb9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The customer portal now shows the correct title on sales order cards. This avoids confusing labels for customers viewing their sales documents online and helps keep the portal experience clear.
This fix prevents an error when calculating days sales outstanding for customers whose related invoices are missing an invoice date, which can happen after migrations. It helps keep customer accounting information accessible instead of showing a server error.
Original PR description
Description of the issue/feature this PR addresses: This MR fix the error raised when a partner have related invoices without invoice_date field defined. In my case it happened after a migration.…
Description of the issue/feature this PR addresses:
This MR fix the error raised when a partner have related invoices without invoice_date field defined. In my case it happened after a migration.
This is the error trace:
```python
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
File "/mnt/odoo/odoo/odoo/http.py", line 1764, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/odoo/odoo/odoo/service/model.py", line 133, in retrying
result = func()
^^^^^^
File "/mnt/odoo/odoo/odoo/http.py", line 1791, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/odoo/odoo/odoo/http.py", line 1995, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/odoo/odoo/addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/odoo/odoo/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/odoo/odoo/odoo/http.py", line 741, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/odoo/odoo/addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/odoo/odoo/addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/odoo/odoo/odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/odoo/odoo/odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/odoo/odoo/addons/web/models/models.py", line 86, in web_read
values_list: List[Dict] = self.read(fields_to_read, load=None)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/odoo/odoo/odoo/models.py", line 3545, in read
return self._read_format(fnames=fields, load=load)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/odoo/odoo/odoo/models.py", line 3756, in _read_format
vals[name] = convert(record[name], record, use_display_name)
~~~~~~^^^^^^
File "/mnt/odoo/odoo/odoo/models.py", line 6636, in _getitem_
return self.fields[key].get_(self, self.env.registry[self._name])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/odoo/odoo/odoo/fields.py", line 1207, in _get_
self.compute_value(recs)
File "/mnt/odoo/odoo/odoo/fields.py", line 1389, in compute_value
records._compute_field_value(self)
File "/mnt/odoo/odoo/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/odoo/odoo/odoo/models.py", line 4880, in _compute_field_value
fields.determine(field.compute, self)
File "/mnt/odoo/odoo/odoo/fields.py", line 102, in determine
return needle(*args)
^^^^^^^^^^^^^
File "/mnt/odoo/odoo/addons/account/models/partner.py", line 480, in _compute_days_sales_outstanding
days_since_oldest_invoice = (fields.Date.context_today(self) - oldest_invoice_date).days
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
TypeError: unsupported operand type(s) for -: 'datetime.date' and 'bool'
The above server error caused the following client error:
OwlError: An error occured in the owl lifecycle (see this Error's "cause" property)
Error: An error occured in the owl lifecycle (see this Error's "cause" property)
at handleError (http://localhost:8069/web/assets/8c6578d/web.assets_web.min.js:916:101)
at App.handleError (http://localhost:8069/web/assets/8c6578d/web.assets_web.min.js:1545:29)
at ComponentNode.initiateRender (http://localhost:8069/web/assets/8c6578d/web.assets_web.min.js:1006:19)
Caused by: RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (http://localhost:8069/web/assets/8c6578d/web.assets_web.min.js:2886:163)
at XMLHttpRequest.<anonymous> (http://localhost:8069/web/assets/8c6578d/web.assets_web.min.js:2890:13)
```
Current behavior before PR:
This error is issued when trying access a partner that have related invoices without invoice_date field defined.
Desired behavior after PR is merged:
The error is no longer issued by the Odoo
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSending payment reminder emails with customer statements attached now handles missing statement details safely. This prevents users from encountering an error when adding Customer Statements as a dynamic report in follow-up emails.
Original PR description
Problem: If there is no `lines` traceback. Steps to reproduce: - Install `l10n_account_customer_statements`. - Navigate to: Accounting > Customers > Followup Reports. - Select any row and from the "Actions" menu, choose "Send Email." - Load the "Payment Reminder" template. - In the template settings, add "Customer Statements" under "Dynamic Reports." - Save and send the email. - Traceback. opw-4161388
This update fixes a technical issue that occurred when upgrading the Belgium and Hong Kong payroll modules with demo data. The leave type records are now marked as non-updatable to prevent constraint violations during module upgrades, ensuring smoother system updates for users in these regions.
Original PR description
The definition of these records include the field `requires_allocation`, so updating them will trigger the constraint for that field. There's already a [fix for this](https://github.com/odoo/odoo/pull/182533) but it will be interesting to still mark these records as noupdate to be coherent with all the other `hr.leave.type` records. To reproduce: - Install `l10n_hk_hr_payroll` with demo data - Upgrade the module Forward-Port-Of: odoo/enterprise#71844