Some layout change of res_config_settings_views.xml to make it more
readable.
Now, important parameters are on the top of the page.
closesodoo/odoo#139287
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Previously, QR codes could only be obtained by printing an A4 page.
The problem The problem was that some customers would want to create a
specific design and get the raw image of the QR code directly.
A button has now been added to the settings to download a zip file
containing all the QR codes in PNG format.
---
A change has been made to the restaurant table form to enable editing of
the access ID. editing of the access ID. This is useful if a customer
has reset his QR codes and wishes to put them back.
---
Previously, the "close" button in the table selection popup didn't work.
This has been corrected with this PR.
---
Small design change to the display of products that don't have an image
in the selfOrder.
Part-of: odoo/odoo#139287
When implementing the Stripe terminal in a device that will be used by
end-users, we need to ensure that it is the server that will validate
the data and not Javascript as is the case in Point of Sale.
Nevertheless, we're using the Javascript SDK for the connection to the
terminal, as we don't want to add a Python dependency to the Odoo server
How the SDK works:
During initialization, we create a terminal via the `create` function.
This function will receive as argument a function that generates a
unique token with a precise lifetime managed by the SDK. These tokens
must be supplied only to trusted devices, such as the kiosk, accessible
only if we have `access_token` from the `pos_config`.
Then, when making a payment, we make a request to the Odoo server to
create a Stripe payment request from the backend, connect the terminal
to the frontend via the `connectReader` function and send it the payment
request via the `collectPaymentMethod` function, passing it the
`client_secret` sent by the Odoo server.
We then use the `processPayment` function once the customer has
presented his payment card to finalize the payment on the terminal.
Finally, we call the `capturePayment` function, which contacts the Odoo
server to validate the amount and payment. If this is the case, it will
mark the order as paid and send a message via websocket to the kiosk to
display the confirmation page.
During these various stages, trust is placed in the server and not in
the frontend.
Stripe Javascript SDK documentation:
https://stripe.com/docs/terminal/references/api/js-sdkclosesodoo/odoo#138646
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit allows to share kiosk orders with all pos_configs. A new pos_session
boolean attribute is added to check if there is a kiosk config in the company.
In point_of_sale and pos_restaurant, if the company they belong to contains
a kiosk config, the ticket_screen will retrieve the kiosk draft orders.
closesodoo/odoo#138264
Related: odoo/enterprise#49294
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
*point_of_sale, pos_self_order, pos_self_order_epson_printer
In this commit we introduce the functionality that allows
the pos_self_order module to generate receipts.
At the moment, this is possible by using Epson Printers via HTTP.
This is done through the use of the newly added bridge module
`pos_self_order_epson_printer`.
In order to generate the data required for the receipt we add more data
on the first load of the kiosk ( such as company information ) and
also in the `_export_for_self_order` method.
Printing is done through the `printer` service from POS.
closesodoo/odoo#137397
Task: 3487638
Related: odoo/enterprise#48304
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Change of domain applied when clicking on the "home buttons" button of
a self order, now showing buttons linked to its pos_config + those
linked to no pos_config.
Part-of: odoo/odoo#138897
If a pos_config has no category restrictions and receives a product with
no category, a default category named "uncategorised" will be created.
Technical change: previously, categories were grouped according to their
name, the problem being that if two categories had the same name, this
would cause problems; now they are grouped by their ID.
Part-of: odoo/odoo#138897
Online payment method added to kiosk. This works in the same way as in
the mobile SelfOrder, except that the payment page does not open
automatically in the kiosk. A QR code appears and the user is asked to
scan it to make the payment on their phone.
Once the QR code has been scanned, the page on the kiosk updates to show
"payment in progress", and once the payment has been validated, the
validation page appears on the kiosk. These different statuses are sent
via websocket.
closesodoo/odoo#138825
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Before, when ordering on the kiosk/mobile, no confirmation page was
displayed, only a notification.
Now, a confirmation page displays the tracking number, the amount paid
and, if present, the customer's table...
Part-of: odoo/odoo#138013
This commit consist of adaptation of the pos_self_order module to send
orders to preparation display. The main changes consist of sending the
table stand number that the client put in to the backend to be shown
in the preparation display. It also consist of moving the tracking
number from the pos_self_order module to the point_of_sale module so
that every number has a tracking number.
closesodoo/odoo#134980
Task-id: 3495477
Related: odoo/enterprise#47203
Signed-off-by: David Monnom (moda) <moda@odoo.com>
This commit introduce the information button on the product card in the
self order mode. This button open a popup with the newly created field
"description_self_order" which is an HTML field allowing the user to
have a very customizable description for the product.
It also removes the description_ecommerce field from the product view
form as it is a field used in the website and not adapted for
the backend (css/js not compatible).
closesodoo/odoo#138216
Task-id: 3512835
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
**Steps to reproduce**
- Open general settings of pos.
- Select/Create a Point of Sale that is kiosk to see the `Splash screens` field.
- The field is pre-filled with 3 images.
- ISSUE: Try removing the images and save, they won't be removed.
**FIX**
- This is because of the `write` operation made from the `res.config.settings`
model to the `pos.config`.
- When removing an image, the field will be given `link` commands, linking the
remaining images. This is wrong because it won't unlink the images that are
deleted.
- To ensure the deletion, we reinterpret the command to the splash screen images
field if the command comes from the res.config.settings.
- We introduce a context called 'from_settings_view' such that it's set to
true when the write is from the `res.config.settings` view.
- And specific to the pos_self_order, we compute the items that should be
unlinked and we append the unlink commands to the original set of commands
for the splash screen field.
closesodoo/odoo#137819
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Previously, mobile self-order was not available when restaurant mode was
deactivated.
Now it's possible to activate self-order mode without the restaurant
option activated. Self-order will then be forced to "pickup zone" mode
and pay after "each order".
---
Previously, when the self-order was closed, a popup indicating this
appeared in full screen.
Now, this popup has been replaced by a banner at the top of the screen,
so that the self-order can still be used in read-only mode.
---
Previously, when the kiosk was loaded and there was no product available
in the pos_config, a traceback was raised. Now, when we are in this
case, we display a message indicating to first add products in full
screen.
---
Fixed a traceback when trying to start the POS by clicking on the image
of the landing page. The function start() had been removed. It is now
restored.
closesodoo/odoo#137671
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Steps to reproduce:
- Activate "Eat in / Take away" (`pos_self_ordering_takeaway`) setting.
- Set the alternative fiscal position.
- ISSUE: When selecting take away in the app, the take away price is not shown.
FIX: The issue is because during the loading of the products, only the default
price is computed. In this PR, we are now computing the take away price as well.
And in the ui, depending on the choice, we are showing the correct price.
closesodoo/odoo#137653
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Replace all the calls to get_resource_path to the better file_path or
directly use file_open when not needed
Doing both a get_resource_path and file_open means checking twice that
the file exists.
Doing a simple path concatenation before a file_open is safe.
If given to another method (e.g. etree.parse), calling file_path is
the prefered method.
Note that get_resource_path used to return False when the file does
not exists while file_path/file_open raises a FileNotFoundException
closesodoo/odoo#135607
Related: odoo/upgrade#5187
Related: odoo/enterprise#47475
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This reverts commit 3b9401c354.
It shouldn't have been merged in the first place. The PR was `r-` but it
seems like the mergebot bugged and still merged it because there was an
occurence of `r+` in the sentence which asked robodoo to `r-`.
> robodoo r- just to be sure, since there was a random r+ not [...]
Rationale of the revert:
- Bad field name:
- "ecommerce" in product module
- "ecommerce" but used in POS
- Arguably very low value to share the field -> This field is used in
ecommerce to add info exactly between the price and the name of a
product. There is low chance that you want to share that exact
information with the POS.
- Technically, it couldn't work. What you design in website builder on
the product page is related to website assets JS and CSS, which are
not loaded neither in the backend and neither in the POS.
It was leading to multiple critical issues, mainly:
- Losing the whole style of the content (CSS)
- Breaking completly the snippets (visually and design wise) (CSS/JS)
- Not even show (JS is in charge of showing the content eg)
Note that the same issues were already existing in that field in the
backend (it's shown in the product form view). The ecommerce team was
looking for a solution to make it work, but it's impossible as to work,
it would need the website / frontend assets, which can't be loaded in
the backend / POS.
The cancel of this PR was validated with PO of POS and ecommerce
following those explanation, which they weren't aware of.
Apart from this revert, further PR will be done to:
1. Remove the field from the product form view (ecommerce app)
2. Create a new field for POS
Revert of https://github.com/odoo/odoo/pull/136906
task-3524272
closesodoo/odoo#137514
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
After merging of the mobile and kiosk app for self order
(https://github.com/odoo/odoo/pull/136051), the pay after selection that
requires the "upgrade to enterprise" label was misplace. This fix restores the
misplaced label.
closesodoo/odoo#137413
Signed-off-by: David Monnom (moda) <moda@odoo.com>
List of improvements:
- Product list button is now configurable and not hardcoded. Demo data
is updated accordingly. When a new `pos_config` is created the button is
created with the default value "Order Now".
- Fix error 403 error when `pos_session` is not in opened state.
- The `order_widget` display now the number of items to order when all
items are not ordered yet and the total amount to pay and the count when
all items are ordered.
- The `order_widget` button no longer displays the order price.
Mobile mode:
State of order_widget button on `product_list_page`...
..when configured in meal mode, no online payment:
- With new orderlines: "Order"
- Witout new orderlines: "Order"
..when configured in meal mode with online payment:
- With new orderlines: "Order"
- Without new orderlines: "Order"
..when configured in each mode with online payment:
- With new orderlines: "Order"
- Without new orderlines: "Order"
State of order_widget button on `cart_page`...
..when configured in meal mode, no online payment:
- With new orderlines: "Order"
- Witout new orderlines: "Pay at Cashier"
..when configured in meal mode with online payment:
- With new orderlines: "Order"
- Without new orderlines: "Pay"
..when configured in each mode with online payment:
- With new orderlines: "Pay"
- Without new orderlines: "Pay"
Kiosk mode:
State of order_widget button on `product_list_page`...
..when no payment methode:
- Without new orderline: "Pay at Cashier" (disabled)
- With new orderline: "Pay at Cashier" (active)
..when payment methode:
- Without new orderline: "Order" (disabled)
- With new orderline: "Order" (active)
State of order_widget button on `cart_page`...
..when no payment methode:
- Without new orderline: "Pay at Cashier" (disabled)
- With new orderline: "Pay at Cashier" (active)
..when payment methode:
- Without new orderline: "Pay" (disabled)
- With new orderline: "Pay" (active)
closesodoo/odoo#137387
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
This commit adds a popup to show product information when clicking on an
info button in the product card in the self order app. The popup shows
the ecommerce description and the name of the product.
The ecommerce description field has thus been moved from website_sale to
the product module so that the pos_self_order module can use it.
closesodoo/odoo#136906
Task-id: 3524272
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
pos*: point_of_sale, pos_sale_product_configurator, pos_self_order
This commit removes the product info button and put a button on each
product card to open the product info popup.
The commit also adds a new field on the product template model to
track the availability of a product to the self ordering mode. This
field can be changed from the product form view or from the product
info popup directly in the POS. If the field is set to false,
the product will not be shown in the self ordering mode.
The commit also adds new filter and search fields on the product
list view in the backend.
closesodoo/odoo#136467
Task-id: 3515881
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Previously, the custom value of an attribute was not saved in the
database when selected via the point of sale or Self Order. The only way
to see this value was via the product name.
Now, this custom value is saved via the `product.attribute.custom.value`
template, in order to follow the behavior of the Sale module.
Others fix in this PR:
- Prevent to pass to payment page when we are in mobile mode. Only kiosk
mode is allowed to do so.
- Hide "Modify" button in the cart page when the line is already sent to
the server.
- Make the language popup behaviour available in mobile mode too.
closesodoo/odoo#136612
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Previously, the self-order code and parameters were split into two parts
mobile and kiosk.
Now kiosk and mobile have been merged with each other to simplify
maintainability.
closesodoo/odoo#136051
Related: odoo/upgrade#5174
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Following the Odo comment https://github.com/odoo/odoo/pull/129562#discussion_r1306030434
We need to ensure that we have a default user for the mobile SelfOrder
when no session is open.
If we don't have a user, the system will be in sudo mode and the price
calculation will be erroneous because the system has chosen the wrong
taxes: it doesn't know which company to use to calculate the taxes.
We now force the setting of a default user for pos_config with mobile
selfOrder enabled, so that when no session is open, the default user
will be used.
closesodoo/odoo#134273
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Previously, when ordering with the Self app and paying after each order,
since paid orders aren't displayed on tables in floor plan, and orders
aren't send to kitchen directly. The flow is stuck.
This PR makes sure that the kitchen display is installed if the pay
each order is set. If not it will install it.
Because the kitchen display is only available in Enterprise, the
paying after each order mode is not available in community. When selecting
the mode in community the upgrade to Enterprise popup will be displayed.
task-3429195
closesodoo/odoo#135534
X-original-commit: 6c2dd0a53cb4dd33af01fdc3553ba2b379188265
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Loukas Wets (lowe) <lowe@odoo.com>
Following AVW's review, the following changes have been made to the QR
code page:
- Generic QR codes are only added when in QR menu mode.
- Generic QR codes now fit on a single page.
- There is now a sample URL in the description.
- UI change.
- Description change.
Other fix:
Before, fields in res_config_settings.py were not `related` to fields in
pos_config. These have now been changed to `related` fields.
The compute function managing these old fields has also been removed.
closesodoo/odoo#133137
Taskid: 3478173
Related: odoo/upgrade#5112
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
When selecting an attribute value in POS, what we store is the `description`,
which is a string that represents the selected attribute values.
Ex: selecting `Size: M` and `Material: Leather` will result in the description:
`(L, Leather)`.
This choice does not lead to a logical API for dealing with product attibutes.
In this pr, we add a new field that stores the selected `ids` of
`"product.template.attribute.value"` and remove the
`selected_attributes` `Json` field from the `pos_self_order`
override of the `pos.order.line` model.
The `attributeHelper` function from the `tour_utils.js` file
from `pos_self_order` is improved such that it can now handle
both checking if a certain attribute is selected and actually
selecting an attribute.
closesodoo/odoo#126398
Task: 3378533
Related: odoo/upgrade#4992
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
List of improvements:
- Add `Is a Kiosk` field when creating a new POS config
- Add category and change the image of the combo demo product
- Hide useless settings when kiosk mode is enabled
List of fixes:
- Fix bootstrap carousel traceback when no image is set
- Changed the warning sentence concerning adyen payments
- Fix start category in kiosk
- Fix sync between Self Order mobile and PoS restaurant, now new Lines
from restaurant are added to the mobile order
- Fix product reminder when adding something in PoS mobile
closesodoo/odoo#134508
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Carousel is a slideshow for cycling through a series of images. It is a
dynamic display of content that can be used to show a rotating series of
pictures, articles, or advertisements.
Following the specifications, the carousel is displayed on the landing
page of the kiosk mode. Images of carousel can be configured from the
settings (ir.attachement).
Used carousel is a bootstrap carousel.
closesodoo/odoo#133760
Taskid: 3484170
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
*: pos_discount,pos_loyalty,pos_restaurant,pos_self_order
In a previous commit (669b9fcc2f) we added the
backend logic needed for creating combos in `pos`.
In this PR we add the combo functionality to the classic pos ui.
This means that products can now be grouped together and sold as a combo.
ex: Create a product called `Burger Menu` with type='combo'.This product will
have multiple combos associated with it, for ex:
- Drinks - will contain the list of drinks from which the customer can choose
- Main Course - will contain the list of main courses from which the customer
can choose
- Dessert - will contain the list of desserts from which the customer can choose
In the event that one of the products inside one of the combos is to be more
expensive, this product will have a specific `combo_price` which will be added
to the main combo product's price.
We add the relational fields `combo_parent_id` and `combo_line_ids` in the
`pos.order.line` model. In the previous example, `combo_parent_id` will contain
the `id` of the `orderline` of the `Burger Menu` product.
In many cases `combo lines` have to be handled together. For example, deletion
of an orderline containing a product from a combo implies the deletion of all
other orderlines containing products from that combo. This means that multiple
methods from the codebase had to be changed for this reason. Places that needed
changes for this reason:
- `split_bill_screen.js`
- `addProductToCurrentOrder()`
- `remove_orderline()` and `add_orderline()` from the `Order` js model
In this PR we also:
- improve the demo data such that it contains a `pos combo`;
- refactor the `ProductItem` component such that it relies on a stateless
component. This stateless component can now be used anywhere; ( it is now used
in the popup which allows selecting the desired combo products )
- add a new method called `is_pos_groupable` on the `Orderline` js model. Before
we relied on the product unit to see whether or not a product is groupable. We
now needed a new mechanism, which could account for different reasons for
which products are not groupable, such as belonging in a combo;
Note on price calculation:
- The idea is simple, imagine a rectangle divided into two parts. The whole
rectangle is the total order, whereas the two partitions are the orderlines.
- Now, imagine shrinking the rectangle by a certain factor. This shrinked
rectangle represents an order containing a combo -- because normally, a
combo results to smaller price. The two partitions are also shrinked by the
same factor.
- So the calculation will be:
- Nominal total price is calculated. This is the sum of the orderlines'
prices when they are added individually. This represents the whole
rectangle.
- Target price is derived from the combo product's price and selected
components' combo prices. This represents the shrinked rectangle.
- Reduction factor is computed as the ratio between the target price and the
nominal price.
- Each component's unit price is adjusted by multiplying the reduction
factor.
- When the unit prices of the components are computed, we now let the normal
price computation take place.
- A spreadsheet is prepared to show a sample calculation:
https://docs.google.com/spreadsheets/d/1iOdnaILnvKiaf2_z7jTijYiVfB_3mjKWjq6nOB70Un0/edit#gid=0closesodoo/odoo#129483
Task: 3430636
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Co-authored-by: Joseph Caburnay <jcb@odoo.com>
Kiosk parameters were not displayed when the pos_self_order_sale module
was installed.
This was due to an overridden function in this module that didn't call
super().
This is now fixed and functional.
closesodoo/odoo#133910
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
To begin with, there are two different fields.
- tracking_number: used with the kiosk or self so that the customer can
track his order.
- name (order_reference): classic order number, used to find them in the
odoo backend.
Example of tracking number:
- A1
- B1
Example of order_reference:
- Classic PoS: Order 00001-001-0001
- SelfOrder Mobile: Self-Order 00001-001-0001
- Kiosk: Kiosk 00001-001-0001
Two ir.sequences are used to generate these numbers. The first to
generate order_reference numbers per session, and the second to generate
tracking_numbers, which are common to all pos_configs and reset once
a day.
closesodoo/odoo#133902
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
*:point_of_sale,pos_adyen,pos_online_payment_self_order,pos_restaurant,
pos_sale,pos_self_order,pos_self_order_adyen,pos_self_order_restaurant,
pos_self_order_sale
This PR adds the kiosk to the existing `pos_self_order` module, which
until now has enabled end-users to order their restaurant meals directly
from their smartphones.
We've added the possibility of creating kiosks / totems (devices with
large touch screens) that allow users to order their menu directly
without having to go through a waiter.
Once the order has been placed, the user will be invited to pay either
by adyen, already integrated into this PR, or at the counter.
At the end of the order, the user will receive an order number and his
table number if `service at table` is activated.
Main differences with the Self-order mobile:
- Kiosk shouldn't be accessible publicly
- Kiosk should support payments via card readers
closesodoo/odoo#129562
Design: XLU
Dev: ADGU & MODA
Taskid: 3323163
Related: odoo/upgrade#5024
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
In order to improve the self order user experience, QR code generation
has been improved. Now, the user can reset the access_token linked to
the QR code and then regenerate them, he can also redownload the QR code
whenever he wishes.
The content of the QR code PDF has also been changed. Now, for each
table a QR code is generated and inserted in the PDF with the name of
the table and its unique identifier (access_token).
closesodoo/odoo#129100
Taskid: 3377335
Related: odoo/upgrade#4958
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
**Steps to reproduce:**
- Install pos_self_order.
- Create a product with a price of any price, say 100.
- Assign a tax of 10% to the product.
- Create a new company and switch to it.
- With the same product, add a new tax, say 20%.
- Go back to the original company.
- Open a bar (restaurant pos.config) that allows self order which also loads the
product.
- Open self order page and add the product.
- [BUG] The product's price is not only 10%-taxed, but also 20%-taxed.
**Explanation and fix**
The issue is caused by use of sudo almost everywhere in the context of
pos_self_order. This commit removes/reduces this use of sudo in many places and
contextualize the records involved in the calculation such as pos.config,
product.product, etc. to be the ones of the company and the user who opened the
current pos.session.
After this changes, only the taxes that belong to the company of the pos.config
record are used in the price and tax calculations.
closesodoo/odoo#131140
X-original-commit: 7ce7f3e21ad8f457742e27f88b7146c7d8fff5f3
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
*: pos_self_order
Adds online payment support for self-order flow in the Point of Sale app.
- Adds a configurable online payment method specific to the self-order flow, which is optional in "Pay after meal" mode, required in "Pay after each" mode.
The POS config of a restaurant can use 2 different online payment methods, one for the frontend cashier flow, and another for the self-order flow, or can use the same for both.
By default, if an online payment method is configured for the self-order flow, any new order paid online will be paid with that payment method.
But if the cashier requests an online payment with a different online payment method, that payment method will be used for that order during the time the cashier keeps his online payment popup open (without cancelling the online payment) (after cancelling the online payment, the order could potentially still be paid online, and if so it will use the online payment method of the self-order if one is configured, otherwise the online payment method of the cashier flow).
- Allows the customer to open the online payment page of an order from the self-order UI.
In "Pay after meal" mode, if an online payment method is configured, the "Pay" button is displayed when the customer order is saved on the server, otherwise the "Order" button is displayed (even when the order has been sent to the server and then modified without sending it again).
Otherwise, if no online payment method is configured, the "Pay at cashier" unclickable button is displayed.
In "Pay after each" mode, the "Pay" button is displayed everytime.
- Replaces the self_order_after_each_cart_tour test.
closesodoo/odoo#127869
Task-id: 3171698
Related: odoo/enterprise#44055
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Previously, access_token were linked to tables. These tables were linked
to a floor_plan, which could be linked to several pos_configs.
The only way to access the self-order was to obtain a valid table
access_token. This behaviour was not correct because sometimes we would
allow table selection directly in the interface or commands without
a table.
Now, access_token is managed by pos_config. When a user has this token,
they can place commands and select the table they want if the option is
enabled.
closesodoo/odoo#126186
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Previously, when an order was paid for at the restaurant counter,
the self-orderer received no update that the order had
been paid for.
Now, if the customer self-order page is still open on their phone,
it will receive a notification via websocket that the order has been
paid for from the restaurant counter.The order will no longer be
editable.
In the event that they have already closed the self-order when paying
at the counter, the next time they return to this page. An RPC request
will be made with the access_token of the old order and the
states will be aligned.
closesodoo/odoo#125921
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
*: point_of_sale, pos_self_order
Changes:
- Adds a default restaurant with some default usual settings (with tips after payment if the company is in the United States) but no floor in the Point of Sale app. Makes pos_restaurant module auto installed with point_of_sale.
- Makes some restaurant settings enabled by default (only for restaurants).
- Adds loadable default demonstration data for onboarding (only when no real product is available in POS), specific to a restaurant. The default demonstration data for onboarding of point_of_sale and pos_restaurant are loaded together (if pos_restaurant is installed) to make it so an user that clicks to add demo data will have demo data for the default point of sale and also for the default restaurant (and the current restaurant if it is different than the default one). Makes the load demonstration data button visible when there is no product with a positive price available, because without that condition the tips (in restaurant) and discount were preventing the display of the button.
- Hides the Preparation Printers menu item if there is no POS config using the printers.
- Renames some labels.
Fixes:
- Adds checks to always set set_tip_after_payment to False if a point of sale is no longer a restaurant or if the tips are disabled. This is needed because the code of pos_restaurant seems to be written considering that set_tip_after_payment is True only when the point of sale is a restaurant with the tips enabled (which wasn't guaranteed). Without that checks, some tests like ReceiptScreenTour fail. Another solution to make the tests successful without that checks would be to add !this.env.pos.config.module_pos_restaurant in pos_restaurant/static/src/js/Screens/PaymentScreen.js:16. But because other parts of the code only check the value of set_tip_after_payment, I think it is better to opt for the additionnal checks.
- Fixes duplication of displayed product categories when loading demonstration data.
- Fixes products before loading demonstration data that were kept and displayed after (discount for example).
- Fixes categories and therefore communication with the preparation display after loading demo data in a restaurant.
- Adds a check on the server side to prevent demonstration data loading when there is at least one valid product for POS.
- Fixes order count display when "NaN" (in floors and tables view).
- Fixes arguments of orm call for set_not_tip (model and method names were not given in the right order).
closesodoo/odoo#117941
Task-id: 2484291
Related: odoo/enterprise#39450
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Correction of the order in which categories are displayed in the self
following the deletion of the "order" argument on the product search
in a previous PR.
closesodoo/odoo#125743
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Previously in the front-end there was a notion of "tag" which used
product categories. This led to misunderstandings, because in the
backend there was a notion of tag and category for the products.
Now, the name of the category field is aligned in the backend and
the frontend.
The product model ID field has also been changed from product_id to
id during loading.
Part-of: odoo/odoo#125743
Currently, a product can only be part of one `pos_category`.
This PR changes the relationship between the `product` and the `pos_category` from a `One2many` to a `Many2many`.
closesodoo/odoo#122907
Task: 3138825
Related: odoo/enterprise#41791
Related: odoo/upgrade#4739
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
General refactoring of the codebase. Inline of certain components
that had no logic in the JS side, the XML of these components was
directly added to the place where they were called.
Simplification of the python controller, inline of many functions and
separation of the logic. There is now one function that manages new
orders and another that manages and updates existing orders if we are
in "pay after meal" mode. In "pay after each" mode, orders cannot be
edited.
Addition of different models, product, order and orderlines in order to
facilitate the use of these objects between the backend and the
frontend.
Added price calculation on the serverside because we can't trust the
data coming from the customer in the self since no identification
is required.
Management of last change sent added. Thanks to this, users will no
longer be able to click on the order button if no changes have been
made to the order.
closesodoo/odoo#122901
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Currently from the pos_self_order app a customer can only view the menu.
This PR adds the option to order items.
A customer of the restaurant will now be able to scan a qr code on their table, and navigate to a website where they will be able to order items from the pos.
The customer can select product variants and add a specific notes for each of the ordered products.
This version does not support online payment. This means that the customer will still have to pay by the usual methods.
The pos can be configured such that a customer can add items to an existing order. For example, ordering a second coffee will result in an update of the existing pos order containing the first coffee. Alternatively, the pos can be configured such that each order made from the web app results in a new pos order. Orders made from the self order app will be placed in the same pos session as regular orders. Once a customer orders from the self order app, a new order will appear in the pos app. Thus, a waiter will be able to quickly see all the orders placed by customers from the self order app. He/She will then be able to send the order to the preparation display. This step has to be done manually.
In the interest of security, each table now has an associated access token. It is included in url that the customer gets from the qr code. When sending the order, the self order app also sends back to the server this access token. The server will only process the order if it receives a valid access token. When placing an order, the server will respond with the pos_reference and access_token of the created order. The web app will keep this data and will send it back to the
server as a proof of ownership in the event that it intends to get the latest state of the order or to update it. The server will only reveal information about an existing order when the request contains a valid pair of pos_reference and access_token.
closesodoo/odoo#121029
Task: 3058586
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
New module that would allow restaurant customers to see the menu on their own devices by scanning a qr code and navigating to the provided link.
Task id 3232765
closesodoo/odoo#114022
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
“moda”