Daily updates from Odoo
Thursday, June 27, 2024
15 changes
4 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
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
11 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 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