Monday, August 26, 2024
3 changes · saas-17.1
Resolved issues and error corrections
This change prevents billing field requirements from one checkout context from being reused in later checkouts. It helps avoid incorrect mandatory fields appearing for customers or tests in other countries, improving reliability in portal and point of sale flows.
Original PR description
Since [1], the `MANDATORY_BILLING_FIELDS` are now returned through the method `/portal._get_mandatory_fields`:…
Since [1], the `MANDATORY_BILLING_FIELDS` are now returned through the method `/portal._get_mandatory_fields`: https://github.com/odoo/odoo/blob/b454a060a41961b7e0c9cc1ee6ec77b5cca1ec75/addons/portal/controllers/portal.py#L421-L423 Where `MANDATORY_BILLING_FIELDS` is a list defined on the class: https://github.com/odoo/odoo/blob/b454a060a41961b7e0c9cc1ee6ec77b5cca1ec75/addons/portal/controllers/portal.py#L134-L136 This is a problem: the value is an object, so if the list is modified during a call, the method will then return that modified list instead of the initial one. For instance, in `l10n_ec_website_sale`, we add some values to that list: https://github.com/odoo/odoo/blob/10b7c27a4fc873c6220d63a0686f484e92ae906b/addons/l10n_ec_website_sale/controllers/portal.py#L14-L17 Then, if we call again `_get_mandatory_fields` with a company that is not EC, we will still have `l10n_latam_identification_type_id` and `vat` in the list of mandatory fields. That is incorrect. Looking at builds on runbot, some of them failed because of that error. This is the case with the FW of [2] on 17.4 which is blocked because of the above issue. Indeed, this commit contains a tour that checkouts a cart with an EC company. And, in 17.4, this flow leads to a call of `_get_mandatory_fields`. As explained, we will therefore add the EC mandatory fields. So, if [2] is part of the code, and if we try to run this: `--test-tags=.test_checkout_address_ec,.test_qr_code_receipt_mx` Where the first test comes from [2] and the second one is an existing test in the code, it will fail: the first test will add some values in `MANDATORY_BILLING_FIELDS`. Then, during the second test, at some point we also check the mandatory fields: the method will return the modified list (i.e., with the EC fields), and we will not have any value for these unexpected fields -> the test will fail [1] 9b9b0ee4c2d8a8a66e5e0456acbb780e5d8d6456 [2] 732b4fbbf3009769708f9c9cba57609d22f2a570
This update removes an unnecessary critical error log from the Six payment terminal integration and replaces it with more appropriate logging. It also reduces connection-related errors when internet access is unavailable, helping keep point-of-sale operations clearer and less noisy for support teams.
Original PR description
A `_logger.critical` call was mistakenly committed in the `SixDriver.py` file. It has now been removed. Task: 3995682
This update replaces an outdated internal reference with the current approach for determining optional billing fields. It helps keep the website checkout flow compatible with newer platform behavior and reduces the risk of future maintenance issues.
Original PR description
`portal.CustomerPortal.OPTIONAL_BILLING_FIELDS` is deprecated, we should rather use the method `_get_optional_fields` c.f. the OC-side commit