Daily updates from Odoo
Saturday, March 16, 2024
6 changes
Resolved issues and error corrections
This fix ensures that preparation printers accurately print the details of product variants on receipts, resolving an issue where only the product template name was displayed. This improves kitchen staff's ability to prepare orders correctly, reducing potential errors and improving order fulfillment. The change was implemented as a result of a previous update and includes new tests for variant name and quantity.
Original PR description
Before this fix: Receipts printed with kitchen/preparation printer does not show the details of variants products. Just the product template name. This is ambigious for kitchen as the variant information is generally necessary in order to prepare the order correctly After this fix: Restore the previous behavior regarding the product name used This bug is a side effect of: https://github.com/odoo/odoo/pull/152213 due to the changes to `set_full_product_name` Was also a good occasion to add some tests on the changes name & qty opw-3755391 Forward-Port-Of: odoo/odoo#156390
This update addresses minor discrepancies between Odoo's chart of accounts and the latest Portuguese tax regulations (OCC). The changes ensure Odoo remains compliant with Portuguese accounting standards, specifically for companies under the general regime. This is a routine maintenance fix.
Original PR description
In #87572, the CoA was refactored to follow the regulation for companies under the general regime, which can be found at https://www.occ.pt/fotos/editor2/taxonomiasplanocontas_fev2019.pdf This commit fixes minor discrepancies between our version and the published regulation. Enterprise PR: https://github.com/odoo/enterprise/pull/58387 taskid:3060790 Forward-Port-Of: odoo/odoo#157780 Forward-Port-Of: odoo/odoo#157131
This update corrects a technical issue that prevented custom models inheriting from the mail thread functionality from properly configuring a 'user_id' field. Previously, a specific field type caused an error during message processing. This fix ensures that custom models can correctly define and utilize the 'user_id' field, improving the flexibility of email workflows.
Original PR description
-Step to reproduce: any custom model that inherit from mail.thread then define a field user_id but with type is char and boom error happen at method '_message_get_suggested_recipients' because it always expect 'user_id' to be a many2one field -Solution: need to check the type of 'user_id' also 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 Forward-Port-Of: odoo/odoo#157350 Forward-Port-Of: odoo/odoo#155149
This update resolves a bug where the 'Email' field within website forms didn't appear correctly when using the new OWL date picker. The fix ensures that the 'Email' field is always visible when the associated date field is populated, eliminating a previous requirement to add text to the 'Name' field. This improves the user experience by ensuring consistent form functionality.
Original PR description
Steps to reproduce [17.0+]: - Create a website form of any type in which you have: - One "Name" or other text field. - One field with the "Date" type. - One field "Email" with the visibility…
Steps to reproduce [17.0+]:
- Create a website form of any type in which you have:
- One "Name" or other text field.
- One field with the "Date" type.
- One field "Email" with the visibility condition: "Only visible if"
a field of type "Date" "Is set".
- When you complete the "Date" field, the "Email" one should show but it
does not > It shows if you also add at least two characters to the text
field.
Starting from [1], an OWL date picker component was introduced mainly to
replace the use of `TempusDominus` and `DateRangePicker` libraries.
After this change, an adaptation (from [2]) was done to completely
replace every usage of `TempusDominus` with the new OWL component
(including the form date[time]picker fields).
One of the lost features from `TempusDominus` was the trigger of an
"input" event on date [time] change, which also triggers the form field
visibility check.
The goal of this commit is to fix this behaviour by simply updating
fields visibility on every component value change.
[1]: https://github.com/odoo/odoo/commit/b5794e89e1ad29e2a86c7ddaf241e3fc24654b5f
[2]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
opw-3778129
Forward-Port-Of: odoo/odoo#157328This update fixes a discrepancy between the printed sale order report and the customer portal preview. Previously, the customer portal only showed the payment term name, but now it accurately displays the payment term note, ensuring consistent information for customers. This improves transparency and reduces potential confusion.
Original PR description
Description: There is a discrepancy between the printed sale order report and the customer preview when it comes to displaying the Payment Terms. On the SO report, Odoo prints the 'note' field, whereas on the preview, Odoo only displays the 'name' field. Desired behavior after PR is merged: Customer preview now matches the printed report by displaying the payment_term.note field as well opw-3790997 Forward-Port-Of: odoo/odoo#157475
This update corrects a potential issue where users could accidentally select incorrect payment method lines when creating payments. The fix prevents outdated values by validating the payment method selection, ensuring data integrity and accurate payment recording. This improves the reliability of financial transactions.
Original PR description
When you create or register a payment, the domain of the payment method lines is based on a computed field dependent of the selected journal. The issue is that the interface isn't blocked when…
When you create or register a payment, the domain of the payment method lines is based on a computed field dependent of the selected journal. The issue is that the interface isn't blocked when waiting for the onchange return. So if the user changes the journal, then select the payment method quickly enough while the onchange is still pending, he will be able to select outdated values. It is a limitation of the js framework, so to avoid the user encoding wrong datas, the fix here is to raise a `ValidationError` telling to re-select the payment method. To reproduce: - create second bank journal, with outbound payment method lines having different names than the ones of the first bank journal (in order to distinct them). - slow down the `_compute_payment_method_line_fields` method - create a vendor payment, switch the journal to the one created and select the second payment method (before the onchange ends). - save the payment. -> The payment has a payment method line from a different journal opw-3587241 Enterprise PR: https://github.com/odoo/enterprise/pull/56602 Forward-Port-Of: odoo/odoo#157872 Forward-Port-Of: odoo/odoo#147583