Thursday, September 5, 2024
9 changes · saas-17.4
Resolved issues and error corrections
This fixes a problem where Italian electronic invoices could fail during automated website order payments if customer or invoice data was incomplete. Instead of stopping with an error, the system now generates the fallback proforma PDF as intended, helping automated sales flows complete more reliably.
Original PR description
In some cases, the Send & Print wizard is used in a "headless" way. For instance, when paying a sale order from the website, with the "automatic invoicing" setting on, an invoice will be created and…
In some cases, the Send & Print wizard is used in a "headless" way. For instance, when paying a sale order from the website, with the "automatic invoicing" setting on, an invoice will be created and the legal attachments will be generated and sent to the government. Neverthless, if the attachments cannot be generated (in the case of missing or invalid data on the partner or on the invoice), a proforma pdf will be generated instead (`allow_fallback_pdf=True`). In Italy, when generating an invoice with such an "headless" send & print, for instance: from the website, with a missing zip, an error will be raised: "Partner(s) should have a complete address, verify their Street, City, Zipcode and Country.". This prevents the generation of the PDF. Hence, a traceback will occur in `_hook_invoice_document_after_pdf_report_render`: a KeyError is raised by `invoice_data['pdf_attachment_values']`. This commit fixes this and makes sure the proforma pdf is generated. no task/ticket (internal feedback at task-3542881)
This fix prevents an error when users edit invoice subview lists with Odoo Studio. It ensures accounting forms can be customized without blocking users with a traceback.
Original PR description
Steps to reproduce:
* Install `web_studio` and `account`
* Open customers/invoices
* Edit view form with studio
* click on subview list
* click edit
* traceback
```
TypeError: Cannot read properties of undefined (reading 'state')
get isProductClickable()
/account/static/src/components/product_label_section_and_note_field/
product_label_section_and_note_field.js:188
```
To get fields from the parent view, we need to use evalContext instead
of `model.root`.
Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4148174)
opw-4148174This fixes an issue where electronic invoice documents could fail during the send and print process after an earlier technical change. Businesses using electronic invoicing can reliably generate, send, and print these documents again without disruption.
Original PR description
Since https://github.com/odoo/odoo/pull/167729, the return value of the rendering method has changed from a binary value to a dictionary. This was not taken into account in the send and print wizard in `account_edi_ubl_cii`. opw-4140992 opw-4141009 opw-4143248 opw-4144142 opw-4145603 opw-4147219 opw-4148447 opw-4159727 opw-4162854 opw-4162855 opw-4165230
This fixes an issue that prevented customers from paying by card when using payment providers other than Xendit. Businesses can again offer card payments through their chosen providers without being unintentionally limited to Xendit.
Original PR description
Following commit a4afe63a952f0dab3cf2157ee301c4540454b903 it wasn't possible to pay by card with something else than xendit any more.
The kiosk interface now correctly shows available languages when multiple languages are configured. This lets customers switch languages as intended during self-ordering, improving accessibility and usability in multilingual locations.
Original PR description
If you allowed multiple languages in your kiosk the language selector was not working properly. You were not able to change the language Steps to reproduce: ------------------- * Activate atleast 2 languages * Add those language as available in the kiosk config * Open the kiosk > Observation: The language selector is empty and you can't change the language Why the fix: ------------ It wasn't working because the fields used for the language selector were not loaded in the PoS. So we just needed to add those in the `_load_pos_data_fields` function from `res_lang`. opw-4108870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The point of sale now prevents customers from using loyalty rewards when they do not have enough points. This avoids incorrectly granting discounts or benefits and makes reward eligibility clearer at checkout.
Original PR description
Before this commit: ========== - Loyalty rewards would apply even if the customer had fewer loyalty points than required. After this commit: ========== - If the customer has fewer loyalty points than required for the loyalty rewards, the loyalty button will become disabled. task-4126886
This fix restores the ability for customers to pay by card using payment providers other than Xendit. It prevents checkout failures for businesses offering multiple card payment options, helping preserve sales and payment flexibility.
Original PR description
Following commit a4afe63a952f0dab3cf2157ee301c4540454b903 it wasn't possible to pay by card with something else than xendit any more.
Confirming an inter-company purchase order could fail when custom product options were involved because some stock-related logic was in the wrong module. The fix moves that logic to the stock-enabled inter-company module, preventing the error while preserving custom option details on the generated sales order.
Original PR description
### Steps to reproduce: - Create a second company COMP 2 - In the settings of COMP2 tick: Inter-Company Transactions Generate SO - With COMP1 create and confirm a PO for COMP2 for 1 unit of any product #### > Traceback ### Cause of the issue: These lines rely on stock models and hence provoque the traceback: https://github.com/odoo/enterprise/blob/d42af3270dea55acf247a99b815264ef96f0ac03/sale_purchase_inter_company_rules/models/purchase_order.py#L123-L132 They were added to transfer the `custom_product_template_attribute_value_id` during flows using stock routes. However, the stock dependency was removed from the `sale_purchase_inter_company_rules` module so that these lines should be moved to `sale_purchase_stock_inter_company_rules` ## opw-4151614
Fixed an issue that caused sharing to fail when a spreadsheet document became large. Users can now share bigger spreadsheets without hitting the previous size limit error, improving reliability for document collaboration.
Original PR description
- create a new spreadsheet - fill all cell with content (add rows and content until it crashes) - click on the Share button => boom We have a monkey-patched version of `literal_eval` which only accepts an input size of maximum 100KiB. But spreadsheet files can be larger than that. Bug introduced by https://github.com/odoo-dev/enterprise/commit/e55597dde848ae349248e4381f812e516b839985 opw-4139087 opw-4082093