Tuesday, April 9, 2024
30 changes · 17.0
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
This update fixes the error dialog window to be wider, allowing error messages and tracebacks to display properly without being cut off. Users will now be able to see complete error information when issues occur in the system.
Original PR description
The dialog width for errors is to small to properly display the traceback. --- 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 update removes unnecessary technical attributes (t-key) from template files that don't require them. These attributes were previously added but aren't needed for templates that don't use the Owl framework, and removing them eliminates warning messages during system operation.
Original PR description
-Since [1] we have add t-key for some template, but some aren't necessary because they not load via Owl, therefore remove it to avoid warning : "Unknown directives or unused attributes" [1]: https://github.com/odoo/odoo/pull/130467/commits/a9b577dfcbd6c01abdc649a3ea61f80e9018832d#diff-0ba40f64ee7d28c08bdbb7273985adc0d2d2b63d8c3233aa2630e6ba4bde4df9 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 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
This fix corrects an issue where journal entries created from company-paid expense reports were all assigned the same date, regardless of when individual expenses occurred. Now each journal entry will properly reflect the actual date of the corresponding expense, ensuring accurate financial records and better audit trails.
Original PR description
Before when we create an expense report paid by company with multiple expenses of different dates then we posted the expense report. The journal entries had all the same date. Now journal entries will match the date of the expense when it is an expense paid by company. Signed, Logan Staelens lost@odoo.com https://github.com/lost-odoo Forward-Port-Of: odoo/odoo#159083
This update fixes a visual issue where two scrollbars would appear when editing tables in notes. When users stretched table columns beyond the visible area and scrolled, an unnecessary second scrollbar would appear. The fix hides the overflow in the editor field and lets the main editable area handle scrolling, resulting in a cleaner, single scrollbar experience.
Original PR description
Issue: ===== double scrollbar appears in notes. Steps to reproduce the issue: ============================= - Go to notes - Insert a table - Add some columns and try to stretch the last one to the right until it goes outside the width of the editable. - Click on the last cell to the right in the table and scroll left - Another scrollbar will appear. Origin of the issue: ==================== The part of the table that is invisible in the editor is considered as overflow for the `html_field` so it will show a scrollbar which is not needed since we already have a scrollbar in the edtibale. Solution: ========= We mark hide the overflow in `html_field` and let the editable takes care of the overflow. task-3721794 Forward-Port-Of: odoo/odoo#160674 Forward-Port-Of: odoo/odoo#157675
This update improves the error messages displayed when users encounter issues on public discussion pages. Instead of cryptic technical errors that are difficult to understand and report, users will now see clearer, more user-friendly messages that help them better understand what went wrong.
Original PR description
Before this PR, the error displayed in the public page was quite cryptic. It was hard for the user to understand that error and even harder to report it if needed. This PR makes the error more user friendly. task-3850559
This fix resolves an issue where document headers in boxed layout PDFs were overlapping and cropping the body content on pages after the first page. By reducing unnecessary whitespace in the header design, the header now fits within the standard page margins, ensuring all document content displays correctly across all pages.
Original PR description
### Steps to reproduce issue: 1. Select a boxed layout document 2. Create an invoice and add lines until the pdf version is on two pages 3. Print the pdf 4. On every page except the first one, the body of the document is cropped by the header ### Explanation: The PDF consists of three parts: the header, the footer and the body, and they are added separately. The body is delimited by the paper format and margins. Those do not depend on the size of the header and the footer. In the boxed layout, the height of the header is bigger than the default size of the top margin of the body. Because of that, it covers a part of the body. ### Suggested fix: By removing some whitespace, the header size has been reduced to a size smaller than the default margins of the document while keeping every information readable. opw-3768511 Forward-Port-Of: odoo/odoo#160770 Forward-Port-Of: odoo/odoo#159125
This fix corrects a language inconsistency on the email unsubscribe page where some text was displaying in the user's language instead of the website's language. The fix ensures all content on the unsubscribe page displays in the correct language by properly setting the language attribute, providing a consistent user experience for customers in different regions.
Original PR description
### Steps to reproduce issue: 1. Download two languages, set one as the user's language, the other as the website's 2. Make sure MailHog is running 3. Create a Mailing Contact with two different…
### Steps to reproduce issue: 1. Download two languages, set one as the user's language, the other as the website's 2. Make sure MailHog is running 3. Create a Mailing Contact with two different Mailing Lists 4. Create a mail with a link to unsubscribe 5. Send mail to one of the Contact's Mailing lists 6. Through MailHog, click on the subscription cancelling link 7. The first line is in the user's language and the others in the website's language ### Explanation: While most of the webpage originates from an XML file, translated using the language of the website. https://github.com/odoo/odoo/blob/2ad911dab1f34b1b6dda1016cc189f0fea64b12c/addons/mass_mailing/views/mass_mailing_templates_portal.xml#L118 The first line is passed through javascript and translated on the fly. https://github.com/odoo/odoo/blob/efd178daee689192d4e930a075475587038b3e0d/addons/mass_mailing/static/src/js/unsubscribe.js#L50-L55 The line is translated thanks to an object fetched at the load of the page. The url where the object is located can receive parameters including the language, but defaults to the user's and is not set in our case. https://github.com/odoo/odoo/blob/0ca2ca9e8914dda77166b62dc8c2e9dc1ca1d3a4/addons/web/static/src/legacy/js/core/translation.js#L73-L78 ### Suggested fix: The language can be passed through the attribute `lang` of the document. https://github.com/odoo/odoo/blob/658bc65b22dba86a35f6bba0f892427e1be4aed1/addons/web/static/src/legacy/js/core/session.js#L205-L211 https://github.com/odoo/odoo/blob/e251354ce4b7df1763247385413e98f975981479/addons/web/views/webclient_templates.xml#L10 This option is already used in `website` and, [since 16.0](https://github.com/odoo/odoo/commit/5136ac7e4daaadda396c45c8538a81f8d6c44c0e), is inherited once `website` is installed. https://github.com/odoo/odoo/blob/c3c8003c6d1c4d694531c93e803e7e9cd7ebaa83/addons/website/views/website_templates.xml#L39-L50 opw-3748027 Forward-Port-Of: odoo/odoo#160697 Forward-Port-Of: odoo/odoo#159341
Fixed a visual bug where spaces between rating icons would disappear when users changed the score in the rating snippet. The issue was caused by a jQuery library update that changed how HTML tags are processed. The fix ensures proper spacing is maintained between icons regardless of score changes.
Original PR description
To reproduce the issue: -Drag and drop the rating snippet. -Change the score from options. -Notice that spaces between icons disappear. Specification: In the release notes[[1]](…
To reproduce the issue: -Drag and drop the rating snippet. -Change the score from options. -Notice that spaces between icons disappear. Specification: In the release notes[[1]]( https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/) of jQuery 3.5.0, it's stated that security fixes related to the HTML parser were implemented. Consequently, self-closing e.g. `<i/>` tags inside function arguments were replaced with e.g. `<i></i>`. As a result, trailing spaces lost significance, causing icons to stick together. Prior to Odoo 16.2, jQuery 3.3.1 was utilized, which allowed the use of self-closing tags in the append function. This behavior was as expected.However, starting from Odoo 16.2, jQuery version 3.6.3 was adopted. After this PR: Instead of using self-closing `<i/>` tags, `<i></i> ` with a trailing space was used. This trailing space gained significance due to the prefilter no longer ignoring it. Consequently, icons no longer stick together after changing the score. task-3576760 Forward-Port-Of: odoo/odoo#160061
This fix corrects an issue where the website menu editing tutorial incorrectly referenced the "Shop" menu item, which is only available when the website_sale module is installed. The tour now works properly with just the website app, making it more accessible to users who haven't installed the sales features.
Original PR description
The tour mentioned the "Shop" menu item since [1]. This is obviously a mistake: the tour should work when only the website app is installed. [1]: https://github.com/odoo/odoo/commit/a4b1c268131ed771dd68616a26a9f1ce50a189f0 runbot-60696