Daily updates from Odoo
Thursday, May 16, 2024
33 changes · 17.0
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
This update removes unnecessary supplier data from Peru's electronic delivery guide documents to comply with the latest government validation rules. The removed data was not required for the transport types Odoo supports, so eliminating it reduces file complexity and prevents potential validation errors.
Original PR description
The SellerSupplierParty data was initially included for transport reason '13', but recent validations show it is only necessary for transport reasons '02' and '07', which we do not support. Removed these fields to prevent data redundancy and potential errors. Before: - Included SellerSupplierParty data for transport reason '13'. After: - Removed SellerSupplierParty data from DespatchAdvice template. This change ensures compliance with the latest validation rules and reduces unnecessary XML data. Legal Reference:  https://cpe.sunat.gob.pe/sites/default/files/inline-files/ValidacionesGREv20221020_publicacion.xlsx Latam Task: https://latam-localizations.odoo.com/web#id=1203&menu_id=142&cids=1&action=188&model=project.task&view_type=form
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
A syntax error in the CRM team views configuration file has been corrected by removing an extra closing curly brace. This fix prevents potential errors when the CRM module loads and ensures the context field is properly formatted.
Original PR description
I found in the CRM view crm_team_views.xml on line 82 an extra closing curly brace in the value of the context. Each opening tag/brace must have only one closing tag/brace. In our case it was a curly brace which must be removed to avoid syntax errors. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes critical issues in Hungarian electronic invoice processing that were causing system crashes and blocking email delivery. The changes prevent crashes when invoice names aren't set, allow demo mode usage without credentials, enable proper email delivery for invoices in certain states, and ensure modification invoices use the correct submission method to allow future corrections.
Original PR description
1. Avoid crashing if move.name is not set
In the tests
- `:TestAccountMoveInInvoiceOnchanges.test_fiduciary_mode_date_suggestion`
- `:TestSequenceMixin.test_sequence_empty_editable_with_quick_edit_mode`
the compute method `_compute_l10n_hu_edi_attachment_filename` was called before the invoice name was set.
Because of this, calling move.name.replace('/', '_') was raising an AttributeError.
2. Allow user to not put credentials when they are using demo mode.
3. sent (waiting for response) and confirmed_warning states should not raise a UserError and should not block an e-mail from being sent to the customer.
4. always send modification invoices using 'MODIFY' (never 'STORNO') since 'STORNO' prevents further modifications from being issued to the invoice, but in Odoo we can't predict whether the user will want to issue further corrections to an invoice in the future.
Fixes runbot errors 64755 and 64756.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-prThe word "Cash" was not being translated in the Point of Sale Sales Details report, causing it to appear in English regardless of the user's language setting. This fix adds proper translation support so the payment method displays correctly in all supported languages.
Original PR description
Problem: The word "Cash" is not translated and appears in the sales details Steps to reproduce: - Install "Point of Sale" app - Open a POS session and make some sales WHITHOUT paying in Cash - Close the session and change the language - Go to "Reporting" > "Sales Details" and print the report - In the section "Payments" you should see a row with "Cash" payments Cause: The word is not added to the translations opw-3684937 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164173
Emails 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 fix corrects an issue where payment terms were incorrectly displayed on refunded invoices in the preview page. When an invoice is fully refunded and marked as "reversed," the due date should no longer appear in the preview, as it's no longer relevant. This ensures customers see accurate information when viewing refunded invoices.
Original PR description
Payment term on reversed invoices should not be displayed in the preview page. Steps: - Create and confirm an invoice - Open the preview - The invoice due date is displayed on the top left of the page just above the "Download" and "Print" buttons - Go back to the invoice and make a full refund - The payment state of the invoice is "reversed" - Go back to the invoice preview -> The invoice due date is still displayed, it should not be opw-3894596 Forward-Port-Of: odoo/odoo#164897
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 update adds the url_unquote function to the system's URL handling utilities for version 17.0 and later. The function was not previously available in the compatibility layer, which could cause issues when the system needs to decode URL-encoded text. This fix ensures the function is properly available across all supported versions.
Original PR description
url_unquote was not used before 17.0 and not available in the noble monkeypatch, adding it for 17.0 -> master See https://runbot.odoo.com/runbot/build/62587153
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
A typo in the message template has been corrected where the messageSearch property was missing its proper reference. This fix ensures the Message component correctly recognizes and uses the messageSearch functionality, improving the reliability of message search features in the mail module.
Original PR description
This commit fixes a typo in message template. `messageSearch` is a prop of Message component.