Daily updates from Odoo
Thursday, June 27, 2024
22 changes
6 changes
Resolved issues and error corrections
Reloading a product page opened from Physical Inventory no longer causes an error page. This prevents an avoidable interruption for inventory users and keeps navigation stable during stock checks.
Original PR description
When the customer opens the product from Physical Inventory and tries to reload the page, a traceback will appear. Steps to reproduce the error: - Go to Inventory > Operations > Physical Inventory -…
When the customer opens the product from Physical Inventory and tries to reload the page,
a traceback will appear.
Steps to reproduce the error:
- Go to Inventory > Operations > Physical Inventory
- Open any product > reload the page
Traceback:
```
KeyError: 'views'
File "odoo/http.py", line 2254, in __call__
response = request._serve_db()
File "odoo/http.py", line 1829, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1849, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1827, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1834, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2059, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/action.py", line 90, in load_breadcrumbs
name = act['display_name'] if any(view[1] != 'form' and view[1] != 'search' for view in act['views']) else None
```
https://github.com/odoo/odoo/blob/a0af91d2a7fbf22b610240497a791fa6cb63cc25/addons/stock/models/stock_quant.py#L390-L398
Here, 'views' key is missing in the action.
When the user refreshes the page, 'load_breadcrumbs' method will be called here.
https://github.com/odoo/odoo/blob/afb35b9ea5392eb097e4fc7689cb98a64396aef9/addons/web/controllers/action.py#L90
In the action, 'views' key is not present.
so it will give the above traceback.
Earlier, if the 'views' key was not present in the action, It worked fine.
because 'view_id' was enough for the action.
since 'load_breadcrumbs' method, if 'views' key is not present in the action,
It will give the above traceback.
sentry-5132471164
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue where serial or lot numbers disappeared from the Lots/Serial Numbers view after products were shipped to customers. Businesses can now keep visibility of tracked items even when they are moved to customer locations without an assigned company.
Original PR description
Problem --- After shipping them to customers, lots do not appear in the `Inventory > Products > Lots/Serial Number` view Steps --- * enable stock locations in setting * create a product tracked by unique serial * make an inventory adjustment so we have at least 1 of it * create sale order for this product, confirm it * go to corresponding delivery, validate it * go to `Inventory > Products > Lots/Serial Number` => the lot is not there opw-3969556
This fix ensures that when the Point of Sale system requests only selected information, existing record details are preserved instead of being overwritten with incomplete data. This helps avoid missing information in POS workflows and improves reliability for users.
Original PR description
Before when read or search_read was called on a model with specific fields, the server was returning only these fields which is normal. But when data_service was loading these fields, it was replacing the old record with the new one, which was missing all the other fields. This commit fixes this by updating only the fields that were returned by the server when there is specific fields in the context. taskId: 4005114
This update fixes several internal test helpers used by Odoo's web module, making automated tests better reflect real user screens and behavior. It improves confidence that calendar views, date-time validation, relationship handling, and breadcrumb loading work correctly before changes reach users.
Reloading an Inventory traceability report now preserves the needed context, so users no longer see an incorrect “No operation made on this lot” message when operations exist. This also helps browser reload, back, and forward navigation keep reports and pages in sync.
Original PR description
- In the Inventory app, go to Lots/Serial Numbers; - Open any record; - Click on the Traceability stat button; - reload the page; Before this commit, the message "No operation made on this lot." was…
- In the Inventory app, go to Lots/Serial Numbers; - Open any record; - Click on the Traceability stat button; - reload the page; Before this commit, the message "No operation made on this lot." was shown, even if there are operations. This occurs because the TraceabilityReport lost the current model at reload (active_model). Since [1] a new prop (a function called updateResId) was give to the controllers components of the window actions to update the resId on the action state and url, when needed. For instance, the form view after saving a new record, will update the state and the url with the newly created id. Since [2], the prop was also given to the controllers components of the client actions to update the resId. There is a need to update more than the resId. This PR will introduce a new prop with the aim to update the action state (updateActionState). This props will allow the controller components to update the state and push the new state to the router (updating the url). In practical, this allows to push a new state in the url, keeping the action service in sync. This synchronization between the router and the action service allows the browser back/forward/reload to work as expected. Now, the TraceabilityReport can update the state, to add the active_model to the url (as a query param), and be able to restore the full state at reload. [1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f [2]: https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe
This fixes an error that could appear after opening a dialog from an employee record and then returning through the breadcrumb. Users can now close those dialogs and navigate back normally without seeing an “Invalid controller to restore” crash.
Original PR description
- Open the Employees app;
- Open the record of an employee, that have the onbording plan link in
the chatter (for instance Abigail Peterson in runbot);
- Click on the onbording plan;
- Close the onbording plan dialog;
- Click on the Employees link in the breadcrumb to came back to the
employees multi-record view;
Before this commit, a traceback was raised : `Invalid controller to
restore`. This issue occurs because when we load from a link/URL
(loadState), the controllers list is updated from the actions found in
the URL, this is done to be able to recreate the controllers (the
breadcrumb) from the URL.
This behavior is correct when the action has a target other than “new”
(i.e., when it's not a dialog). In the case of a target "new" (a dialog)
the controllers shouldn't be modified, to be able to interact with the
breadcrumb when the dialog is closed.
Now, only when the action has a target different from "new", the
controllers are updated from the URL.3 changes
Resolved issues and error corrections
This fixes how subscription-related sales permission checks are tested by placing them with the module where they belong. It helps keep validation reliable for subscription sales and stock flows without changing day-to-day user behavior.
Original PR description
Related: odoo/enterprise#60912 https://github.com/odoo/enterprise/pull/65331/files#r1651151330
This update corrects an internal planning calendar test so it checks the expected event end time consistently. It also fixes the test setup to use a defined timezone, reducing false test failures caused by different machine settings.
Original PR description
Before this commit, a planning calendar test was wrong. In this test, we resized two events to make them end at 14:30 but then check that they end at 15:30 which is inconsistent. This commit adds a mockDate with a defined timezone which will prevent the test to depend on the machine local timezone.
The reporting option to hide lines with zero amounts now ignores informational text columns such as VAT numbers or countries. This helps users keep financial reports focused on meaningful amount-based entries without being blocked by non-financial details.
Original PR description
Some reports display some informational columns (like the VAT for a partner, or the country of origin). These columns sometimes prevent the `Hide Lines at 0` option to correctly do its work: the desired behavior of this option is to hide the lines where the amounts are null. It shouldn't care about the "informational" columns, that are usually always present This commit force the `Hide Lines at 0` feature to ignore columns displaying information other than float, integer of monetary ones. task-4006235
13 changes
Resolved issues and error corrections
This update corrects rounding calculation errors in the Belgian payroll system that were affecting representation fee calculations. The fix ensures that volatile representation fees are calculated and rounded correctly, preventing discrepancies in employee payslips and financial records.
Original PR description
Forward-Port-Of: odoo/enterprise#65605 Forward-Port-Of: odoo/enterprise#65585
Employees were receiving duplicate timesheet reminder emails when they had records across multiple companies. This fix ensures that reminder emails are only sent to employees within their respective company, eliminating unnecessary duplicate messages. For example, an employee with records in 4 companies will now receive 4 emails instead of 16.
Original PR description
Duplicate emails were being sent out to employees because employees were being searched from user ids for each company, but each search was not filtered by the company. So if there was a user that had multiple employee records, all of their employee records on every company would be pulled up for every company on their database that had timesheet notifications on. For example if there were 4 companies and the employee had an employee record for each of them they would receive 16 emails in total. 4 for each employee record. Adding to the search domain to only look for employees on the current company defined by the for loop avoids these duplicate emails. This is similar to a fix that was done on the manager notification emails here: https://github.com/odoo/enterprise/pull/52808 opw-3748426 Forward-Port-Of: odoo/enterprise#64291
This fix resolves a crash that occurred when creating subscription alerts with the "Create next activity" action while leaving the due date type field blank. The system now properly handles alerts without a specified date range type, allowing users to complete their alert configuration without encountering errors.
Original PR description
Steps to reproduce: - Install "Subscriptions" - Go to "Configuration" -> "Alerts" - Create a new alert: - Add a name for the alert - Action: Create next activty - Trigger On: Modification - Activtiy: To Do - Add a summary - Add a note - Due Date In: 1 - Due Date type: Put it blank Issues: When triggered the action will result in a traceback due to `activity_date_deadline_range_type`. https://github.com/odoo/odoo/blob/9a62d0c82cdc47718181aed36cad763499b4a51d/addons/mail/models/ir_actions_server.py#L123-L124 [Linked PR](https://github.com/odoo/odoo/pull/168043) opw-3946293 Forward-Port-Of: odoo/enterprise#63816
Fixed a bug where the trash workspace in Documents was showing "undefined" for the number of days before items are permanently deleted. Users will now see the correct deletion days value even after updating the setting in Documents Settings.
Original PR description
## How to reproduce: 1. Go to Documents > Settings > Change the deletion days of docs. (Optional) 2. Go to Documents > Trash #### Issue - The Deletions Days shown 'undefined'. It says: 'Items in trash will be deleted forever after undefined days.' ## After this commit: Deletions Days will be shown there even after you update them. Task-3984627
The Cash Flow Statement report was incorrectly including accounts that are not bank or credit card accounts. This fix ensures that only accounts designated as cash or credit card type are included in the report, preventing non-financial accounts from appearing in the statement.
Original PR description
**Steps to reproduce:** - Install account_reports - Go to "Accounting / Accounting / Journals / Journal Entries" - Create a new entry: * Accounting Date: [a date from last month] * Journal Items: [2…
**Steps to reproduce:** - Install account_reports - Go to "Accounting / Accounting / Journals / Journal Entries" - Create a new entry: * Accounting Date: [a date from last month] * Journal Items: [2 lines using accounts that are not of type "asset_cash" or "liability_credit_card"] - Post the entry - Create a journal: * Type: Miscellaneous * Default Account: [one of the accounts used for the created entry] - Go to "Accounting / Reporting / Statement Reports / Cash Flow Statement" **Issue:** The default account from the newly created misc journal appears in the report even if it is not a bank-type (or cash-type) account. **Cause:** Previously, only account moves from a bank or a cash journal were taken into account in the report. The default account of these journals is forced to "asset_cash" type. However, a fix has been made to allow some account moves from miscellaneous journals, which can have any type of account as default account. **Solution:** Only allow default accounts having "asset_cash" or "liability_credit_card" as type. opw-3867312
This fix prevents users from accidentally sending duplicate delivery guides when retrying after a connection error. Previously, the system would clear the ticket number on any error, forcing a new submission on retry. Now, the ticket number is preserved for connection errors, allowing the system to retrieve the existing delivery guide status instead of creating a duplicate.
Original PR description
Currently, if there is a connection error while retrieving the CDR, we clear the ticket number. This will cause the user to send a duplicate delivery guide if he clicks on 'Retry', which is not what we want. Instead, we should keep the ticket number in all error cases except explicit rejection from SUNAT, so that a retry will try to retrieve the CDR again using the existing ticket number. [link to API docs](https://cpe.sunat.gob.pe/sites/default/files/inline-files/ServicioREST_GRE-SEECont_v1.2_0.xlsx) opw-3757843 Forward-Port-Of: odoo/enterprise#65352
This fix resolves an issue where credit notes generated for global invoices in Mexican POS systems would fail validation if created more than 72 hours after the original order. The system now uses the current date for credit note creation instead of the original order date, ensuring compliance with Mexican tax authority (CFDI) validation requirements.
Original PR description
With an MX company Enable QR on POS ticket receipt Open POS session Make 2 orders without customer or invoice (save qr of a receipt) Close POS Session Go to Orders, select the 2 orders Click Actions > Create Global Invoice (After a few days) Open QR link and validate invoice Issue: Credit note CFDI validation will fail In this flow the system first issue a global invoice, then when a customer ask the invoice a credit note for the global invoice needs to be generated with the new invoice. Currently the system uses the original pos order date as credit note date and this will fail validation if the order has been created before 72 hours ago
This fix resolves a memory error that occurred during system upgrades when calculating outstanding amounts for customers with very large numbers of transactions. The issue affected the account follow-up feature when processing partners with hundreds of thousands of transaction records, causing the system to run out of memory. The fix optimizes how these calculations are performed to handle large datasets more efficiently.
Original PR description
During upgrade `_compute_total_due` method calculate for `total_due` and `total_overdue`, with too many move lines, so raises MemoryError queries: ``` jard_1413607=> select partner_id, count(id)…
During upgrade `_compute_total_due` method calculate for `total_due` and `total_overdue`,
with too many move lines, so raises MemoryError
queries:
```
jard_1413607=> select partner_id, count(id) total_move_lines from account_move_line where partner_id is not null group by partner_id order by total_move_lines desc limit 5;
partner_id | total_move_lines
------------+------------------
1905 | 547530
1371 | 288578
1396 | 18423
3223 | 10945
1244 | 6988
```
traceback:
```py
Traceback (most recent call last):
File "/tmp/tmpj_23hd3k/migrations/testing.py", line 208, in test_check
self.check(value)
File "/tmp/tmpj_23hd3k/migrations/base/tests/test_mock_crawl.py", line 151, in check
self.assertFalse(diff, msg)
AssertionError: [('account.menu_action_move_journal_line_form', 125, 'Accounting > Accounting > Journals > Journal Entries', 205), ('purchase.menu_procurement_management_supplier_name', 247, 'Purchase > Orders > Vendors', 218), ('account.menu_account_customer', 115, 'Accounting > Customers > Customers', 217), ('account.menu_action_move_out_refund_type', 111, 'Accounting > Customers > Credit Notes', 207), ('account.menu_account_supplier', 122, 'Accounting > Vendors > Vendors', 218), ('account.menu_action_move_out_invoice_type', 110, 'Accounting > Customers > Invoices', 206), ('account.menu_action_move_in_refund_type', 118, 'Accounting > Vendors > Refunds', 209), ('account.menu_action_account_moves_all', 126, 'Accounting > Accounting > Journals > Journal Items', 204), ('account.menu_action_move_in_invoice_type', 117, 'Accounting > Vendors > Bills', 208), ('sale.res_partner_menu', 179, 'Sales > Orders > Customers', 217), ('point_of_sale.menu_point_of_sale_customer', 461, 'Point of Sale > Orders > Customers', 217)] is not false : At least one menu or view working before upgrade is not working after upgrade.
('account.menu_action_move_journal_line_form', 125, 'Accounting > Accounting > Journals > Journal Entries', 205):
Traceback (most recent call last):
File "/tmp/tmpj_23hd3k/migrations/base/tests/test_mock_crawl.py", line 252, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpj_23hd3k/migrations/base/tests/test_mock_crawl.py", line 409, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpj_23hd3k/migrations/base/tests/test_mock_crawl.py", line 438, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3538, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3749, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6590, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1207, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1389, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/base_automation/models/base_automation.py", line 745, in _compute_field_value
return _compute_field_value.origin(self, field)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4867, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/odoo/17.0/addons/stock_landed_costs/models/account_move.py", line 19, in _compute_landed_costs_visible
account_move.landed_costs_visible = any(line.is_landed_costs_line for line in account_move.line_ids)
File "/home/odoo/src/odoo/17.0/addons/stock_landed_costs/models/account_move.py", line 19, in <genexpr>
account_move.landed_costs_visible = any(line.is_landed_costs_line for line in account_move.line_ids)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3775, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3825, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3930, in _fetch_query
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1108, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
```
Failed request: UPG-1403488
Ticket: 3797437This update adds French language support to the checkout process for customers in Mexico using the ecommerce platform. Previously, customers selecting French would see English text during checkout, creating a poor user experience. The fix translates customer-facing elements while leaving technical invoicing terms in their original language to avoid duplicating translations across multiple Mexico localization modules.
Original PR description
This module adds user facing elements to ecommerce (i.e. the Website > Shop). This results in part of the checkout process showing up in English when customers are using a language other than Spanish. We make an exception for translating a localization into a language other than the one spoken in the country it's specific to because this is customer facing (i.e. in the website) and we do not want to restrict the language of the potential ecommerce customers. Unfortunately some of the terms that show in the extra step added by this model are defined in other `l10n_mx_*` modules and since we don't want to have to track down only these specific terms or translate all of the Mexico localization into French, we leave some parts untranslated (specifically the invoicing specifics) opw-3881171
This update fixes how the bank statement import system processes transaction type information from bank files. The system now properly handles cases where transaction type data uses different capitalization formats, making the import process more reliable and preventing potential errors when processing bank statements from various sources.
Original PR description
The issue: Our code generally assumes that strings are uppercase, which is typically true. However, in some cases, such as the one described in this ticket, the input string is only capitalized (the first character in uppercase). The Fix: convert the keys to uppercase before retrieving their values from the array, and use the get method instead of the bracket notation for safer access. opw-3979945 Forward-Port-Of: odoo/enterprise#64887
When users replace an attachment in the Documents module, the new file now correctly maintains its link to the original product or record. Previously, replacing a file would break the connection between the document and the product it was attached to, making it difficult to track which product the updated file belonged to.
Original PR description
Steps to reproduce: ------------------- - Install `Documents` and `Inventory` (for test purpose) modules - Go to Settings and enable `Centralize files attached to products` - Go to Inventory > Products > Choose any product - Add an attachment to the Product - Go to Documents, then select the `Products` workspace - Select document related to product just uploaded - `Replace` the attachment with a new one (old one should be added to `History`) Issue: ------ The new attachment, and therefore the document, is not related to the product anymore. Cause: ------ When uploading a new attachment, we link the attachment to the document, and we don't keep the related record. Solution: --------- Keep the related record on the new attachment and remove it from the old attachment to not have all versions of the attachments displayed on the attachments of the products. opw-3932497 Forward-Port-Of: odoo/enterprise#64530
This fix resolves a technical issue where appointment durations entered in hours and minutes format (like 1:50) were causing scheduling failures and 404 errors. The system was converting these durations to decimal numbers, which created precision problems. The fix ensures appointment scheduling works correctly regardless of the duration format entered.
Original PR description
[FIX] appointments: precision issue in appointment durations Representing duration given in HH:MM as fractions of an hour (i.e. as float) causes precision issues. Added comparia [Reproduce] - Install website_appointment - Open an appointment, modify "Appointment Duration" to 1:50 - Open preview for the appointment, try scheduling a slot - BUG: 404 opw-3914117 Forward-Port-Of: odoo/enterprise#65170 Forward-Port-Of: odoo/enterprise#63335
The Marketing Automation template form was displaying a duplicate button that wasn't functional or needed. This update removes that button from the interface, cleaning up the user experience and reducing confusion about available actions.
Original PR description
Before this PR: In Marketing Automation, upon opening a template form view, a duplicate button is displayed which won't be used. After this PR: Duplicate button is now hidden. Task - 3994775