Daily updates from Odoo
Navigate
Branch
Tuesday, March 30, 2021
10 changes
Enhancements to existing features
Manufacturing work order tests were updated to better reflect how completed quantities are calculated in normal use. Extra components added to a manufacturing order are now consolidated when the same component already exists, reducing duplicate lines and making orders clearer.
Original PR description
The "quantity_done" field is filled in by onchange. In previous test, this number is always 0 because we didn't trigger the onchange. Since now when "quantity_done" is 0 and no backorder, the move will be cancelled, the test will fail. we adapt the test to trigger the onchange. Task 2446915 COM PR odoo/odoo#66583
Resolved issues and error corrections
Appointment confirmation emails now show the same time that attendees see on the website confirmation page. This prevents confusion caused by mismatched appointment times across customer-facing touchpoints.
Original PR description
make the time shown in the email sent to attendees consistent with the time shown on the website confirmation page in order to make sure that users don't get confused when they see different times displayed. Task-2451154 Related: COM-PR: odoo/odoo#65729
Access rules for SMS templates were corrected so regular internal users can read templates when other features need them. This prevents avoidable errors while still keeping restrictions on creating, editing, or deleting templates.
Original PR description
These record rules were meant to restrict access to certain model to create/write/unlink, but not read. This was leading to issues when others models were trying to read a template. Unit test were also added to the sms module to ensure that a member of group_user can always read a sms template. task-2191254
Code cleanup and technical improvements
Odoo’s online payment process has been redesigned so payments can be processed first and saved for future use afterward, matching how modern payment providers work. This improves compatibility with providers, reduces unnecessary validation/refund steps, and simplifies future payment integrations, including SEPA direct debit updates.
Original PR description
PURPOSE Before this commit, the "payment from odoo" flow (direct) required tokenizing a payment method before processing a payment, rather than directly processing the payment, and eventually…
PURPOSE Before this commit, the "payment from odoo" flow (direct) required tokenizing a payment method before processing a payment, rather than directly processing the payment, and eventually tokenizing the payment method later. In practice, this often meant that a 'validation' transaction had to be processed and immediately refunded in order to generate a temporary token. Then, a second "payment by token" flow had to be executed to process the intended payment. This implementation was too rigid for most modern payment providers' APIs. Indeed, they mostly expect single processing for a given payment and usually offer the possibility to tokenize the payment method after the payment, rarely before. Because of this, the implementation of many providers was either difficult, limited, or even impossible. Among the various incompatibilities, we find: support for direct payments but not tokenization, lack of support for authentication during tokenization, absence of hosted page dedicated to tokenization, etc. As another cascading consequence of this implementation choice, several providers could not be migrated to newer APIs after that the ones implemented in Odoo were deprecated. The goal here is thus to 'invert' the payment flow implemented in Odoo. As this means re-writing most of the payment module and of its provider implementations, the opportunity is taken to deeply clean and document the code of the impacted modules. SPECIFICATIONS - Lift the limitations listed above by inverting the generic direct payment flow to first create and process a transaction, then tokenize it if requested. - Remove the `payment_flow` field on `payment.acquirer` and let the acquirer choose the appropriate flow according to the use-case. - Filter acquirers offered to the customer based on the use-case. - Add overridable hooks at key steps of the payment flow to allow implementing new providers with minimal effort (both in Python and JavaScript). - Move all module-specific logic and fields to where they belong (e.g. let Subscriptions filter out acquirers based on their support for tokenization, move `qr_code` in `payment_transfer`, ...). - Homogenize the inheritance strategy of acquirer modules. - Standardize the implementation logic in other modules' controllers. - Improve the traceability of payments through stored fields and logs. - Remove the public read right on `payment.acquirer` and enforce the use of access tokens in all modules' flows. - Fix all bugs that were inherent to the old implementation. - Replace the previous testing suite (which was mostly commented-out for years) with a new one that allows testing of both routes and flows with different test configurations (user, transaction context, ...). LINKS Enterprise PR: https://github.com/odoo/enterprise/pull/12528 Upgrade PR: https://github.com/odoo/upgrade/pull/2291 task-2085989 Co-authored-by: Antoine Vandevenne <anv@odoo.com> Co-authored-by: Victor Feyens <vfe@odoo.com> Co-authored-by: Arnaud Joset <arj@odoo.com> Co-authored-by: Kevin Baptiste <kba@odoo.com> Co-authored-by: Barad Mahendrasinh <mba@odoo.com> Co-authored-by: Prakash Prajapati <ppr@odoo.com> Co-authored-by: Adrien Horgnies <aho@odoo.com>
Miscellaneous changes
Issue - Install 'Rental' module - Create a rental order - Select 'Meeting Room' as product - In wizard, select same day for pickup and return date but different hours, then add it. Time displayed in product description for return date is wrong. Cause 'format_time' function should receive time already timezoned. Solution Add timezone to datetime before format. opw-2480692 Forward-Port-Of: odoo/enterprise#17272
Original PR description
Issue - Install 'Rental' module - Create a rental order - Select 'Meeting Room' as product - In wizard, select same day for pickup and return date but different hours, then add it. Time displayed in product description for return date is wrong. Cause 'format_time' function should receive time already timezoned. Solution Add timezone to datetime before format. opw-2480692 Forward-Port-Of: odoo/enterprise#17272
delivery guide from Chile Forward-Port-Of: odoo/enterprise#17147
Original PR description
delivery guide from Chile Forward-Port-Of: odoo/enterprise#17147
Steps to follow to reproduce the bug: - Go to app > install the “l10n_ca_check_printing” module - In the accounting settings > under the "vendor payments" section, in the checks option select the canada check layout - In accounting > configuration > journals - Select “Bank” > Edit the form > Advanced Settings > uncheck the "Manual Numbering" field - Go accounting > vendors > payments > create a new payment - Choose “send money” in payment type - Choose any partner - Select “Bank” in pay
Original PR description
Steps to follow to reproduce the bug: - Go to app > install the “l10n_ca_check_printing” module - In the accounting settings > under the "vendor payments" section, in the checks option select the canada check layout - In accounting > configuration > journals - Select “Bank” > Edit the form > Advanced Settings > uncheck the "Manual Numbering" field - Go accounting > vendors > payments > create a new payment - Choose “send money” in payment type - Choose any partner - Select “Bank” in payment Journal and choose the “Checks” option - Confirm the payment - Click on print check - Enter any valid number on “next check number” field Problem: The sequence_number appears on the top right of the check while it shouldn't be. In the view, this field does not have the condition to check the value of 'manual_sequencing'. So it is always displayed in the check opw-2455986 Forward-Port-Of: odoo/enterprise#17294
[FIX] l10n_ar_edi: avoid AFIP accesses in test mode In test mode, we should not access to AFIP web service to get the last invoice number as the AFIP key may be not configured. Instead of that, we should return a default value. One reason is that during an upgrade, we check that all the menus/views have the same behaviour before and after the upgrade to check that not menus/views have been broken. During this check, when we access to the `menu account.menu_action_move_out_invoice_type`, `
Original PR description
[FIX] l10n_ar_edi: avoid AFIP accesses in test mode In test mode, we should not access to AFIP web service to get the last invoice number as the AFIP key may be not configured. Instead of that, we should return a default value. One reason is that during an upgrade, we check that all the menus/views have the same behaviour before and after the upgrade to check that not menus/views have been broken. During this check, when we access to the `menu account.menu_action_move_out_invoice_type`, `account.move.highest_name` is computed and, in its compute method, `account_journal._get_last_sequence_from_afip()` is called, which leads to an error as the AFIP key is not configured. The test mode is enabled only when `self.registry.enter_test_mode(cr)` is explicitely called. This is the case for upgrade tests for example, but not for `l10n_ar_edi` tests. upg-4898 opw-2481780 Forward-Port-Of: odoo/enterprise#17290
…e current company and workorder company. Refined search condition on the basis of company_id; - The company of the workorder, - Or the company is False. Since, while upgrading the database of the customer, we observed that the team associated with the workorder gets changed as it was not satisfied in the previous domain. Hence, appending this domain to the condition it would only fetch the records belonging to the same company, in other words, only the same company's team would b
Original PR description
…e current company and workorder company. Refined search condition on the basis of company_id; - The company of the workorder, - Or the company is False. Since, while upgrading the database of the customer, we observed that the team associated with the workorder gets changed as it was not satisfied in the previous domain. Hence, appending this domain to the condition it would only fetch the records belonging to the same company, in other words, only the same company's team would be allowed to get associated in the record of the workorder. upg - 9306 Forward-Port-Of: odoo/enterprise#17096
Making the module non-installable generates an error when updating a database where the module is installed. opw-2454201 Forward-Port-Of: odoo/enterprise#17347
Original PR description
Making the module non-installable generates an error when updating a database where the module is installed. opw-2454201 Forward-Port-Of: odoo/enterprise#17347