odoo_source

3 Commits

Include renames

Author SHA1 Message Date

Author	SHA1	Message	Date
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>	2023-07-31 23:21:10 +02:00
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	2023-07-20 11:49:05 +02:00
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>	2023-07-18 19:27:56 +02:00

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>

2023-07-31 23:21:10 +02:00

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

2023-07-20 11:49:05 +02:00

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>

2023-07-18 19:27:56 +02:00