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>
This commit switch the cash control opening mangement from the backend to the front end of the point of sale.
task_id: 2258817
closesodoo/odoo#55741
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Create a new POS session with User A
- Make an order
- Logout and connect as User B
- Resume the session
The session cannot be resumed and the user is redirected to the POS
Dashboard.
When searching for a session to resume, the search restricts the user to
the current user. Therefore, no session is found.
If no session is found, we search on sessions corresponding to the given
configuration. The configuration is mandatory to avoid being redirected
to a random session.
opw-2274973
X-original-commit: 2deb94aa9da821455374df5602e2d30c5befcdec
If no product is loaded when opening the PoS, show a popup asking if
the user wants to load demo data.
closesodoo/odoo#52919
Taskid: 2276054
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
Otherwise, if two POS stations are using the same user with the same pos.config,
i.e. create two session AND if you have bad luck, then those sessions will get
same login_number, which leads to losing half of orders, because POS stations
will generate same pos_reference and only first order from the POSes is saved,
while another order is lost without let know to cashier.
closesodoo/odoo#24486
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When you are login to a session, the domain that was looking for the
session was wrong, so you could log into a session and connect to
another one.
TASK-ID: 2057436
PURPOSE
=========
When working in restaurants, there are often more than one waiter working on the same floor.
But Odoo doesn't support that.
There can only be one person working on one session for the same tables.
The purpose of this task to allow several people to work on the same session (while synchronizing sessions).
SPECIFICATIONS
===============
- MultiUser is active by default.
- Allow multiple waiters to login on one PoS Config.
- All waiters login to the same session, the waiter that does the paiment is the responsible for the order (same as now).
- Synchonize the information across the multiple instances running on same floors.
Syncronisation will take place at switch of table.
(close tables automaticly if no activity, to force sync)
- Syncro cannot be done if no internet : how do we manage it ? We should inform the user the internet connection has been lost and that synchro cannot be done. What impacts? To check
Useful links
https://github.com/it-projects-llc/pos-addonshttps://apps.odoo.com/apps/modules/11.0/pos_bus_restaurant/
Related PR:
odoo#32789
TASK-ID: 1891130
closesodoo/odoo#33973
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When you are lanching a POS session in multi-company, the allowed
companies in the user context when you open the route '/pos/web' are the
ones taken from your cookies which are the last thicked in any of your
tab.
So if you have a tab in company one, then open a new one and thick
company 2, the values in your cookies will be company 2. The you go back
in tab 1 and open a POS, when you'll arrive in the main controller,
you'll have a company 2 in allowed companies even if you are opening a
session which is in company 1.
So we are searching in the session with a sudo, as there is only one
session/user, and then we pass the company of the session into the
allowed_companies in session user_context for the frontend.
closesodoo/odoo#35487
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This commit goal is to encapsulate every tour-test into a separate assets
bundle that would be called only during tests (command line) or by URL
(debug=tests). That way, a lot of .js files would not be loaded anymore
uselessly outside test mode and will speed up the page loads (especially in the
frontend as the backend do not reload the page anyway).
In order to do that, we needed to propagate the `debug` state from page to
page.
Otherwise, every page change during a test would simply lose the debug mode and
the test would stop as the test assets would not be loaded.
As we could not add the `&debug=tests` on every link (either hardcoded or
preprocess during the rendering), it has been decided to store it in session.
Technical summary:
1. `debug` state (currently only stored in URL) will be stored in session.
Either when adding the `debug` param in URL (handled with _dispatch) or by
starting Odoo with `test-enable` or `test-file` (handled by session init).
2. Once activated (and so set in session), debug mode will remain activated
even if not visible in URL (after a page navigation eg).
To deactivate it, set its value to nothing, `debug=`. That will exit debug mode
(whatever mode it is: debug, assets, tests).
3. As tour-test files are now in a separate bundle, every layout (when needed)
should `t-call="web.conditional_assets_tests"`.
As it would be redundant and verbose, no `t-if` is needed on the t-call to
load it only in test debug mode. That will be handled by
`compiled_assets_tests` that will actually do the conditionnal t-call-assets
to web.assets_tests, if tests debug mode is activated.
4. In addition to separating the tour-tests files in a separate bundle, we also
moved those files to a specific folder under /static/tests/tours next to
QUnit tests.
5. Also, tour files will be moved in a specific folder /static/src/js/tours for
cleanness purpose (those files will still be kept in their 'normal' assets
as needed outside test mode since it is tours).
This will be done in the next commit.
6. It is possible to enable multiple debug mode, such as 'tests' and 'assets'
together. Simply separate debug modes with a comma, eg '?debug=assets,tests'
task-1934445
Comes with https://github.com/odoo/enterprise/pull/4281Closes#33213
* add a json_scriptsafe module, which re-exports the stdlib's json but
provides a script-safe `dumps` function, because of the way it works
the script-safe version is fine / safe to use outside script
contexts, so there's no need to provide different functions to qweb
contexts
* make the json.dumps in qweb contexts <script>-safe (should be
rendered using t-raw)
* update callsites to properly dump json:
- dump in template, not in the python code
- dump the entire structure at once, not bits and bobs inside a JSON
literal
Task 1999158
closesodoo/odoo#33682
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* Creating a new structure by transforming all the plugins in the
library using the odoo inheritance system. Plugins are easier to
implement with the AbstractPlugin to add Odoo behaviors.
* From now on, the methods of the library (in this case Summernote) can
no longer be called by other modules or files. Only the wysiwyg
widgets can access it, to simplify the updating process. The wysiwyg
object serves as an interface.
* Depending on the options the snippets will be loaded or not, the
editor will be in an iframe or not... all of this is transparent from
the outside.
* Regarding iframes, all controllers related to editing have been
removed: the new API no longer needs them. This speeds up loading,
eases testing and removes complexity for the same
features.
PUBLIC FEATURES
There are several public methods on the Wysiwyg class:
* Wysiwyg.prepare (WidgetParent): returns a deferred resolved when the
library (xml, lazy, assets...) is loaded.
* Wysiwyg.getRange (DOM): returns the range (selection in the dom)
* Wysiwyg.setRange (startNode, startOffset, endNode, endOffset): creates
a range (selection in the dom)
* Wysiwyg.setRangeFromNode (DOM, options) that creates a range from an
element (option available to select all, start or end)
A jQuery selector was added: :o_editable, which indicates whether the
current element is editable. That is, if it is contained in a tag with
the attribute 'contentEditable = "true"' or in a tag with the class
o_editable.
Several methods are also present:
* focusIn: makes a focus and places the cursor at the beginning of the
element
* focusInEnd: makes a focus and places the cursor at the end of the
element
* selectContent: makes a focus and selects the content
HTML FIELD
The HTML field can receive different options:
* style-inline: {boolean} transforms a class into an inline style when
saving and vice versa when reading.
* no-attachment: {boolean} prevents the use of attachments (in media
dialog)
* cssEdit: {xml_id} to use a template containing the css to loaded in
an iframe when editing
* cssReadonly: {xml_id} to use a template containing the css to load
into an iframe when viewing in readonly
* snippets: {xml_id} snippets template (can be used with or without
cssEdit)
* wrapper: {template} qweb static template (containing a tag:
id = "wrapper") that will include the content during editing (removed
on save)
MASS MAILING
A widget was created for mass mailing. There are now two fields:
body_html and body_arch.
body_arch contains the code with the class without conversion into
inline style, useful when editing and one with the inline style that is
visible in readonly mode and sent by email.
Advantage: no spreading errors, able to update css/theme, able to do
more changes when converting to inline style so that a maximum of mail
clients have an impeccable rendering.
Co-authored-by: Antoine Guenet <age@odoo.com>
Fixes#15101 (cf comment 273208287 for details)
Closes#15862
Restore the rescue mechanism from v9, without the field it will be based on
the session name containing '(RESCUE FOR'
Add tests
A customer facing display is any monitor that can be connected through
HDMI on the POSBox. When enabling the customer facing display option the
customer will get a realtime overview of their current order, what they
have to pay and the change they should receive.
What is displayed on the customer facing display is fully customizeable
through web_editor, two snippets are provided that will be dynamically
updated (Order Block, Payment Info Block) as the order changes in the
POS.
The POSBox handles the live updates through hw_screen.
The HTML that eventually gets sent to hw_screen contains references to
remote resources. All of these remote resources are available on the
Odoo server, no other external connections have to be made. Resources
that are unavailable for the POSBox (like product images) are base64
encoded and included in the HTML. This is accomplished by using the BASE
HTML tag. This does mean that the customer facing display will *not*
work with a POS client opened through localhost or 127.0.0.1. The POS
has to be opened through an IP address (or URL) the POSBox can reach.
Courtesy of JOV, LPE, GED and MAT
The sale of the day report was removed during new api migration as it was
thought, it could be replaced by pivot view.
Due to the lack of some options and the problems to be printed, create similar
report.
This commit adds a report in the PoS interface to be printed on ESC/POS printers
and add a JS wizard to restore it in the backend with date selection.
The wizard is made in a new web widget because adding a wizard requires changes
not compatible with stable version.
Creating a proper wizard should be done in v10
opw-681833
This commit introduces a mechanism to add information into the session
from a different module, without having to fetch it manually with a rpc.
This is intended to be used with small pieces of info required at the
start of the web client, such as currency informations.
To add information to the session, one can simply inherit from ir.http
and modify the session_info method.
When you go to /pos/web and there is no open session that belongs to the
current user the controller redirected to an old action called
action_pos_session_opening that was removed in
48ab50ed0d. This replaces that action
with action_client_pos_menu which just redirects to the POS dashboard.
the pos session now keeps track of the session logins, and that number is
included in in the order reference. This prevents orders generated in parallely
created sessions from having the same reference, and also helps reduce fraud.
[REM] dead code: pos_box_entries.py/xml, pos_box_out.py/xml, pos_return_view.py/xml
[ADD] lines, invoice, cashbox of the day, payment, receipt, users product reports converted to QWeb. Added YML tests for the bank statement reports.
[FIX] closed cashbox of the day sql using old fields in its queries, yml test not correctly generating an invoice from a pos order
bzr revid: sle@openerp.com-20140414104954-xj10wi640tyr3ufe
Antoine Prieels