Steps to reproduce the bug:
1. Install PoS
2. Change the Shop type to "Bar/restaurant" (into its setting) then save
3. Go into the newly created "Bar" settings
4. Enable "Direct devices" (with any IP)
5. Open a session on Bar
6. Pick a table
7. Ignore the "Connection to the printer Failed" error
8. Take a coca
9. Click on the "Bill" button
10. On the Bill Printing screen, pick "Print"
Bug:
A traceback was raised
opw:2382350
closesodoo/odoo#62790
X-original-commit: 00ba9d2d244314ee09ffefb616f9bc3a26027092
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
There is a situation in pos_restaurant such that when an order
is deleted from the ticket screen, it persists to show when the
table is opened. To reproduce:
1. Create an order in T1 then add items to it.
2. Get out of the table (back to floor).
3. Open ticket screen.
4. Delete the order in T1.
5. Close the ticket screen.
6. Open T1, the order is still there (bug).
This commit fixes this behavior such that in step 6, new order should
show and not the deleted order.
Note that we also made a change in the template in order to allow
checking the number of synced orders during testing. We want to make
sure that the table is clicked when the sync finishes to prevent
concurrency issue during testing.
closesodoo/odoo#62488
X-original-commit: e6e2a7392a5dd518c3f0df1c1ac0f90b0cba78f4
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
The alignment of quantity and product name was off when the product
name was split into multiple lines.
opw-2360424
closesodoo/odoo#60547
X-original-commit: 58404f299f7fa9128758b4b7830a6393c64ad085
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
Issue
- Install "Point of sale"
- Create a new one.
- Activate the "Is a Bar/Restaurant" feature and save
- Activate the "Bill Printing" feature then save
- Start a new session
- Add a product A
- Click on "Bill" then "Print"
- Then click on "Ok" to go back to order
- Add a product B
Error is raised ("Cannot read property 'add_product' of null").
Cause
Trying to add a product to an order who is destroyed
if the bill has been printed.
Solution
If the bill is printed (and not the receipt), set '_printed' of
the current order to 'false', therefore it will add the product
to the current order.
opw-2341115
closesodoo/odoo#59465
X-original-commit: 6683a9929d68be956854000fa9b3e9f99ceecdfb
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
This random runbot error happens when the tour manager is steps ahead of
the rendering:
1. clicks Second Floor button
2. checks T1 - this won't fail even if the Second Floor hasn't finished
rendering because Main Floor has tables that start with `T1`.
3. clicks a table in Main Floor with T1 in name
4. Then error because the back to floor button should be Second Floor.
Tables that start with `T1` is created in Main Floor during the tour,
however, we also have one in Second Floor. To make sure that the runbot
correctly waits and clicks for the right table, we use T3 in Second
Floor instead of it's T1.
closesodoo/odoo#59170
X-original-commit: 8e65a220cadefe41df9fcc2172d60ff90ea5b584
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Checking the log of the runbot error, there is an extra `create_from_ui`
rpc call for `restaurant.floor`. This is because when table T4 is clicked,
it is still an `EditableTable`. It is possible that the full rendering after
toggling edit mode isn't complete and the tour proceeds because it sees
table T4 in the dom, when in fact the table we want to click should not be
`EditableTable` instead a `TableWidget`. This is random because the tour
may proceed as long at it sees the trigger element, even if the owl
rendering is not finished.
In this commit, we make sure that we click the correct element which is an
unselected table. So we check if table T4 is unselected before clicking
table T4 to open the product screen.
To reproduce, follow instructions here: https://gist.github.com/caburj/ef311076a24d898132ed9c6b99367581closesodoo/odoo#58151
X-original-commit: 238a65f59202d279d2c9327dd7937f125d80175b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
To transfer an order from one table to another, we first select the order,
then we click the 'transfer button', then we are shown the table selection.
The moment we click the 'transfer button', two simultaneous rpc's are made
for the same method (`create_from_ui`). This method deletes and recreates
the orderlines in database. The 2nd request fails because of the deletion.
But despite the failure, the server retries the rpc after a random amount
of time in sec: `wait_time = random.uniform(0.0, 2 ** tries)`.
If the user immediately (within the `wait_time`) clicks the new table where
the order is to be placed, the problem happens - the transfer of order to
the new table fails. This is because of the 3rd rpc whose result is used
for the actual order transfer. If the 3rd rpc happens before the retry of
the second, the transfer fails.
The randomness of `wait_time` (time-to-retry rpc) results to the random
runbot error. The solution is to prevent the 2nd (redundant) request
because it is not actually needed. This commit tries to accomplish that.
closesodoo/odoo#57370
X-original-commit: af7e7899124d2d8e3d4526d7de1c93158878f6e6
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
Initial rendering of order management screen shows the list of orders
based on the previous render. This is done so that during fetching of
new orders from the server, a list of orders are already shown.
This optimization causes a random runbot error when transferring an
order from one table to the other. The moment the order management
screen is open, it will render orders with the old table, but right
after fetching of orders, the listed orders are immediately updated.
To rectify the random error, we modify the test so that instead of
immediately clicking the transferred order, we wait for its new table
to show before selecting it.
closesodoo/odoo#57104
X-original-commit: 713dd3777ca0ce9d121d5162a3d63de3237509f4
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
It was only possible to print the tip receipts through an IoT Box.
If no IoT Box is configured, we now show the browser's dialog.
X-original-commit: 4b48109bb414b4768712d0e5d8706fd0088bef4b
Tours with `step_delay` potentially hide errors because of missing tour steps.
This is mainly caused by unfinished renders within the `step_delay` between
two steps. It is possible that the render after the 1st trigger is not yet
finished but the 2nd step trigger already existed in the screen. Because the
render result of 1st step is late and the 2nd step is already triggered, the
3rd step will fail. Note that the 3rd step will occassionally fail because
render of the 1st step is most of the time faster than step_delay but
there is no guarantee that the render is always faster because of occassional
cpu slow downs.
Runbot will eventually catch these tour errors which it did with the ticket
screen tour.
In this commit, we removed the `step_delay` in the pos tours. We also
supplemented the missing step in the ticket screen tour which was the cause
of random runbot error when there was `step_delay`.
We also figured that value property of input element is not observed by the
tour service's mutation observer, which result to an indeterministic error
in a step in tip screen. To fix this, we introduce an attribute to the input
element which is used in the step trigger.
closesodoo/odoo#56961
X-original-commit: 2ef73bb64cd0730d1e078a47f2ea9e1290b0df6c
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
HTTPS had been disabled on SaaS to allow the use of the IoT Box that
had no valid SSL certificate. As of V13.0, IoT Boxes connected to
Enterprise DBs have a valid certificate. POS can then use HTTPS.
Nginx is configured to redirect all requests to `/pos/web` to HTTP,
so we change the POS URL to `/pos/ui`, except when using a Six
payment terminal as it only works in HTTP.
closesodoo/odoo#56933
Taskid: 2191878
X-original-commit: 8aee4992778fee5e2f146c4cff8b35e83c7f56b3
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
As long as the payment is not validated, the cashier can add products
to the order, even if the payment has been completed. The amount
authorized can be adjusted if the payment interface implements the
canBeAdjusted method.
closesodoo/odoo#56656
Taskid: 2117032
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The amount is authorized when the customer scans its card, then the
customer writes the tip on the receipt and the total amount is captured
when the waiter manually inputs the tip, either right after or at the
end of the day.
closesodoo/odoo#56148
Taskid: 2321771
Related: odoo/upgrade#1661
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This commit fixes the tipping workflow. It includes the following changes:
1. Instead of directly setting tip when clicking a tip amount in tip screen,
we set the input amount to that selected tip. Then we introduce validate
validate button to confirm setting of tip.
2. The tip screen is only shown for non-cash payments. This behavior can be
overridden in extension module in cases where the showing of the tip screen
is only available for certain type of payments.
3. We introduce a way a settle tips for multiple orders in the ticket list.
When the user filters by 'Tipping' status, an editable tip-amount column
appears which can be editted for each order. When tip amounts are final,
settle button will set tip for each order in tipping status.
closesodoo/odoo#56198
Task-id: 2322683
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
In this commit, we make sure that the selectedTable doesn't change
even during the popup is shown to the user. During testing, there might
be rouge clicks that click the .floor-map element which deselects the
selected floor, making the value of this.selectedTable to be false,
causing runtime error.
If floor screen (iface_floorplan) is not active in the pos.config,
product screen should follow the tip screen and not an error.
closesodoo/odoo#55998
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
1. Introduce an option in restaurant config to allow setting tips after payment.
2. Tip form is shown in bills so the customers can choose/set their tips.
3. Validated orders are kept in TipScreen (access via TicketScreen) so that at the
end of the day, the user/cashier can set the tips for each validated order.
closesodoo/odoo#55488
Task-id: 2117029
Related: odoo/upgrade#1606
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The following changes are made in this task:
1. Remove order tabs and replace with ticket list.
2. Top bar color change.
3. Search bar in the product screen is moved in the top bar.
4. List of sub-categories are now in the same line as the category
breadcrumbs.
closesodoo/odoo#55100
Task-id: 2276678
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
We now allow invoicing of finalized orders in an open session in this first
iteration of order management in the pos frontend. Additionally, receipt
reprinting is also introduced. With this feature, we can now reprint the
receipt of old orders.
closesodoo/odoo#51141
Task-id: 1981354
Related: odoo/enterprise#11690
Related: odoo/upgrade#1472
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
1. Methods associated to touchmove and touchstart listeners should not
call preventDefault because they are passive by default. Calling preventDefault
will do nothing but in chrome browser, error message is issued.
2. We now allow resize based on touch events.
closesodoo/odoo#54612
X-original-commit: c6b7133d9c9dc52a8d283124b5a4497940e54682
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The layout of the split bill screen is broken after the responsive pos ui.
This fixes the split bill screen and make it also responsive.
New classes are introduced because reusing proved to be very difficult.
One benefit of declaring a new classes (then styling them) is that we can
target the particular elements that we wanted to change without the concerns
that another elements are changed.
closesodoo/odoo#54529
X-original-commit: 51f0c6a1be912192d910d47b79ac2cb3c5b42784
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
1. Idle timer is now reset also for touch events.
2. Using onWillUnmount and onMounted hooks to add event listener to
window for detecting activities is not possible in this situation
because setting the listener depends on a pos.config field
(iface_floorplan) which is only available after 'start' is finished.
(Remember that hooks are required to be set in the constructor.)
So instead of using those hooks, we replicate them by using a global
variable IDLE_TIMER_SETTER. This variable holds the bound method
_setIdleTimer and set it as callback to each event listener.
Then, before closing pos, we remove the listeners.
3. Close present temporary screen when going back to floor screen
after idle timer.
closesodoo/odoo#54498
X-original-commit: de1430d71890da24547fe24ba04dd28f59f77ee0
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
For most localizations, decreasing quantity of an orderline is
prohibited. This commit generalizes this behavior and is now available
in core point_of_sale.
A timeout is setup to go back to the floorplan after the user has been
idle for 1 minute to synchronize orders. We now only keep this
behaviour on the ProductScreen.
closesodoo/odoo#44062
X-original-commit: 7569b630ef174254e4443587c66b26a13e6a6e1e
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
Separate orders synchronization from set table to make the code clearer and
enable overriding.
X-original-commit: 5dd115b885193d1b301f4154d76f028194a7ae09
When there are no items in the cart, pressing the print bill button
may result in an error due to the translation (_t) module not being
imported
closesodoo/odoo#43937
X-original-commit: f4ef43e98613c2e916402eb35375a3d39481832f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Printed receipts are transformed into images by placing them into an
hidden `div`. When trying to print multiple orders, we did not wait
correctly between rendering the different receipts. Receipts were then
overriding one another while they were being rendered, resulting in
errors and missing receipts.
closesodoo/odoo#43907
X-original-commit: 00ba908d7b3d8b1145e4161ea8d9011ff6eea33d
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
This is a followup to the fix made in
99615ff6cc.
When calling JSON.stringify to undefined, it results to undefined, thus,
it is necessary to check if the value is undefined before JSON.parse'ing
it.
closesodoo/odoo#42812
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before this, when we printed a ticket for the kitchen, if we went back to the table management and go back to the order, we could re print the same product.
Now, we can only reprint the order if there is something different.
closesodoo/odoo#42208
Task-id: 2123029
X-original-commit: c8f604045eb0d476766641386c4e5e1605b915c3
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
* In a pos-session with table management create a new order with products
and go back to the floor-plan.
* The order is sinced to the back-end.
* Open the table again, remove all products but keep the order.
* Go back to floorplan to trigger syncing again.
* Open the table again.
behaviour before fix:
* The empty order is not loaded in the frontend anymore.
* To close the session the order has to be manually removed in the backend.
After fix:
* The order is still visible in the frontend and can be removed or finalysed as expected.
closesodoo/odoo#40165
X-original-commit: 3add8dd226f39d5166873a575b858694eeb2e6ee
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When a table is created, the new table appears to be selected but the
capability to resize and drag is not active. As a result, when this new
table is dragged, it is unselected instead. This is because of the call
of `save_changes`. The table widget is rendered but the event handlers
for resizing and dragging are not assigned. After this commit, the
created table can be resized and dragged immediately after creation.
closesodoo/odoo#38068
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Until now, the ticket printed from the web or to the printer were
different because one was using the OrderReceipt template and removed
some fields, and the other was using the BillReceipt.
We are now using only the bill receipt, to avoid to maintain multiple
template showing the same thing.
TASK-ID: 47990
Before this fix product lines did not merge on adding a same product
after transfering an order or re-opening an order that was synced.
To verefy if lines can be merged an unused field 'type' was compared.
Removing this field fixes the problem.
Before this fix, if an empty order gets transfered to another table, the
screen gets stuck on the floorplan until the window is refreshed.
With this fix the new table is opened.
WHen you are creating a draft order, the sequence is not saved on the
server, and when we load the orders from the server the session id is
not correct too.
This leads to having inconsistant sequence numbers in the POS, almost
when we are synchronizing orders through the pos restaurant.
We now show the orders sequence number prefixed by login number when the
order is synchronized and don't have the same login number as current.
TASK-ID: 2057436
closesodoo/odoo#36032
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When you are in a pos session, and have installed pos_restaurant, you
get the number of guest ('1') printed on the ticket even if you are not
in a session of type restaurant.
So we are now checking that you have a table (which mean you are in a
pos session of type restaurant) to show the guest number.
TASK-ID: 2057436
When we are running the tests on runbot, we get race condition when we
verify if the syncronisation is beeing sent, so we removed all of this
as it doesn't really verify if it synched or not, and we make a search
in python after tour execution.
closesodoo/odoo#36010
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When you are trying to resize and/or move a table in editing mode on the
floor plan, it doesn't work anymore, because the polling that will count
the orders by table will re-render the table after it has been selected
so the classes making it dragable are ot there anymore and you cannot
move or resize it.
Tu ix this behavior, we are not calling table order count when we are in
editing mode.
TASK-ID: 2057368
When you were trying to edit the table map of your pos, you were getting
a traceback because, it was getting information from a table that
is not in the list of table.
So we are now correctly set the table in the list when it is created and
duplicated.
TASK-ID: 2057368
Goffin Simon