Tuesday, April 9, 2024
35 changes
2 changes
Resolved issues and error corrections
Uploading a file in a newly opened live chat now works reliably instead of causing an error. The system now saves the chat on the server before starting the upload, improving the support experience for users and agents.
Original PR description
Before this PR, uploading a file to a temporary thread would lead to errors because the thread only exists locally. This PR ensures the thread is saved on the server before uploading like it's done when a message is posted. This PR adapts the attachment upload service to rely on models instead of components: - Service should not be coupled to views - Thread is updated when calling `uploadFile` so the hook passed to this function is outdated and we cannot access the new thread hook (it's not even mounted yet). Steps to reproduce the issue: - Log in as admin - Go to the live chat support page - Open a chat - Click on upload file and upload one - Crash occurs https://github.com/odoo/enterprise/pull/60165
Reloading a product page opened from Physical Inventory no longer triggers an error page. This keeps inventory workflows stable and prevents customers from being interrupted by a traceback when refreshing the browser.
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: 'display_name'
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1827, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, 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 1825, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, 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 739, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/action.py", line 74, 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/853bd97eda1f4eca5f9f63ef1c5909fddaa98d27/addons/stock/models/stock_quant.py#L388-L396
Here, 'display_name' key is not present.
https://github.com/odoo/odoo/blob/853bd97eda1f4eca5f9f63ef1c5909fddaa98d27/addons/web/controllers/action.py#L74 When Customer reloads the page,
It will try to access 'display_name' here, but it is not present.
So, It will lead to the above traceback.
sentry-5132471164
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr2 changes
Enhancements to existing features
Spreadsheet users now get visual highlights on pivot and list cells when they interact with related menu entries or side panels. This makes it easier to understand which spreadsheet area belongs to each data source and reduces navigation confusion.
Original PR description
This commit add highlights on pivot and list cells. The cells of a pivot/list are highlighted when: - the user hovers the menu item corresponding to a list/pivot - the side panel of a list/pivot is opened - the user hovers a list/pivot in datasource list side panel Task: [3571796](https://www.odoo.com/web#id=3571796&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
21 changes
New functionality added to Odoo
Odoo now supports Spanish cooperative businesses with two new chart of accounts templates: one for small and medium-sized cooperatives (SMEs) and one for larger cooperatives. This allows cooperative organizations in Spain to use accounting structures that comply with their specific regulatory requirements.
Original PR description
In Spain, "Cooperativas" have their own variant of the Spanish chart of accounts. In order to support these businesses, we add two extra CoA templates: Cooperatives - SMEs and Cooperatives - Complete. [task-3803050](https://www.odoo.com/web#id=3803050&cids=1&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The room booking interface now responds more smoothly when users create or update meetings, reducing flicker and blocking duplicate actions while changes are saved. It also makes editing clearer by recentring selected bookings and using more precise button and notification wording.
Original PR description
### 1. Avoid flicker on quick booking When using the quick booking feature in the frontend view, there is currently a flicker when the main view is restored after booking the room. This flicker…
### 1. Avoid flicker on quick booking When using the quick booking feature in the frontend view, there is currently a flicker when the main view is restored after booking the room. This flicker occurs because the view is restored before receiving the booking creation notification through the bus service. With this commit, instead of restoring the view after sending the new booking creation rpc, it is restored when the new booking notification is received. ### 2. Show booking when re selecting it from sidebar In the frontend view, when editing a booking and re-clicking on it in the sidebar, currently nothing happens. With this commit, it will discard the current modifications and recenter the view on the booking being edited. ### 3. Reword parts in the frontend view - rename "save" button to "update meeting" button when editing a booking to clarify what will happen - update content of the notification shown when the view is reset because the booking being edited has been updaed/deleted, as the current one may be confusing (if it has been updated, it would tell the user that is has been deleted while it has not). Task-3704495
This update adds full Catalan language support to Odoo's Spanish localization module. Users who configure their environment to use Catalan will now see all account names and labels displayed in Catalan instead of English, providing a better localized experience for Catalan-speaking users in Spain.
Original PR description
Description of the issue/feature this PR addresses: Add the name@ca for catalan translation at the main account plans in the spain l10n_es localization, and the l10n_es/i18n/ca.po file too. Current behavior before PR: The accounts names are in english when user configures her environment to use the catalan language. Desired behavior after PR is merged: The accounts names are in catalan. Previously clashed PR https://github.com/odoo/odoo/pull/158182 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update improves the UK HMRC tax report submission experience with four key enhancements: users now receive confirmation notifications when connecting to HMRC and when sending reports, the system automatically handles authentication issues when switching between companies, and the send button only appears when a valid tax obligation is selected. These changes reduce confusion and prevent errors during the VAT reporting process.
Original PR description
Contains four improvements for HMRC flow: 1- Successfully connecting to HMRC now shows a notification to let the user know they can send their reports. 2- The "send" button in the send HMRC wizard…
Contains four improvements for HMRC flow: 1- Successfully connecting to HMRC now shows a notification to let the user know they can send their reports. 2- The "send" button in the send HMRC wizard triggers the sending but nothing happens UI wise. Now, the wizard is closed and a confirmation notification is shown. 3- For a user wanting to submit the VAT report for two companies, after switching clicking on the "send to HMRC" button raises an error as the token does not correspond to the correct company. Before, the user had to manually remove their authentication credentials to allow for a new connection to get a new token. Now, if we get an error from HMRC that the agent isn't authorised to submit the report, we clear the credentials ourselves and redirect the user to the login page, so they could get the correct token. 4- Trying to send the report without selecting an obligation returns a traceback error. Now, the send button will not appear unless an obligation is selected. task-3696341
This update improves how Odoo handles payment registration when dealing with invoices in foreign currencies. Instead of creating write-offs, the system now intelligently uses exchange rate adjustments to fully reconcile payments without leaving unpaid balances. This simplifies accounting records and provides a cleaner financial trail for multi-currency transactions.
Original PR description
When a register payment is made with a writeoff in foreign currency and when the user set manually an exchange difference account, don't create a write-off. Instead, 2 cases to consider: - When the payment is expressed in a foreign currency different than the invoice's one, play with the rate between amount_currency and balance and let odoo making an exchange difference accordingly. That way, the payment has no write-off and the invoice is fully paid. - When the payment is expressed in company currency but the invoice has a foreign currency, force the exchange difference to use a rate that will fully paid the invoice without creating any write-off line on the payment. task_id: 3717436 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves the IoT app's log file download feature by making downloaded files more identifiable with the IoT device name and generation date included in the filename. It also adds better error handling to prevent system crashes when log file configurations are missing or files cannot be found, providing clearer feedback to users when issues occur.
Original PR description
Small improvements on the download logs button in the Iot App: - Log file contains the IoT name and date of generation - Internal server error araise if the logfile config is missing - Internal server error aised if the log file is missin Was meant to be part of: https://github.com/odoo/odoo/pull/159186 opw-3827121 Forward-Port-Of: odoo/odoo#160645
Resolved issues and error corrections
This fix improves how payment registrations are handled when dealing with invoices in different currencies. Instead of creating write-offs, the system now intelligently uses exchange rate adjustments to fully reconcile payments without leaving unpaid balances. This ensures cleaner financial records and more accurate payment processing for businesses operating with multiple currencies.
Original PR description
When a register payment is made with a writeoff in foreign currency and when the user set manually an exchange difference account, don't create a write-off. Instead, 2 cases to consider: - When the payment is expressed in a foreign currency different than the invoice's one, play with the rate between amount_currency and balance and let odoo making an exchange difference accordingly. That way, the payment has no write-off and the invoice is fully paid. - When the payment is expressed in company currency but the invoice has a foreign currency, force the exchange difference to use a rate that will fully paid the invoice without creating any write-off line on the payment. task_id: 3717436
This fix resolves a system error that occurred when customers removed pickup or return dates from rental products in their shopping cart. The issue has been corrected so customers can now modify rental dates without encountering errors, improving the rental checkout experience.
Original PR description
… the cart -> 17.0 Steps to reproduce : -> Add a rental product to your cart with a rental period -> Go to the cart -> Remove one of the date from the rental period (either pickup date or return date) Issue : -> Get this traceback Cause: -> when we remove the date from the cart we find a traceback of 'start_date'. Solution: -> Added the condition so if the we remove the start date or end date we not get the traceback. opw-3638268
This fix resolves an issue where rental products with serial number tracking were not displaying correctly in the Schedule view when the Rental Transfers feature is enabled. The system now properly captures and displays serial number information for all rental orders, allowing users to accurately group and organize rentals by serial number in the Gantt view.
Original PR description
**Current behavior:** The `rental.schedule` model/view does not have serial number data for order lines which are constructed while the `Rental Transfers` config option is active. This prevents the…
**Current behavior:** The `rental.schedule` model/view does not have serial number data for order lines which are constructed while the `Rental Transfers` config option is active. This prevents the view from accurately grouping by serial number. **Expected behavior:** The schedule view will correctly group the records in this gantt view. **Steps to reproduce:** 1. Create a new rental product, ensure it has the 'By Unique Serial Number' tracking option 2. Create an on hand instance of this product with a serial number 3. In Rental settings, enable the `Rental Transfers` option 3. Create a new rental order for this product, go to the `Schedule` view in the Rental app, select Group By Serial Number, observe that the new order is listed as having an undefined serial number **Cause of the issue:** When the Rental Transfers option is enabled, the wizard which normally tracks rental pickups/returns gets circumvented to instead get organized via stock. The SQL view for the schedule model only looks in the tables managed by this wizard to find lot_ids of products included in rental orders. So when we don't use the wizard, that information never makes it to the proper place. **Fix:** Union the current view's table result with another query which will select the data for the excluded records. opw-3754422
This fix resolves a crash that occurred when users in Philippine companies tried to change filter options in the Sales and Purchases summary report. The issue was caused by the system not properly handling empty data fields during report formatting, which has now been corrected to prevent the error.
Original PR description
### Steps to reproduce 1. Install "l10n_ph" 2. Switch to PH Company 3. Accounting / Reporting / Partner Reports / Summary Lists of Sales and Purchases 4. In the options/filters, change the "In" field You will be met with a traceback: `KeyError: 'no_format'` opw-3805585
The Profit and Loss report for Belgium was showing too much detail by breaking down the "Profit (Loss) of the Preceding Period Brought Forward" line into individual accounts. This change simplifies the report to display only the total amount, making it cleaner and easier to read for users.
Original PR description
In the "Profit and Loss" report, the `14P - Profit (Loss) of the Preceding Period Brought Forward (+)/(-)` line is grouped by account_id, showing then all the accounts from the preceding period that impact the final amount. Which provides a lot of information that may be too much. Only the total amount should be displayed. opw-3810161
This fix corrects how the progress percentage is calculated for resource schedules in the Planning module's Gantt view. Previously, the percentage calculation was incorrect and always displayed as 0%. Now the percentages will display accurately, helping managers better track resource utilization and scheduling progress.
Original PR description
**Steps to reproduce:** 1- Install Planning module 2- Go to gantt view for Schedule by Resource 3- Check percentage for any row that has planned shift **Current behavior before PR:** The percentage of progress of each resource is calculated in a wrong way https://github.com/odoo/enterprise/blob/17.0/planning/static/src/views/planning_gantt/planning_gantt_model.js#L135 The ratio is already the value of the decimal multiplied by 100 so when divide it again by 100 then round it, it will always give 0 **Desired behavior after PR is merged:** Since ratio is already multiplied by 100 and it will be formatted as percentage by multiply it again by 100 through 'formatPercentage' so we divide it by 100 without rounding it. opw-3796124
This fix removes the 'Request EDI Cancellation' button that was incorrectly appearing on Colombian invoices after they were sent through the EDI system. Since Colombian tax regulations do not allow cancellations of invoices that have been submitted to the government, users will no longer see this button or encounter errors when attempting to use it. Instead, they will need to follow the proper process of creating a credit note.
Original PR description
Currently, when a Colombian invoice has been sent through the EDI, a 'Request EDI Cancellation' button appears on the form view. This button shouldn't be there, as the cancellations process is not…
Currently, when a Colombian invoice has been sent through the EDI, a 'Request EDI Cancellation' button appears on the form view. This button shouldn't be there, as the cancellations process is not allowed in Colombia. ### Steps to reproduce * install `l10n_co_edi` * switch to a Colombian company and set up the EDI * create, confirm, and send an invoice * once the invoice has been successfully sent, attempt to cancel it using the 'Request EDI Cancellation' button. The invoice will be marked as `to cancel`. Odoo will then periodically try to cancel it, but it will never succeed because Colombian invoices that have been sent to the government cannot be reset to draft. If the cancellation process is initiated by the user (either by manually running the EDI services cron, or using the 'Process Now' button on the form view) the following error message appears: > You can't edit the following journal entry [journal name] because an electronic document has already been sent to Carvajal. To edit this entry, you need to create a Credit Note for the invoice and create a new invoice. opw-3754395 Forward-Port-Of: odoo/enterprise#59749
Fixed a bug in Ecuador's tax withholding system that was causing errors when users accidentally added multiple withholdings to the same vendor invoice. The system now prevents users from linking more than one withholding to a single invoice, ensuring accurate tax reporting and preventing system crashes when generating tax reports.
Original PR description
With an EC company setup Create a vendor bill Add 2+ withholding via the 'Add Withhold' Go to Accounting > Reports > Tax Report Set the month to this month, make sure report 103 is selected, then click the drop down menu for the PDF to select ATS Issue: Traceback It occurs because the user should not be able to add multiple posted withholds to the same invoice opw-3793714 Forward-Port-Of: odoo/enterprise#59679
This fix ensures that when messages are updated in Discuss channels, the information sent to users is read directly from the database rather than from temporary values. This prevents users from seeing outdated or incorrect message information and improves the reliability of the messaging system.
Original PR description
When writing in a discuss channel, the updated value sent to the client should be read from the database, not directly from the values passed to the write method. Partially backport of https://github.com/odoo/odoo/pull/139563 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users were unable to smoothly type URLs when adding media to content blocks because the interface kept re-rendering and losing focus on the input field. This fix resolves the focus loss issue that occurred after a recent migration from jQuery to Owl components, making it much easier for users to enter media URLs without interruption.
Original PR description
Video to reproduce on runbot odoo CE 17: https://github.com/odoo/odoo/assets/56789189/dcece1e9-9f33-4734-8cfa-aac012ec71e5 -Step to reproduce: + Add a block contain media + click on it and try to set…
Video to reproduce on runbot odoo CE 17: https://github.com/odoo/odoo/assets/56789189/dcece1e9-9f33-4734-8cfa-aac012ec71e5 -Step to reproduce: + Add a block contain media + click on it and try to set url for it to redirect + when typing the ui keep rerender and after render the autocomplete element it not focus back to the url input which cause user really struggle in typing unless they have a very quick hand -Reason: Since [1] we have migrated jQueryUI `urlautocomplete` to owl component , this add multiple event for the input element which the 'input' event is fire first when user type for url then it will try to trigger change for the url to include 'http' or 'https' after the change the element won't focus on the input itself which is a very bad behaviour [1]: https://github.com/odoo/odoo/commit/86a9171ec7790aa09f2b9a50dcb26deb029e8bed 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
This fix resolves an issue where expense reports were generating duplicate log notes every time the page was refreshed. The problem was caused by unnecessary quantity assignments in the expense module that were triggering unwanted system logs. This fix ensures that expense reports display cleanly without spurious activity logs.
Original PR description
Steps to reproduce: - with demo data - go on expense report - open the report from marc demo - refresh Issue: New log note on each refresh Note: Issue happening only in 17 commit introducing the bug: https://github.com/odoo/odoo/commit/f261c83b0dbc27dacc9cd0e0d935d52626723dac opw-3817367
This update fixes how the system handles electronic invoices for customers located in San Marino. Previously, San Marino customers were treated as non-EU countries, resulting in incorrect destination codes and VAT numbers in generated invoices. The system now correctly applies San Marino's specific destination code (2R4GTO8) as required by Italian tax regulations since October 2021, ensuring compliance with electronic invoicing requirements.
Original PR description
Steps to reproduce: - Install Accounting, l10n_it_edi and Contacts - Switch to an Italian company (e.g. IT Company) - Go to Contacts and create a contact from San Marino: * Name: SM customer *…
Steps to reproduce: - Install Accounting, l10n_it_edi and Contacts - Switch to an Italian company (e.g. IT Company) - Go to Contacts and create a contact from San Marino: * Name: SM customer * Country: San Marino * Street, City, ZIP: [any] * Destination Code: [any] - Create an invoice: * Customer: [the created contact from San Marino] * Product: [any] - Confirm the invoice - Generate E-invoice XML via "Send & Print" button Issue: In the XML, the destination code (i.e. CodiceDestinatario) is the default one for non-Italian customer (i.e. XXXXXXX). Also, the VAT number (i.e. IdFiscaleIVA) is the default value for countries that are not in the European Union (i.e. OO99999999999). However, since October 2021, San Marino should be handled differently for Italian electronic invoices. A specific destination code (i.e. 2R4GTO8) should be used for all customers from San Marino. Source: https://www.credemtel.it/fattura-elettronica/fattura-elettronica-san-marino/ Solution: For customers from San Marino: - Keep VAT number - Set "2R4GTO8" as destination code opw-3819054 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an illogical configuration in the time off accrual system where capping accrued time with zero maximum days would block all future allocations. The system now enforces that when capping accrued time is enabled, a meaningful maximum leave value must be set to ensure employees continue to receive time off allocations.
Original PR description
Steps to reproduce:
-------------------
- create a time off accrual plan with:
- cap accrued time equals to `True`
- maximum leave equals to `0 days`
- create an allocation with this accrual plan
- run the scheduled action "Accrual Time Off: Updates the number of time off"
(make sure you have the right "lastcall" and "nextcall")
Issue:
------
The number of days of the allocation is set to zero. This scenario makes no sense from a business point of view. In effect, we are blocking the accumulation of allocations at zero. The result is that there will never be any days allocated to these allocations.
Solution:
---------
Add a constraint to force a maximum leave number when cap accrued time is set.
opw-3847408This fix ensures that when creating product documents in the PDF Quote Builder, only PDF files can be saved. Previously, the validation check only occurred when editing existing documents, allowing non-PDF files to be saved during creation. This update closes the gap and maintains data integrity across all document operations.
Original PR description
When creating a product document, it was still possible to save something that wasn't a pdf. The check only happened when modifying it. opw-3802795
This fix prevents an error message from appearing when users click the confirm button while creating a time off request that doesn't require validation. The confirm button is now hidden during the creation process, ensuring users can only confirm after the request is properly saved, which eliminates unnecessary error messages.
Original PR description
Description of the issue/feature this PR addresses: In odoo V17 if a user is creating a holiday request for a time of type that requires no validation, the confirm button is visible during the…
Description of the issue/feature this PR addresses: In odoo V17 if a user is creating a holiday request for a time of type that requires no validation, the confirm button is visible during the creation process due to this line https://github.com/odoo/odoo/blob/2876b8300d1f9a740deb0faa02399df2426df402/addons/hr_holidays/views/hr_leave_views.xml#L248 in prior versions this was not the case https://github.com/odoo/odoo/blob/391a427620b6aec690481fe7c7d0b0326b95ee8c/addons/hr_holidays/views/hr_leave_views.xml#L238 So due to this change in Odoo V17 the confirm button is visible to the user while creating (before saving) so if the user clicks on the confirm button the behavior is it will save the record then set its state to confirm then will call action validate (all in the create function) after the execution of the create is finished it will call `action_confirm` which in turn will raise the user error. I added a check in the action confirm function to check if the time off requires no validation. alternatively I can revert the changes and add the `id == False` in the condition for the `action_confirm` button action. Current behavior before PR: A user error message is raised if the user clicks on the confirm button. see issue #160831 Desired behavior after PR is merged: No user error message that happens if the user clicks on the confirm button. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents support tickets from different customers using generic email providers (like @proton.me, @cegetel.net, and @dbmail.com) from being incorrectly grouped together. The system now recognizes these as personal email domains rather than company domains, ensuring that tickets from different customers are properly kept separate.
Original PR description
## Issue: - When we have open tickets from anyone with the email domain @proton.me, they are linked together even though this domain is generic, not a private one. same issue with @cegetel.net and…
## Issue: - When we have open tickets from anyone with the email domain @proton.me, they are linked together even though this domain is generic, not a private one. same issue with @cegetel.net and @dbmail.com ## Steps To Reproduce: - Create three tickets with "@proton.me" domain but different addresses. - See that in the smart button, the tickets are linked to each other even though the customers are different. ## Solution: - in `_compute_partner_ticket_count` we check if the email domain of the partner is in `iap_tools._MAIL_DOMAIN_BLACKLIST `, if not, we considers the email to be a company email which tickets can be grouped by. - the `_MAIL_DOMAIN_BLACKLIST` is a list of generic email providers on which IAP services should not run. Retrieving company information from them makes no sense. - To fix this issue I added `proton.me` , `cegetel.net` and `dbmail.com` to `_MAIL_DOMAIN_BLACKLIST` opw-3786308 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159321