b0a4451c19c3ebb4a1803e6dd9ea0b554b8cc708
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Anita (anko)
|
4d1a1f1c99 |
[IMP] payment, *: verify and reroute payment flows
This commit changes the way transactions linked to a document (sales order, invoice...) are created in a payment flow. Rather than receiving and trusting the transaction values from the controller, they are now read from the linked document, and the payment flow is rerouted to use the document's module's controllers instead of that of `payment`. This ensures that no unexpected value can be passed to the `create` method of a transaction, and simplifies the implementation of the payment flows of linked documents. task-3136240 closes odoo/odoo#126425 Related: odoo/enterprise#43212 Related: odoo/upgrade#5124 Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com> |
||
|
|
7e012dd544 |
[IMP] payment, *: replace providers with payment methods in payment forms
Before this commit, the payment providers (e.g., Stripe, Adyen...) available for payment were displayed on the payment forms. The customer had to select one to process their payment. After that, the customer had to select their preferred payment method (e.g., Credit Card, Bancontact...) from a list of payment methods supported by the selected provider over which the website administrator had close to no control. This was making the payment forms confusing because the payment methods were displayed sometimes more than once, if at all, in a non-controlled order, and behind the selection of a payment provider that customers should not have to deal with. As the payment method was selected in an iframe or directly on the provider's website, the information on the selection payment method was not available in Odoo. This posed many problems, among which were the impossibility of assessing whether a specific feature (e.g., tokenization, refunds, manual capture...) was available, not being able to easily identify payment tokens through the payment method logo, listing available payment methods on the website, sorting and fine-grained configuration of the available payment method, subpar payment method-specific display on the payment form (e.g., PayPal that requires displaying a "Pay with PayPal" button), etc. In this commit, the payment providers are thus replaced by the payment methods on the payment forms. All contextually available (depending on the country, currency, requested feature...) payment methods are displayed one after the other on a single-level list and in the order configured by the website administrator. Each payment method is "powered by" (i.e., linked) to a single payment provider: the first one, by model order, to support it. This allows, for example, offering the PayPal payment method through Mollie, which charges low processing fees, while also offering Klarna through Stripe, which supports more payment methods but charges higher processing fees. While doing so, the two different payment forms, "Checkout" and "Manage", are also merged together in a new, configurable case-by-case, payment form that is entirely redesigned to offer a better user experience. After payment, the information on the selected payment method is saved on the transaction and eventual payment record and updated with the information received from the provider. task-2882677 closes odoo/odoo#120446 Related: odoo/upgrade#5103 Related: odoo/documentation#5717 Related: odoo/enterprise#40666 Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com> Co-authored-by: Anita (anko) <anko@odoo.com> Co-authored-by: Brieuc-brd <brd@odoo.com> Co-authored-by: Valeriya (vchu) <vchu@odoo.com> |
||
|
tsm-odoo
|
b5896c9d03 |
[IMP] *: add generic make_jsonrpc method in tests
*: bus, crm_livechat, crm_mail_plugin, im_livechat, payment, payment_demo, pos_online_payment, test_discuss_full, test_mail_full, tests, website_livechat, website_sale. Several python tests have their own way to make jsonrpc requests. This PR adds a generic `make_jsonrpc_request` method to the `HttpCase` in order to provide a generic way to do so. At the same time, calls to `_open_livechat_channel` are removed in favor of jsonrpc request to `get_session`. This makes the tests more realistics (some incoherences were present like passing `country_id` to the open channel method while the user country id is not set...) Finally, this will ease the diff in the PR introducing livechat visitors as mail guests. part of task-3332628 closes odoo/odoo#130036 Related: odoo/enterprise#44840 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com> |
||
|
william-andre
|
0d30cc2bc9 |
[IMP] models: manage sub companies with check_company
Allow some models to be delegated to the main company of the object. For instance: * Have company Parent and Child * Child has access to all the accounts of Parent * When creating a document in Child using an account of Parent, there shouldn't be a consistency error. In order to do that, a new method `_check_company_domain` has been added. This method is used when `check_company=True` is set on the field declaration to: * filter relational fields in the UI [^1] * validate relational fields when writing on them in `create` and `write` That method should also be used in the business code for models likely to be shared amongst company branches instead of hardcoding the domain based on `company_id`. The same applies on domain restriction on the field declaration: the flag `check_company` should be prefered instead of providing the domain explicitly based on `company_id`. Since a lot of validation and filtering will now be done based on `parent_of`/`child_of` of the company, some support has been added for that special case in `filtered_domain` in order to avoid doing additional queries. task-3371677 [^1]: because of that change, support has been added on the python interpreter of the client to allow concatenatng domains. Part-of: odoo/odoo#125642 |
||
|
Theo VINCENT (thvi)
|
3fa87c8c47 |
[ADD] pos_online_payment, *: add online payments
*: point_of_sale, pos_adyen, pos_hr, pos_mercury, pos_restaurant Adds online payments in Point of Sale using the payment module. The pos_online_payment module is meant to be used by shops for paying online instead of using a physical terminal and by restaurants for paying an order either from the paying station or in the self-order process (smartphone used to order and pay online). The module depends only on point_of_sale (and account_payment to support online payments). The online payments support for self-order will be added in another commit. The feature can be used by configuring a special pos.payment.method for one or many pos.config. Operation: The frontend session user can enter one or several online payment method lines (with or without other payment methods). When he validates the order, if the online payment amounts are valid, a popup with a QR code is displayed on the frontend screen and on the customer display. This QR code allows the customer to open the payment page to pay online for the order. The amount to pay for an order on the payment portal is the remaining unpaid amount or a lower amount if several online payments lines are used. Therefore, at any time, the customer will be able to pay the amount of the order that is unpaid, without requiring a staff operation to update the amount to pay. When an online payment is done for a POS order, the generated account.payment is linked to the POS order through a pos.payment that is created with the online payment method configured for the pos.config, and the POS order paid process is triggered (it is the responsibility of the server to finalize the validation of POS orders that have at least one online payment, and not the responsibility of the POS session web client). If for any reason, there is no longer any online payment method configured for the pos.config of the order, a new one can be created automatically and exceptionnaly used to link the done payment with the POS order. This guarantees that any online payment saved by the payment module will be linked to the POS order. The session web client is notified of successful online payments through web socket communication, to make the cashier screen automatically and quickly react to payments. If several online payments are used for a single POS order, they are processed one after each other. Working principles: - The POS session web client is not allowed to save online payments on the server. Only the Odoo server, which handles the payment, can save online payments for a POS order. - The POS session is only responsible for saving the order (especially other payment methods) and the next online payment amount to pay (in case of several online payments) on the server before the online payments are made by the customer, and for displaying the online payment status and the link (QR code) to open the payment page. That means that modifications that are made after the order is fully paid are not taken into account by the server. - Before validating an order, the POS session checks with the server if any online payment has been made for that POS order. If the user wasn't aware of one, the validation process is aborted, notifying him. - The sensitive online payments data is received by the frontend user with RPC to the server when validating an order, cancelling an online payment or receiving a notification through the POS bus (web socket communication). This data is used to update the cashier data for the specific order. - No sensitive information is sent through the POS bus (web socket communication). Indeed, the bus communication is only protected by the name of the channel, and there is no mecanism to prevent several attempts. Therefore, no sensitive information is sent through it, only a notification to invite the local browser to do a safe RPC to the server to check the new state of the order. - Online payments for a POS order cannot be modified or removed when they succeeded. Checks ensure to never allow an online payment to make the total paid amount greater than the total amount of the POS order. - If the frontend user clicks on the "Cancel" button of the online payment popup, the order can potentially still be paid online. Indeed, the order will be removed from the server only if it was added only for the online payment flow, and any order that is not paid can be paid on the online payment portal (if the customer has the web link). This behavior ensures that in a shop, starting an online payment and then cancelling it doesn't prevent the user to close the POS session. And it ensures to don't delete a draft order that is used for other flows, like in a restaurant or when there are trusted POS configs. Payment portal features: - The payment portal pages of a POS order are protected with its access_token. - If the amount of the order has changed when the customer clicks to pay, an error is fired to notify him and give him the choice to continue or abandon the payment. - An exit_route argument (an URL) can be passed to allow the customer to exit the payment portal at any time (with a button), which could be used for self-order flow. - A button to go back to the payment page is displayed when an error occurs during a payment transaction, which allows the customer to retry a payment without needing to scan again the QR code. - If the customer is not logged in in the payment portal (most frequent case), it is considered as the public user partner for the payment flow to don't give him privileged access to sensitive data like payment tokens. - The accounting process of online payments for POS orders is made in the same way that the pos.payment.method that have split_transactions to True. - The POS customer of a POS order has no link with the customer making an online payment for that POS order. - The payment portal is made using the pos.order id and not the pos_reference because the latter is not guaranteed to be unique. Some tests have been written, especially one that simulates a whole online payment flow starting from nothing, creating an order, requesting an online payment, faking this online payment by doing web requests to the payment portal, then finally closing the POS session to check that there is no accounting issue. The design of the payment portal is temporary. closes odoo/odoo#123237 Task-id: 3276404 Related: odoo/enterprise#41776 Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com> |