Monday, August 24, 2020
5 changes · master
New functionality added to Odoo
Odoo eLearning now lets businesses identify contacts who have completed courses and email them specifically. Course managers can also configure an automatic completion email, making it easier to congratulate learners or send follow-up information at the right time.
Original PR description
PURPOSE Before this commit, it was possible to send an email to all attendees only. After this commit, it will be possible to send an email to attendees that completed the course. SPECIFICATION Adds a searchable o2m field in the res.partner model to find all the completed courses linked to that partner. Adds a new 'Completion Email' template field in the slide.channel model that will be sent automatically after an attendee completes a course. LINKS Task ID-2216352 PR #49592 Upgrade PR #1084
Enhancements to existing features
Calendar quick creation can now use a configured field instead of assuming every record is named with a standard "name" field. This helps customized Odoo models create calendar entries faster without forcing users into the full form view.
Original PR description
Until now, the quick creation dialog of the calendar view assumed that the underlying model used a 'name' field for quick creation, with a graceful degradation if it was not the case (redirect to the form view). This prevented quick creation of models created through customizations (for example). This commit adds a `create_name_field` attribute on the view declaration (similarly to many2one field) that allows to specify the field to use during quick creation. Task-2185423
Resolved issues and error corrections
Invoice creation now works when an online order involves a customer linked to a different company. This prevents invoicing errors in multi-company setups and helps ecommerce purchases complete smoothly across companies.
Original PR description
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
Users configuring calendar views in Studio can now choose which field is used when quickly creating a new calendar entry. This makes calendar setup more flexible and helps newly created records use the right name or label from the start.
Original PR description
Add support for the `create_name_field` attribute on the calendar view in the view editor and in the modelconfigurator. Task-2185423
When shoppers are sent to an external payment provider, their cart is now protected from being changed mid-payment. This reduces mismatches between the paid amount and the order total, helping merchants avoid manual refunds or order corrections.
Original PR description
Some payment flows allow way to much stuff to happen to the cart during the payment process. For example, imagine a customer that pays using Paypal. Upon clicking the 'Pay now' button, they get…
Some payment flows allow way to much stuff to happen to the cart during the payment process. For example, imagine a customer that pays using Paypal. Upon clicking the 'Pay now' button, they get redirected to paypal.com where the payment flow then goes on without our knowledge. Some customers (and particularly nefarious ones) might try to modify their cart while they are filling in the payment details, hoping that the extra value added to the cart will be validated along with the rest even though the paid amount no longer matches the total of the SO. This is not a huge problem in and of itself, as the cart will not be confirmed in such a case (indeed, the amount of the tx is checked upon payment feedback). However, this is still annoying for the maintainer of the database, since the payment/cart combination now has to be handled manually (e.g. refund the payment entirely or contact the customer to check the initial content of the cart and validate it with the correct content). In this commit, we introduce a mechanism to avoid this issue by duplicating the cart when the payment flow starts. This way, the duplicated cart is unavailable for the customer to modify and if the payment goes through, we can be assured that the card has not been modified in the mean time. The original cart gets deleted upon payment (to avoid 'recovery email' for abandoned carts, since it was not actually abandoned). Note that for payments done using a token, there's no need for this cart bait-and-switch since the payment is done in a single request - it is not really possible (or at least very impractical) for a customer to modify their cart during this process. TO CHECK WITH WEBSITE TEAM: - using sale_order_id get param in validation routes is unsightly - polluting the session again - session pollution logic should perhaps be factorized (used 2 times) à-la payment portal controller - m2o mechanism for original cart is a bit dumb maybe? + another relational field again... 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