Before this commit:
===================
In the back-end, there is only one field "date_order" is used, while on the
frontend side, there are two separate fields: "creation_date" and
"validation_date," which causes confusion in the code flow and leads to
redundancies.
After this commit:
==================
Revised the order date flow by eliminating the confusion stemming from the
separate "creation_date" and "validation_date" fields. Both have been
consolidated into the "date_order" field, offering clarity to the order date
process.
task - 3482072
closesodoo/odoo#133293
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When the JS client cannot retrieve the online payment data from the server for an order that has no online payment line, and that has been previously saved on the server (and has its server_id defined in JS), an error is thrown if the user confirms that there is no online payment for this order.
This commit fixes this issue.
closesodoo/odoo#133787
Task-id: 3484441
X-original-commit: 129bc21b609d6d3310d038e631f82bae56c14e74
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In this commit, all usages of env._t() are replaced by _t().
In templates files, env._t() didn't work because terms used
in attributes where not extracted into the translation files.
Only string are exported from .xml files to translation files.
So, to make it works, we set a variable that is then used
in attributes.
For example :
<t t-set="string_to_translate">String to translate</t>
<Dialog title="string_to_translate>...</Dialog>
task-3292454
closesodoo/odoo#131390
Related: odoo/enterprise#45631
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Since the use of Bootstrap, the online payment popup is no longer correctly displayed.
Steps to reproduce:
- Configure an online payment method for a shop
- Open a session for that shop
- Make an order
- Select the configured online payment method in the payment screen
- Click on "Validate" button
The online payment popup is displayed.
The fix consists of adding back the display of this popup as it was before the Bootstrap use.
closesodoo/odoo#132002
Task-id: 3468071
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
Improve gettext to directly handle value injection within translations,
removing the need for sprintf.
closesodoo/odoo#123932
Related: odoo/enterprise#45370
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
*: 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.
closesodoo/odoo#123237
Task-id: 3276404
Related: odoo/enterprise#41776
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Jitendra Prajapat