Monday, October 14, 2024
19 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
Miscellaneous changes
when a field object is not _toplevel, it may be shared with multiple registries and should be readonly in any case 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#182859
Original PR description
when a field object is not _toplevel, it may be shared with multiple registries and should be readonly in any case 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#182859
Description of the issue/feature this PR addresses: sys.settrace prevents coverage.py from working properly: https://coverage.readthedocs.io/en/7.5.3/trouble.html The main cause of the problem is that when executing the SyncCollector profiler we will settrace(None). This makes the coverage result invalid since the settrace added by the coverage is not resumed. Also, it would be possible to have a similar problem with nested SyncCollector, or if any other tool/code uses sys.settrace.
Original PR description
Description of the issue/feature this PR addresses: sys.settrace prevents coverage.py from working properly: https://coverage.readthedocs.io/en/7.5.3/trouble.html The main cause of the problem is that when executing the SyncCollector profiler we will settrace(None). This makes the coverage result invalid since the settrace added by the coverage is not resumed. Also, it would be possible to have a similar problem with nested SyncCollector, or if any other tool/code uses sys.settrace. So, an error is logged when the profiler starts. Current behavior before PR: The coverage.py report doesn't correctly track which tests have been run. Desired behavior after PR is merged: coverage.py will report all the correct tests. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167379
Currently, the cron job "Base Action Rule: check and execute" has its frequency set dynamically based on the shortest delay of time based automated actions. Nevertheless, when a time based automated action has a negative delay, the frequency of the cron job is set to shortest frequency. This causes load on the server more than needed. This can be solved by adding an absolute and treating the negative delay like the a normal delay which results in more representative frequency.
Original PR description
Currently, the cron job "Base Action Rule: check and execute" has its frequency set dynamically based on the shortest delay of time based automated actions. Nevertheless, when a time based automated action has a negative delay, the frequency of the cron job is set to shortest frequency. This causes load on the server more than needed. This can be solved by adding an absolute and treating the negative delay like the a normal delay which results in more representative frequency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182799
Little improvement of bcaf8cb859dc2f7e975d180ba0fc49da20204557 as we forgot some use cases opw-4072691 Forward-Port-Of: odoo/odoo#182791
Original PR description
Little improvement of bcaf8cb859dc2f7e975d180ba0fc49da20204557 as we forgot some use cases opw-4072691 Forward-Port-Of: odoo/odoo#182791
Steps to reproduce the error 1.create a db in odoo 15.0 install hr_holiday and l10n_be_hr_payroll 2.create a leave with existing leave type from l10n_be_hr_payroll module 3.upgrade db to 16.0 the below mentioned traceback will raise traceback ```py Traceback (most recent call last): File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 698, in _tag_root f(rec) File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 599, in _tag_record record = model._load_recor
Original PR description
Steps to reproduce the error 1.create a db in odoo 15.0 install hr_holiday and l10n_be_hr_payroll 2.create a leave with existing leave type from l10n_be_hr_payroll module 3.upgrade db to 16.0 the…
Steps to reproduce the error
1.create a db in odoo 15.0 install hr_holiday and l10n_be_hr_payroll
2.create a leave with existing leave type from l10n_be_hr_payroll module
3.upgrade db to 16.0 the below mentioned traceback will raise
traceback
```py
Traceback (most recent call last):
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 698, in _tag_root
f(rec)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 599, in _tag_record
record = model._load_records([data], self.mode == 'update')
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4393, in _load_records
data['record']._load_records_write(data['values'])
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4324, in _load_records_write
self.write(values)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3806, in write
real_recs._validate_fields(vals, inverse_fields)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 1365, in _validate_fields
check(self)
File "/home/odoo/src/odoo/16.0/addons/hr_holidays/models/hr_leave_type.py", line 188, in check_allocation_requirement_edit_validity
raise UserError(_("The allocation requirement of a time off type cannot be changed once leaves of that type have been taken. You should create a new time off type instead."))
odoo.exceptions.UserError: The allocation requirement of a time off type cannot be changed once leaves of that type have been taken. You should create a new time off type instead.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/odoo/src/odoo/16.0/odoo/service/server.py", line 1310, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/16.0/odoo/modules/registry.py", line 91, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 484, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 372, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 231, in load_module_graph
load_data(cr, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 71, in load_data
tools.convert_file(cr, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 763, in convert_file
convert_xml_import(cr, module, fp, idref, mode, noupdate)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 829, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 749, in parse
self._tag_root(de)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 711, in _tag_root
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/16.0/l10n_be_hr_payroll/data/hr_leave_type_data.xml:14, somewhere inside
<record id="holiday_type_maternity" model="hr.leave.type">
<field name="name">Maternity Time Off</field>
<field name="requires_allocation">no</field>
<field name="leave_validation_type">no_validation</field>
<field name="request_unit">half_day</field>
<field name="color_name">lavender</field>
<field name="leave_notif_subtype_id" ref="hr_holidays.mt_leave"/>
<field name="work_entry_type_id" ref="work_entry_type_maternity"/>
<field name="icon_id" ref="hr_holidays.icon_11"/>
<field name="company_id" eval="False"/>
</record>
```
why this traceback is raised because while loading ``l10n_be_hr_payroll`` moduel this data file will load during that if record is noupdate false then it will go for write call so in that requires_allocation will also go for write call even the value is same. So, the newly introduced [``constraints``](https://github.com/odoo/odoo/commit/33da34b842f2fe700efaf55915d4cb9828e139d7) will trigger and check if any record
of leave is present with the that leavetype constraint will trigger .For fixing this issue pop the value of ``requires_allocation`` if the values are same otherwise record is modified by user.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#182533To avoid confusion, the field previously labeled as 'Purchase Order' has been renamed to 'Purchase Order Warning'. This clarifies that the field relates to triggering purchase warnings, not managing purchase orders themselves. This change only affects the field label, ensuring consistency in user expectations without altering the filter content or behavior. OPW-4141054 Forward-Port-Of: odoo/odoo#180176
Original PR description
To avoid confusion, the field previously labeled as 'Purchase Order' has been renamed to 'Purchase Order Warning'. This clarifies that the field relates to triggering purchase warnings, not managing purchase orders themselves. This change only affects the field label, ensuring consistency in user expectations without altering the filter content or behavior. OPW-4141054 Forward-Port-Of: odoo/odoo#180176
Steps to reproduce ====================== Go to the user profile. Click on tags. You will be redirected to the courses instead of redirecting to the tags. Technical ========== Click event is there on the whole card as our tags are inside the card so the click event of a parent is triggering instead of the child. and we are redirected to the course page. After this PR =========== We will be redirected to tags when clicking on tag. Task-4203676 Forward-Port-Of: odoo/odoo#183079 F
Original PR description
Steps to reproduce ====================== Go to the user profile. Click on tags. You will be redirected to the courses instead of redirecting to the tags. Technical ========== Click event is there on the whole card as our tags are inside the card so the click event of a parent is triggering instead of the child. and we are redirected to the course page. After this PR =========== We will be redirected to tags when clicking on tag. Task-4203676 Forward-Port-Of: odoo/odoo#183079 Forward-Port-Of: odoo/odoo#181499
Backport of #127118 Close #183360 Forward-Port-Of: odoo/odoo#183461
Original PR description
Backport of #127118 Close #183360 Forward-Port-Of: odoo/odoo#183461
The active flag [can be included](https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/stock_warehouse.py#L259-L277) in the values to update when calling function `_create_or_update_sequences_and_picking_types`, for example [during upgrades](https://github.com/odoo/upgrade/blob/master/migrations/stock/saas~17.3.1.1/end-migrate.py#L16). This will raise the Validation Error even if the flag is being kept as active. upg-2034998 Forward-Port-Of: odoo/odoo#180292
Original PR description
The active flag [can be included](https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/stock_warehouse.py#L259-L277) in the values to update when calling function `_create_or_update_sequences_and_picking_types`, for example [during upgrades](https://github.com/odoo/upgrade/blob/master/migrations/stock/saas~17.3.1.1/end-migrate.py#L16). This will raise the Validation Error even if the flag is being kept as active. upg-2034998 Forward-Port-Of: odoo/odoo#180292
In a previous commit, I changed a line who reverted this fix: https://github.com/odoo/enterprise/commit/c756ee72f9f0c3a6badf56779de4b7c50da9ed4e As this wasn't the goal of my fix, and it's still working without this change, I reverse this change to his previous state. linked: https://github.com/odoo/enterprise/commit/5e09e50e8c6248afaed76dff6875d1c85996009d no-task Forward-Port-Of: odoo/enterprise#71845
Original PR description
In a previous commit, I changed a line who reverted this fix: https://github.com/odoo/enterprise/commit/c756ee72f9f0c3a6badf56779de4b7c50da9ed4e As this wasn't the goal of my fix, and it's still working without this change, I reverse this change to his previous state. linked: https://github.com/odoo/enterprise/commit/5e09e50e8c6248afaed76dff6875d1c85996009d no-task Forward-Port-Of: odoo/enterprise#71845