| Age | Commit message (Collapse) | Author |
|---|
|
Before this commit, "document.execCommand" was first
method used when attempting to print, due to a bug
in Safari for Windows (ndr. which is deprecated as
the last version of Safari for Windows is 5.1.7
from may 2012).
On the mobile App, the "document.execCommand('print')"
call returns "true" even if nothing has actually been
done, which therefore prevents from executing "window.print()".
After this commit, we execute directly "window.print()"
as it's supported by all modern browsers (except Firefox Android,
which doesn't support printing at all).
Notes:
* "document.execCommand" is deprecated and the "print" command isn't even documented
* Safari 5.1.7 doesn't support Promise/Async/Await, and therefore not Odoo 13+.
References:
* https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand
* https://developer.mozilla.org/en-US/docs/Web/API/Window/print
* https://caniuse.com/?search=await
* https://caniuse.com/?search=promise
* https://apple.stackexchange.com/questions/68836/where-can-i-download-safari-for-windows
opw-2486818
closes odoo/odoo#70155
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
|
|
|
|
|
|
These changes have been made to be able to add some behaviors in some specific points of the flow when overridden.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The terms in the search bar of the ticket screen are not translated.
This commit fixes this issue by passing the translated form of the
terms to the search bar component.
closes odoo/odoo#65038
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
closes odoo/odoo#62742
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
|
|
Courtesy of Transifex's translators for reporting bad/unclear sentences.
closes odoo/odoo#62539
Related: odoo/enterprise#15032
Signed-off-by: Martin Trigaux (mat) <mat@odoo.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.
closes odoo/odoo#62403
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
|
|
|
|
|
|
|
|
- Go to Point of Sale > Configuration > Attributes and create an Attribute:
* Attribute Name: Attribute X
* Variants Creation Mode: Never
* Attribute Values: Value Y, Value Z
- Create a Product (i.e. Product X) available in POS with the created Attribute and Values
- Configure a POS and enable the following options:
* Is a Bar/Restaurant
* Product Configurator
- Open POS Session and select a table (i.e. Table 1)
- Select Product X and a value for Attribute X
- In the order summary, the value of the attribute appears after product name
- Go to Floor plan
- Go back to Table 1
The values of all attributes don't appear anymore in order summary
In POS front-end, when adding a product, the name of all chosen attributes values
are registered in a variable named "description".
The full product name displayed in the order summary is generated from display_name
of the product and this "description" variable.
When moving to floor plan, ongoing orders are saved in DB and reloaded when moving
back to a table.
As "description" is not saved, regenerating full product name from display_name of
product and "description" is not possible.
However the generated full product name is saved in DB and can be retrieved.
opw-2371965
closes odoo/odoo#61220
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
|
|
Except Spanish, waiting for cleanup
closes odoo/odoo#60848
Related: odoo/enterprise#14421
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
The alignment of quantity and product name was off when the product
name was split into multiple lines.
opw-2360424
closes odoo/odoo#60545
X-original-commit: 58404f299f7fa9128758b4b7830a6393c64ad085
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
|
|
There was a problem in the Transifex translations for Spanish and all
translations were overwritten by mistake with english defaults.
This commit reverts all modified es.po files to their previous version
while we work to restore the translations on Transifex.
|
|
|
|
|
|
|
|
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
closes odoo/odoo#59461
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.
closes odoo/odoo#59168
X-original-commit: 8e65a220cadefe41df9fcc2172d60ff90ea5b584
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
|
|
Including demo data this time
closes odoo/odoo#58821
Related: odoo/enterprise#13682
Signed-off-by: Martin Trigaux (mat) <mat@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/ef311076a24d898132ed9c6b99367581
closes odoo/odoo#58146
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.
closes odoo/odoo#57365
X-original-commit: af7e7899124d2d8e3d4526d7de1c93158878f6e6
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
|
|
Currently on branch saas-13.5
Without demo data
closes odoo/odoo#57148
Related: odoo/enterprise#12985
Signed-off-by: Martin Trigaux (mat) <mat@odoo.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.
closes odoo/odoo#57095
Signed-off-by: pimodoo <pimodoo@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.
|
|
After clicking a table, ProductScreen should show, not FloorScreen.
closes odoo/odoo#57009
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
|
|
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.
closes odoo/odoo#56949
Signed-off-by: pimodoo <pimodoo@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.
closes odoo/odoo#51625
Taskid: 2191878
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
|
