Thursday, November 23, 2023
13 changes · 17.0
Resolved issues and error corrections
This change updates Odoo's mail and chat handling to improve thread behavior and related chat window tests. It likely makes messaging interactions more consistent for users, though the PR description does not provide detailed business context.
Original PR description
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
The chatter panel now avoids reloading unnecessarily when users make changes in a form that has not been saved. This reduces extra background requests and should make form editing feel smoother, especially on records with active communication history.
Original PR description
This RPC /mail/thread/data is called on every form view change, even when not saved. It comes from the chatter onWillUpdateProps and calling `load` then `fetchData` We don't want to reload chatter when every time props updates. Do it when the record `onWillLoadRoot` Task: 3569123 https://github.com/odoo/enterprise/pull/50607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves how customer names are displayed in the POS restaurant table view when appointments are booked. The system now correctly shows the actual customer name (from the appointment booker) instead of displaying auto-generated appointment names, making the table view cleaner and more user-friendly for restaurant staff.
Original PR description
We should use the appointment_booker_id before falling back on the appointment name when displaying the customer name. When the appointment is taken from the frontend an appointment_booker_id is set on the calendar event created. This should be use to display the customer name on the POS table view. In case the appointment is created from the backend, we fallback on the name set on the event. This fix also avoid to display the long name automatically created when booking an appointment from the frontend.
This update prevents the email conversation panel from reloading unnecessarily every time you switch between form views, even when you haven't saved your changes. Previously, the system would fetch conversation data on every view change, which was inefficient. Now it only loads the data when actually needed, improving performance and reducing server requests.
Original PR description
This RPC /mail/thread/data is called on every form view change, even when not saved. It comes from the chatter onWillUpdateProps and calling `load` then `fetchData` We don't want to reload chatter when every time props updates. Do it when the record `onWillLoadRoot` Task: 3569123
This fix resolves an error that occurred when adding or updating options for selection fields in editable sign templates. The issue was caused by a change in how Odoo 17.0 handles option data compared to the previous version. Users can now successfully add and modify selection field options without encountering errors.
Original PR description
Issue: ====== When you add a new selection sign item in a template and add new options or update them it will raise an error. Steps to reproduce the error: ============================= - Open any editable sign template - Add a selection field - Click on the selection field - Add new option in the options field Origin of the error: ==================== In saas-16.4 option_ids contains a `REPLACE_WITH` command which is an array of length 3 of this format `[SET, _, ids]` so each time we set the new options with the new ids. In 17.0 option_ids contains a list of `LINK` command where each one have an id to link , so we will have an array of commands each of this format `[LINK, id, _]` that's why the old code doesn't work anymore. Solution: ========= We get all the ids of the `LINK` commands opw-3596542
This fix corrects how date ranges are applied when auditing financial report lines that use cross-report calculations. Previously, the system was using incorrect date information when drilling down into aggregated data, which could show inaccurate audit trails. The fix ensures the correct date scope is used during the audit process.
Original PR description
When auditing a line with a subformula of `cross_report and an engine `aggregation the domain returned in `_get_audit_line_domain` will not have the correct `date_scope`. When we loop trough `expression._expand_aggregations()` the date_scope that we use on `audit_or_domains` should be the one of the expression **if** it has a subformula `cross_report` and not the one on the `expression_to_audit`. Task-id 3531220 Forward-Port-Of: odoo/enterprise#51064 Forward-Port-Of: odoo/enterprise#50153
This update fixes an issue where shipping labels could not be generated for deliveries to Mexico when using UPS with EasyPost integration. The system now includes a product description in the shipment details as required by Mexico's Carta Porte regulation, allowing labels to be created successfully.
Original PR description
Steps to reproduce: 1. Set up UPS with EasyPost shipping integration 2. Make a shipping with destination in Mexico 3. Attempt to validate the delivery Get an error message: `"EasyPost returned an error : A package in a Mexico shipment must have a Merchandise description"` Based on new Carta Porte regulation in Mexico, (See https://www.easypost.com/blog/2023-02-13-all-you-need-to-know-about-the-new-ups-carta-porte-regulation) EasyPost enforces some carriers to have `contents_explanaton` field. This field is a package-level description of the shipment. This commit uses a truncated list of product names to this field so that the labels can be generated. opw-3555670 Forward-Port-Of: odoo/enterprise#50856 Forward-Port-Of: odoo/enterprise#49546
This fix resolves a JavaScript error that occurred when warehouse staff scanned a source location with no remaining inventory during manufacturing order barcode operations. The update enables consistent location confirmation behavior across picking and manufacturing workflows, allowing users to seamlessly switch between warehouse locations when scanning components.
Original PR description
This commit does 2 things: - avoids an error occurring when scanning a source location that has no (remaining) reserved qtys at that location to scan. Issue was due to:…
This commit does 2 things:
- avoids an error occurring when scanning a source location that has no
(remaining) reserved qtys at that location to scan. Issue was due to:
https://github.com/odoo/enterprise/blob/61d3aa2d4ba7540803b88ca4f426e6ee6503e8dd/stock_barcode/static/src/models/barcode_picking_model.js#L165
still being used by barcode_mrp_model, but this.needSourceConfirmation
is set to `false` in the mrp model, so an error is thrown because
booleans don't have an index. Originally it was thought this
(picking) feature wasn't wanted for MOs, but this has been
reconsidered and we now want it (afterall, it is better to have
consistent behavior).
Note that in order to add this check in, the _createNewLine in MOs had
to be adjusted so that the assignment of the final product for an MO
created from scratch occurred before the check:
https://github.com/odoo/enterprise/blob/57986a41fb80deecd7c4d2a374afa801bc44a507/stock_barcode/static/src/models/barcode_picking_model.js#L51
because the this.location will throw a cache error due to there being
no default location to find (i.e. there are no locations for the MO
yet). No tests were added for this because existing tours already
failed when creating MOs from scratch.
Steps to reproduce:
- activate multi-locations + set barcode setting for manufacture
picking type: `restrict_scan_source_location`=`mandatory`
- create 2 products, 1 with stock in WH/Stock, the other with stock in
WH/Stock/Shelf 1, both with barcodes
- create MO using those 2 products + reserve
- open MO in barcode, scan "Shelf 1" barcode + scan component in that
loc
- scan "WH/Stock"
expected result: should switch source locations + should be able to
scan the other component
actual result: JS error
- adds in a test to avoid the same mistake that is fixed in the COM PR
of this branch. Existing test has been redone so the test includes:
+ the above location switching scanning (to scan a non-reserved
component)
+ the mandatory consumption check
+ the original test of scanning a diff lot than the one already
reserved
COM PR: https://github.com/odoo/odoo/pull/142933The 'My Performance' text in the Helpdesk dashboard was being cut off and hidden on mobile devices, particularly on foldable phones like the Galaxy Fold. This fix reorganizes the dashboard layout by adding a new row for the 'My Performance' text, ensuring it displays properly and remains fully visible on all mobile screen sizes.
Original PR description
Steps: - Open Helpdesk. - Go to mobile view. - Check for galaxy fold. Issue: - The 'My Performance' text gets cut and some part gets hidden. Cause: - The text is too long. Fix: - We are adding a new row in the table for 'My performance' text. task-3392129 Forward-Port-Of: odoo/enterprise#43490
This update fixes a bug where the "see pivot properties" option was not appearing when users right-clicked on pivot cells in spreadsheets. This menu item is now properly displayed, allowing users to access pivot properties as intended.
Original PR description
The cell menu item `see pivot properties` was not displayed when right clicking on a pivot cell. Task: [3557299](https://www.odoo.com/web#id=3557299&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#49024
This fix improves how the HR Recruitment module handles automatic data extraction from resumes. Previously, the system would overwrite all applicant information with OCR results. Now it only fills in empty fields, preserving any data that was already entered or previously extracted. This prevents accidental loss of important applicant information.
Original PR description
task-3595627 Forward-Port-Of: odoo/enterprise#51253 Forward-Port-Of: odoo/enterprise#50645
A bug in the Point of Sale system was preventing users from creating new partners (customer records). The issue was caused by a recent code update that didn't properly handle empty values. This fix ensures that the partner creation process works smoothly again, allowing staff to add new customers without errors.
Original PR description
Prior to this commit, inside the Point of Sale, clicking the Create button on the partner screen to create a new partner resulted in an error, preventing the creation process. This issue was traced back to the recent refactor of the 'formatFloat' function (https://github.com/odoo/odoo/commit/054ca0a19aaf297f420a1b478b93ae26f1b943b8). The refactor changed '(value || 0)' to 'value', leading to problems when the value is undefined. This commit resolves the issue by ensuring that 'undefined' values are properly handled and prevented from being sent during the partner creation process. opw-3594167
This fix resolves a crash that occurred when users tried to search for phone calls in the VoIP Recent section. The issue was caused by an incorrectly formatted search query that prevented the system from properly retrieving recent call records. With this fix, users can now successfully search and view their recent phone calls without encountering errors.
Original PR description
This traceback arises when the user tries to click on Recent in Softphone To reproduce this issue: 1. Install `VoIP` 2. Open `Discuss/Softphone/Recent` 3. Try to search for something in the Voip…
This traceback arises when the user tries to click on Recent in Softphone
To reproduce this issue:
1. Install `VoIP`
2. Open `Discuss/Softphone/Recent`
3. Try to search for something in the Voip search bar
Error:
``` ValueError: too many values to unpack (expected 3)
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 462, in call_kw
result = _call_kw_model(method, model, args, kwargs)
File "odoo/api.py", line 435, in _call_kw_model
result = method(recs, *args, **kwargs)
File "home/odoo/src/enterprise/17.0/voip/models/voip_call.py", line 85, in get_recent_phone_calls
return self.search(domain, offset=offset, limit=limit, order="create_date DESC")._format_calls()
File "odoo/models.py", line 1604, in search
return self.search_fetch(domain, [], offset=offset, limit=limit, order=order)
File "odoo/models.py", line 1627, in search_fetch
query = self._search(domain, offset=offset, limit=limit, order=order or self._order)
File "odoo/models.py", line 5366, in _search
query = self._where_calc(domain)
File "odoo/models.py", line 5081, in _where_calc
return expression.expression(domain, self).query
File "odoo/osv/expression.py", line 788, in __init__
self.expression = domain_combine_anies(domain, model)
File "odoo/osv/expression.py", line 597, in domain_combine_anies
domain_any = _anyfy_leaves(domain, model)
File "odoo/osv/expression.py", line 371, in _anyfy_leaves
left, operator, right = item = tuple(item)
```
When the user tries to search for something in the search bar an invalid domain format is formed in `get_recent_phone_call`method. Which leads to the traceback from here
https://github.com/odoo/enterprise/blob/5c42708683905cfb5fe8c1005aabbbc9fb016fa2/voip/models/voip_call.py#L79-L85
After applying this commit will resolve the issue by giving a valid domain format to search.
sentry-4644858097