Daily updates from Odoo
Thursday, May 16, 2024
29 changes
1 change
Resolved issues and error corrections
Fixes a web navigation issue where clicking links that point to a section on the same page could unexpectedly reload the app and send users back to the home menu. These links now behave as expected, improving reliability when navigating within pages.
Original PR description
When we changed client-side routing to be path based, we broke the behavior that allowed anchor-only links to scroll to the element with the corresponding id. It would instead cause the webclient to…
When we changed client-side routing to be path based, we broke the behavior that allowed anchor-only links to scroll to the element with the corresponding id. It would instead cause the webclient to attempt to load the state and end up on the home menu. This is caused by the fact that clicking on anchor links fires a popstate event, but that popstate event has no associated state. To fix this, we need to be able to differenciate a popstate event from an anchor click from other popstate events. Initially we considered simply setting a local variable when the user clicks on an anchor link, and checking that variable in the popstate handler, but this is both prone to race conditions and also causes issues when a link is clicked but preventDefault is called on the click event, preventing the popstate from occuring. As such, we decided instead to use the fact that the state on the popstate event from anchor clicks is null. The state is only null in two cases: when you click on such a link, or when you use the back button to go back to the first entry in history where the webclient was loaded. In the second case, this was purely incidental: we actually parsed the state from the URL and when the action mounted, it wouldn't touch the state because the new url was the same as the old one. In order to differenciate from the anchor link click, we now replace the state when the urls are identical. This will incidentally save us from parsing the url again if the user navigates back to this history entry, as the corresponding state will have been saved. Enterprise: https://github.com/odoo/enterprise/pull/60741
2 changes
Resolved issues and error corrections
This update fixes visual issues introduced by the customer portal redesign, especially around sidebar spacing, buttons, badges, and layout consistency. It improves the portal experience across appointments, documents, helpdesk, subscriptions, and signing by making pages look cleaner and more predictable for customers.
Original PR description
This PR has two main objectives : ## Sidebar layout During the portal redesign, we decided to make the sidebar width adapts to its content. While this approach helped us to avoid layout issues, it…
This PR has two main objectives : ## Sidebar layout During the portal redesign, we decided to make the sidebar width adapts to its content. While this approach helped us to avoid layout issues, it was sometimes too much content dependant, meaning that when more when two buttons were displayed side by side it would look okay, while having only a single button would place the sidebar at the extreme opposite side of the invoice, making it floating into the layout. This PR reverts this approach by applying a fixed width to the sidebar, and uses some padding utilities to prevent cluttered layouts. **Note:** This PR only includes important fixes that either: (1) make the user experience not as good as it should be ; (2) are needed to ensure that new features/changes that are being made to the Customer Portal this year provide a good visual result. Other PR's will follow to refine the design of the customer portal introduced in Odoo 17. ## Bugs, inconsistencies or forgotten views of the customer portal UI When the portal redesign happened, an overlay of design was applied to the templates, but the templates themselves were not really revamped and/or cleaned. This created a lot of unused utility classes, useless HTML tags, etc. - task-3703251 - follow up of task-3046004
The EC Sales list now keeps the date and other report settings when opened from the Belgian tax report reminder. This helps users submit reports for the correct period and reduces the risk of filing with mismatched information.
Original PR description
When accessing EC listing through the "Do not forget to submit the EC Sales list report" warning, the tax report's options used not to be passed onto EC listing. This also fixes some Python stylistic warnings. task-3891799
26 changes
Resolved issues and error corrections
This fix corrects a bug in the data merge feature where company-dependent fields were being incorrectly written to the partner model instead of their proper destination models. This ensures that merged data is stored in the right place, improving data integrity and preventing potential data loss or misplacement during merge operations.
Original PR description
data_merge company dependent fields were always written on res.partner and not their correct model.
This update corrects a configuration error in the Subscriptions app where the payment token field had an incorrect setting that caused errors when editing. The fix ensures users can properly manage payment tokens through the Subscriptions interface without encountering technical errors.
Original PR description
Before this commit:
The sale_subscription_order_form XML view had a key-value pair of {'no_create': 'True'} on the field for a payment_token. The proper value should be True without quotation marks, otherwise a invalid prop error is thrown when you attempt to edit the payment_token field via studio in the Subscriptions app.
opw-3891923This fix allows users to assign analytic accounts to liquidity lines during bank reconciliation. Previously, when analytic accounts were mandatory for miscellaneous entries, the system required them for all reconciliation lines but didn't provide a way to set them on liquidity lines. This update makes the analytic account field visible and editable on these lines, resolving the conflict.
Original PR description
Since commit 911886b20ac632a34ab1cfa2c2e22d60d16173ac, any analytic plan that is mandatory for miscellaneous entries is also required for all lines in the bank reconciliation. However, we currently do not allow setting analytic accounts on liquidity lines (the field is not displayed). opw-3905713
Fixed an issue where preparation displays configured to show orders from all Point of Sale locations were not automatically refreshing when new orders arrived. Users previously had to manually refresh the display to see new orders. This fix ensures that preparation displays set to accept orders from all PoS locations now automatically update like those linked to specific locations.
Original PR description
## Analysis Since this commit https://github.com/odoo/enterprise/commit/16ba33cd77413948308dd09326021a14f52f51f6, a domain is used to filter which preparation displays should be refreshed when an order arrives. The current domain only filters the preparation displays that are linked to one or more PoS (`pos_config_ids`). If no specific PoS are linked to the preparation display, the domain will filter out the preparation display and the user will have to **manually refresh** the preparation display to see a new order. ## Solution The domain should also check if a preparation display is linked to all PoS. ## References opw-3756416
This fix corrects how bicycle kilometers are calculated in the Belgian 281.10 payroll report. Previously, only one-way distances were being counted; now the system correctly includes round-trip distances. This ensures accurate mileage reporting for employee bicycle commute benefits.
Original PR description
Kilometers are only computed using the aller-simple distance instead of aller retour
This update fixes a technical issue that occurred when users tried to delete a document from the history list after restoring it. The problem was caused by multiple simultaneous operations being triggered by rapid clicks, which could cause the system to crash. The fix ensures that the restore button only processes one action at a time, preventing errors and providing a smoother user experience.
Original PR description
Steps to Reproduce: 1. Select a doc. 2. Replace it with another doc. 3. You can see the history of the inspector. 4. From the history tab, double-click on the restore button. 5. Delete the previewed doc from the history list. 6. Throws a Traceback. Issue: triggers asynchronous operation on "_onHistoryItemRestore", when clicked, rapid consecutive clicks could result in multiple asynchronous operations being initiated simultaneously, leading to race conditions or unexpected behavior. Fix: No traceback will occur, registered only once on a button. Task:3843157 Forward-Port-Of: odoo/enterprise#62368 Forward-Port-Of: odoo/enterprise#60227
WEBP format images were displaying with distorted previews in the document inspector. This fix adds proper CSS-based image resizing for WEBP images to match the handling of other image formats, ensuring all image types display correctly without breaking the layout alignment.
Original PR description
Before this commit: - Select an image (WEBP format) along with other images. - The preview in the inspector is distorted. Reason: - When introducing the support for WEBP images in the following PR -- https://github.com/odoo/odoo/pull/85494, the upload of documents was not taken into account. - The current image processing ensures that the supported image formats are resized at the backend before being sent to the frontend. Fix: - The exact values of the `max-width` and `max-height` draw their inspiration from the following image resizing values in the `documents_inspector.xml` ref- https://github.com/odoo/enterprise/blob/saas-16.4/documents/static/src/views/inspector/documents_inspector.xml#L39 After this commit: - The WEBP image, along with the other image formats can now be previewed without breaking any alignment in the Inspector. Task-3749547 Forward-Port-Of: odoo/enterprise#59339
This update removes unsupported field types (one-to-many, many-to-many, and binary fields) from the sorting dropdown menu in the Studio view editor for map and list views. Previously, users could incorrectly select these field types for sorting, which is not a supported operation. This fix ensures the sorting options only show compatible field types, improving the user experience and preventing configuration errors.
Original PR description
Before this commit, users were able to see one2many, many2many, and binary fields in the sortby dropdown menu in the map and list views of the studio. Steps to reproduce: - Project > Tasks > All Tasks. - Click on toggle studio and navigate to View tab in the sidebar. - In the sortby dropdown menu, all fields, including x2many and binary, were visible. Observed behavior: Users were able to select one2many, many2many, and binary fields for sorting via the studio sidebar in the map and list views. Expected behavior: One should not be able to sort by one2many, many2many, and binary fields in the map and list views via the studio. After this commit, users will not be able to see one2many, many2many, and binary fields in the sortby dropdown menu in the map and list views of the studio. Task-3790886 Forward-Port-Of: odoo/enterprise#59733
Fixed an issue where creating a new planning event from the calendar or gantt views would not preserve the time slot you selected. When users clicked to create an event at a specific time (like 5:30 AM to 7 PM), the form would incorrectly adjust the dates to match company work hours instead. This fix ensures the form displays exactly what you selected, improving the user experience when scheduling.
Original PR description
### Steps to reproduce the issue: 1. Go to _Planning > My Planning_ and switch to the Weekly Calendar view 2. Plan a new Event from 5.30 AM to 7 PM in the Calendar 3. When the creation Form opens,…
### Steps to reproduce the issue: 1. Go to _Planning > My Planning_ and switch to the Weekly Calendar view 2. Plan a new Event from 5.30 AM to 7 PM in the Calendar 3. When the creation Form opens, the Date does not reflect the slot you were creating - Also happens in Gantt view: 1. Make sure the company's schedule starts or ends between two hours (e.g.: 8.15 am) 2. Click on the '+' button of the corresponding cell in the Daily Gantt view 3. The Date will be cut to the start or end of the schedule. ### Explanation: Before opening `planning.planning_view_form`, the client calls for `onchange` which will then call for `default_get` that will align `start_datetime` and `end_datetime` with the work hours of `res.company.resource_calendar_id` in every situation where no resource is specified. https://github.com/odoo/enterprise/blob/ff4e39a09399f46790c0ad45bc9f9af4e4cd44d1/planning/models/planning.py#L625-L635 ### Suggested fix: `start_datetime` and `end_datetime` should not change only in Weekly and Daily Calendar views and in Daily Gantt View. The key should not remain in the Context of the Action to avoid unintended behaviours, adding it in the Context of the Event instead. opw-3829635 Forward-Port-Of: odoo/enterprise#62417 Forward-Port-Of: odoo/enterprise#61152
Companies can now export financial reports even if they don't have a VAT number assigned. Previously, users had to enter workaround values like '-' or '/' to bypass validation, which prevented proper default settings. This fix removes that restriction and improves the reporting experience for companies without VAT numbers.
Original PR description
Sometimes companies might not have a vat number. In this case they are often prevented from exporting a report. They've been using a workaround by enterping '-' or '/' but that prevents from easily setting proper default values elsewhere, for example in l10n_lu_reports. mentioned in opw-3802589 Forward-Port-Of: odoo/enterprise#62410 Forward-Port-Of: odoo/enterprise#62391
This pull request addresses a specific issue (OPW 3891923) in the Odoo 17.0 enterprise version. The fix resolves a bug that was impacting system functionality. This update ensures improved stability and reliability for users.
Fixed an issue where the selected date period from the Tax Report was not being applied when accessing the EC Sales List report through the warning notification. Users will now see the correct reporting period when navigating from the Tax Report to the EC Sales List, ensuring accurate compliance reporting for intra-community sales.
Original PR description
When accessing EC listing through the "Do not forget to submit the EC Sales list report" warning, the tax report's options used not to be passed onto EC listing. Steps to reproduce original issue: - Install `l10n_be_reports` - Create an invoice for a customer with 'Intra-Community' as a 'Fiscal Position' - Confirm it - Go to: Accounting > Reporting > Statement Reports > Tax Report - Select a period that'd include the invoice - Click on the "Do not forget to submit the EC Sales list report" warning - The period selected will be the wrong one task-3891799
This update fixes two technical issues in Colombian electronic invoice XML generation. The VMT_1 tag now correctly reports the currency exchange rate instead of the invoice amount, and the CDE_2 tag is limited to 30 characters maximum. These corrections ensure invoices comply with Colombian tax authority requirements for electronic invoice submission.
Original PR description
1. VMT_1 tag should report the currency rate instead of the invoice untaxed amount 2. CDE_2 tag should be limited to a max of 30 characters Related: https://github.com/odoo/odoo/pull/148953 and https://github.com/odoo/enterprise/pull/54086 task-3925896 Forward-Port-Of: odoo/enterprise#62512
This update fixes an issue where tab titles in the bank reconciliation feature were not being translated into different languages. The fix reorganizes how these titles are defined in the code so they can now be properly translated and displayed in users' preferred languages across the accounting modules.
Original PR description
* account_accountant_batch_payment, sale_account_accountant Currently the tab titles of the bank reconciliation widget are not translatable. This is due to the fact that attributes of OWL components (including `t-set-slot` elements) are not considered translatable. The solution is to extract these translatable terms in a variable outside of the `t-set-slot`'s parent component so it would become translatable and available inside the right slots. The issue was already partially fixed in [1] in 17.0. [1]: https://github.com/odoo/enterprise/commit/161163928bc4a18700be1b69b5276cb3b8490e45 opw-3881861 Forward-Port-Of: odoo/enterprise#62643
This update fixes a technical error that prevented users from editing the payment token field in the Subscriptions app. The issue was caused by an incorrect configuration value that has now been corrected, allowing users to properly manage payment tokens through the app's customization interface.
Original PR description
Before this commit:
The sale_subscription_order_form XML view had a key-value pair of {'no_create': 'True'} on the field for a payment_token. The proper value should be True without quotation marks, otherwise a invalid prop error is thrown when you attempt to edit the payment_token field via studio in the Subscriptions app.
opw-3891923This fix resolves an error that occurred when editing the payment token field in the Subscriptions app through Studio. The issue was caused by an incorrect configuration value that used quoted text instead of a proper boolean. This correction allows users to edit payment token settings without encountering errors.
Original PR description
Before this commit:
The sale_subscription_order_form XML view had a key-value pair of {'no_create': 'True'} on the field for a payment_token. The proper value should be True without quotation marks, otherwise a invalid prop error is thrown when you attempt to edit the payment_token field via studio in the Subscriptions app.
opw-3891923This update improves how shipping costs are handled for Starshipit deliveries. Previously, the system would process shipping calculations immediately, but Starshipit sometimes returns cost information later. The fix separates the processing logic to ensure only shipments with confirmed shipping costs are processed, preventing incomplete or incorrect cost calculations.
Original PR description
Explanation: send_to_shipper will process the carrier shipping calculation immediately. However for Starshipit, sometimes it will return the shipping cost later. Therefore we need to separate the function to make sure only the data with the carrier shipping cost result will be processed task-3887386 ref odoo/enterprise#61286
This fix resolves an issue where selecting multiple resupply warehouses in the warehouse form was not being saved correctly. When users selected warehouse A as a resupply source and then added warehouse B, the system was not properly tracking both selections, causing a mismatch between what was shown in the form and the actual active resupply routes. The fix updates how the warehouse system processes these selections to match the updated behavior of the form widget.
Original PR description
Steps to reproduce: - Create 3 warehouses A, B and C - Open the form of warehouse C - Select warehouse A as resupply warehouse and save. - Select warehouse B as resupply warehouse as well and save. Issue: The active resupply routes don't match the one selected in the warehouse form. Following #140644, the default behavior of the `many2many_checkboxes` widget changed. Instead of returning a SET command with all the currently linked models, it now returns a list of LINK/UNLINK commands containing the changes. The warehouse `write()` was still processing them as a SET command, leading to inconsistencies between the active routes and the form. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves a bug in spreadsheet accounting functions where date values were being incorrectly converted to strings, causing a mismatch between the cell's declared type and actual value. This prevented users from selecting cells with accounting formulas without encountering errors. The fix ensures cell data types remain consistent throughout calculations.
Original PR description
Steps to reproduce:
- create a new spreadsheet
- type in cell A1 "01/2024"
- in A2, type =ODOO.BALANCE("1", A1)
- select A1 => boom
Since 4939846774 `dateRange` is mutated in place.
But `dateRange` is actually the evaluated cell object. It has originally the `type: "number"` and a corresponding value whose type is a number.
But those accounting functions replaces the value with a string. From that point, there's a mismatch between `cell.type` and `cell.value`. The type says it's a number but it's actually not.
When selecting the cell and the bottom bar statistics are recomputed, because it expects numbers, not strings.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prEmails sent from the chatter message composer were not displaying formatting correctly when received. This fix ensures that styling and formatting (like links) are properly converted and preserved when sending messages through the chatter interface. Users will now see their formatted emails display correctly in recipients' inboxes.
Original PR description
Commit that introduced the issue: [1] Issue: ====== The email sent from chatter message isn't correctly formatted. Steps to reproduce the issue: ============================= - Go to chatter of any…
Commit that introduced the issue: [1] Issue: ====== The email sent from chatter message isn't correctly formatted. Steps to reproduce the issue: ============================= - Go to chatter of any form view - Open the mail compose modal - Add a primary link the in the email body - Send it - The email isn't formatted in the received email. Origin of the issue: ==================== The flow goes as follow, we first change the field and then when clicking send, we first update the value of the editor by `onWysiwygBlur` , then before the send is done, the field is saved which will trigger the event `NEED_LOCAL_CHANGES` which will call commitChanges, but since we already updated the value and we don't have urgent, nothing will happend and the function `toInline` will never be called. Solution: ========= To not break the old commit behavior and make it reset with disard, we add another flag `shouldInline` so we can force `commitChanges` and calculating inline style when saving. [1]: https://github.com/odoo/odoo/commit/35731674561efa391852fd7e42a19c732c29886f opw-3885368 Forward-Port-Of: odoo/odoo#165269 Forward-Port-Of: odoo/odoo#163323
This fix corrects how the email attachment interface displays action buttons. Previously, the download button was being hidden when it should have been visible. The fix ensures that when users can delete attachments, the interface properly shows both the download and delete buttons together instead of hiding the download option.
Original PR description
Since showDelete is not the same that checking that an attachement isDeletable, we need to add the class that diplays multiple buttons if we show the delete button, otherwise the Download button will be hidden. So we now use the correct value to decide if display multiple button. 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 update fixes a bug in the accounting module's certificate handling where a required subject attribute was missing. The fix ensures that certificate data is properly loaded and available for Ecuador EDI (Electronic Data Interchange) operations, preventing errors when processing electronic invoices.
Original PR description
Problem --------- In l10n_ec_edi_certificate.py, we attempt to get the subject attribute which does not exist in the namespace. Solution --------- Add the attribute to the namespace returned. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where Spanish invoices with discounts were being rejected by the Spanish government's validation platform. The system was missing a required "DiscountReason" field in the XML format, causing validation errors. We've added a default value for this field to ensure invoices comply with Spanish government requirements.
Original PR description
Steps to repoduce: - Create an invoice - Add a discount - Post it - Send and print (to get the xml) - Upload the xml on https://face.gob.es/en/facturas/validar-visualizar-facturas Issue: You will get…
Steps to repoduce: - Create an invoice - Add a discount - Post it - Send and print (to get the xml) - Upload the xml on https://face.gob.es/en/facturas/validar-visualizar-facturas Issue: You will get an error from the platform "Línea 111: Element 'DiscountRate': This element is not expected. Expected is ( DiscountReason )." Cause: The default is an empty string and will not be generated. Investigation indicates a delay in ticket arrivals (code from 2023). Presumably, the Spanish Gobierno may have restricted its XML validation. Solution: Add a default value (the same for Charges just in case) We don't add a `t-if` since the value is always empty and the requirements of the Spanish governement only requires a string [0-2500 characters] `3.1.5.2.1.1. DiscountReason Reason why the discount or rebate is made. Y[1..1] TextMax2500Type string positions: 0-2500` sources: - https://www.facturae.gob.es/formato/Versiones%20anteriores/B)%20Versi%C3%B3n%203.0/Esquema_ingles_V3_0.pdf - https://www.facturae.gob.es/formato/Paginas/version-3-2.aspx - https://www.facturae.gob.es/formato/Documents/EnglishFacturae3_0.pdf opw-3911313 Forward-Port-Of: odoo/odoo#165258
This update fixes an issue where sample Vimeo videos were not displaying correctly in the web editor due to privacy settings. New working video samples have been added so users can properly preview what Vimeo videos will look like when selected as an option.
Original PR description
task-3927949 closes #165322 ------------------ This PR fixes an issue about the sample videos for Vimeo not being displayed anymore due to their private parameter. This PR introduces new samples that will be displayed correctly, allowing the user to really see what he can expect by selecting this option. | 15.0 | 15.0-fix-vimeo-sample-videos-chgo | |--------|--------| |  |  | Forward-Port-Of: odoo/odoo#165417
Fixed an issue where mail groups with "Selected Group of Users" privacy setting were incorrectly rejecting emails from authorized users who weren't members of the group. Now the system properly verifies that senders belong to the specified access group, allowing legitimate emails to be received and posted to the mail group.
Original PR description
### [[FIX] mail_group: allow selected group of users while not members](https://github.com/odoo/odoo/pull/157590/commits/a25190e30ad732ab5057e85fcd4f34e3bcf3530b) This commit addresses the behavior…
### [[FIX] mail_group: allow selected group of users while not members](https://github.com/odoo/odoo/pull/157590/commits/a25190e30ad732ab5057e85fcd4f34e3bcf3530b) This commit addresses the behavior of mail groups set to privacy mode "Selected group of users". Prior to this fix, incoming emails were being checked against the list of members within the mail group, even when the privacy setting allowed for a specified user group, not solely members. Consequently, legitimate emails from authorized users were being rejected due to the sender not being a member of the mail group. With this commit, the sender's membership in the access group is verified. ### [Reproduce] - Install -i website_mail_group - Set the alias to "odoo.com" in General Settings - Create or Modify Mail Group named "My Company News", with the following settings: - Email Alias: newsletter@odoo.com - Privacy: "Selected Group of Users" - Select internal user group, add there a user with email pian@odoo.com - Send or Inject the email from the eml file below - BUG: email not present in the mail group Email eml file: ```eml From: "pian@odoo.com" <pian@odoo.com> Subject: members only To: "newsletter@odoo.com" <newsletter@odoo.com> Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8"><p= >Content for Internal Users</p> ``` opw-3725128 Forward-Port-Of: odoo/odoo#164744 Forward-Port-Of: odoo/odoo#157590
This fix resolves an issue where the "Amounts to Settle" field was not displaying correctly for purchase invoices. The problem occurred because the system was not properly handling negative residual amounts in purchase transactions. Users will now see accurate settlement amounts for all invoice types.
Original PR description
**Description of the issue/feature this PR addresses:** Before this commit Amounts to Settle is not show. When it is a purchase amount_residual is lower than zero. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr