Thursday, June 27, 2024
22 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
6 changes
Enhancements to existing features
When Mexican e-invoicing providers Quadrum or Finkok return an error, users will now see the detailed explanation instead of only a generic message. This should make it easier for businesses to understand and resolve invoicing issues without extra support investigation.
Original PR description
'Mensaje' only contains a generic error message. 'ExtraInfo' contains the actual explaination for the error so this field should be shown to the user task-3876805
12 changes
New functionality added to Odoo
Odoo now includes financial reporting capabilities for Tanzania, with the addition of balance sheet and profit & loss statements tailored to Tanzanian accounting requirements. This enables businesses operating in Tanzania to generate compliant financial reports directly within Odoo.
Original PR description
Added the balance sheet and profit loss statements to Tanzania localization package. task-3783153
Document settings now include a dedicated Trash Management section, making deletion delay options easier to find and understand. Related document integration settings are also arranged in two columns, improving readability for users configuring document workflows.
Original PR description
- This commit enhances document organization by relocating 'Deletion Delay' under the newly created 'Trash Management' section in Settings. - Also, adjusted the Settings UI so that the bridge options now appear in two columns instead of a single column. Task-3918898
Attendees who open a cancelled appointment now see a clear cancelled event page instead of potentially seeing an outdated booking page. The appointment page is also forced to reload when using browser navigation, reducing confusion after a booking is cancelled.
Original PR description
This PR provides a cancelled front page to attendees who access an event that has been cancelled. - As inline-block elements cannot directly inherit the 'text-decoration' property from the parent, we change `<label>` to `<span>` tags in the template. - When the user books an appointment, immediately cancels it, and uses the browser navigation to go back, the page should load with the cancelled event. - We prevent the browser from caching the page, so it reloads every time we navigate with browser navigation. Task-3959537
The reporting date filter now supports moving into future periods, making forecasts and upcoming-period analysis easier. Related report definitions and tests were updated so period labels and comparisons work consistently for both past and future dates.
Original PR description
This commit will add the possibility to go in the future with the date filter added with this commit: https://github.com/odoo/enterprise/commit/37224239a4f4309ce3453988313750d9e0c83f6c To do that: - Change the order of the period, before when going in the future the period would go in negative. We now do the opposite. - Change previous_period with just period since we can now go in the future - Remove last_period task-3961087 community pr: https://github.com/odoo/odoo/pull/168875
Pricer tags can now be linked to products directly from the Pricer Store form by scanning the product barcode and then the tag barcode. This speeds up store setup work and gives users immediate success or error notifications after each pairing attempt.
Original PR description
Currently, the process of linking a Pricer tag to a product is a very slow and tedious procedure. This PR adds the possibility to quickly connect the products to the pricer tags through the Pricer Store form view The user needs to scan the product barcode, then the Pricer tag barcode and Odoo will automatically create the link between the two Odoo notification system will notify the user of the succesful link between the two or an error otherwise  task-3619639
Appointment flows now show prices with tax included when the administrator has configured the website to display tax-included prices. This keeps appointment pricing consistent with the rest of the website and helps customers see the expected total more clearly.
Original PR description
If the admin configures prices to be displayed with tax included(https://tinyurl.com/225pkohb) Include tax in the prices present in Appointment flows.(https://tinyurl.com/28zuxok4) Task-3898034
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