This commit addresses an issue with barcode parsing where the parser
might fail when dealing with different types of barcodes, such as
an EAN-13 barcode being parsed with a GS1 barcode parser. To improve
the user experience and add flexibility, a fallback mechanism
has been implemented.
This commit allows users to set a fallback using a system parameter.
This can be accomplished by adding a system parameter with a key equal
to 'point_of_sale.fallback_nomenclature_id'. The value should be set
equal to the barcode nomenclature id.
This provides a robust solution to enhance the reliability of the
system in various scenarios where different types of barcodes are
in use.
opw-3382121
closesodoo/odoo#129891
X-original-commit: 57a2eab4e4b8e7aac6932213611dbd4148f58bd8
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Current behavior:
When using the QRCode on ticket to create an invoice, it was always
creating a new partner, even if a partner was already set on the order.
Steps to reproduce:
- Activate the QRCode on receipt feature
- Create a PoS order and create a new customer for it
- Pay the order and print the receipt
- Scan the QRCode on the receipt to create an invoice
- On the new window enter the customer informations and see the invoice
- Now go check the customers list in the backend, you will see 2
customers have been created.
opw-3275938
closesodoo/odoo#126303
X-original-commit: 0a867a4e53d97da707b14062e0abafc18a1c827c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
when the user allows multi employee per session and the portal user tries to
access the pos with the URL /pos/ui?config_id=1 then the error will be generated.
steps to reproduce:
- Installed point_of_sale module.
- In Configuration > Point of Sale > activate Multi Employees per Session option
and save it.
- In another window, do log in as a demo user and start the pos session.
- From the Admin user, make Marc Demo as a portal user.
- Then refresh the demo user session.
- Traceback will be generated
Applying these changes will resolve this issue.
sentry - 3958755602
closesodoo/odoo#124662
X-original-commit: 49447781b95f18a87491e47c19e4e8a6167ccf1d
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
If applied, this commit will solve the issue of the archived pos config issue
while session accessed from another tab, another device, or another user.
Steps to produce:
- Open the pos session.
- From another device or another tab archive the pos.config record.
- Refresh the opened session.
sentry - 4057306284
see - https://tinyurl.com/2opdugz4closesodoo/odoo#117707
X-original-commit: 75c0f1ca2767837f3e75698ceadeedf362110bd8
Signed-off-by: Achraf <abz@odoo.com>
**Notable feature changes**
- PoS app continues to load even if no nomenclature_id is configured.
- When scanning, an error popup is shown to the user mentioning about
the misconfiguration.
- We introduce a default error handler that shows the ErrorBarcodePopup
when there are no registered barcode handlers via the
`useBarcodeReader` hook.
closesodoo/odoo#115906
Related: odoo/enterprise#38444
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Currently, it is possible to add a QR to generate an invoice for a pos
order at a later time (see
https://github.com/odoo/odoo/commit/14183883432e9d35c6240e1d7dc8c51d04cb93db).
When scanning the QR, the customer can fill various fields (including
potential l10n_* specific fields) and then generate an invoice.
This commit makes it possible to add a 5-digits code on the ticket. A
customer can go to `pos/ticket` and fills this code, the date and the
order reference written on the ticket. He will then be redirected to the
same flow as when scanning the QR code.
task-3178954
closesodoo/odoo#112285
Related: odoo/enterprise#36859
Signed-off-by: Laurent Smet <las@odoo.com>
Some countries, such as mexico, require a seller to be able to
generate an invoices from a ticket from a sale done in a shop,
even after a few days.
This change aims to allow this, by allowing to create an invoice at
a later date after the POS has been closed.
This is done by partially reversing the POS closing entry, and then
generating an invoice the same way it would be done at the POS closing.
The customer can scan a QR code if enabled in order to request the
invoice by himself, requiring him to fill a for to give the customer
information required for the invoicing.
Allows to fill additional fields dependent on the localization that are
required to be set on the partner or the invoice.
Task id #2946604closesodoo/odoo#97675
Related: odoo/enterprise#30599
Signed-off-by: Laurent Smet <las@odoo.com>
Small visual changes that should improve the user experience.
The loading demo data popup has been moved to the backend.
Created an Alert Popup that is less aggressive than an Error Popup
closesodoo/odoo#83780
Task-id: 2485062
Related: odoo/enterprise#26104
Signed-off-by: Masereel Pierre <pim@odoo.com>
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit accomplishes multiple objectives:
1. Loading of model data for the POS UI is now done in single
request (with some exemptions).
2. Backbone.js is removed and is replaced by reactivity.js
authored by the js framework team.
3. Better organization of assets in the `__manifest__.py`
Data Loading
------------
One request per model -- that's always been how the data is loaded
in POS UI. Now, we move the aggregation of data to the backend which
simplified the data loading. In the frontend, data loading is
initiated in `load_server_data` which makes the single rpc call
to the `load_pos_data` defined in `pos.session` model.
There remains some rpc calls during loading but the number is
greatly reduced.
This change result to faster loading of the POS UI. However,
there is no more progress bar during the loading.
Notable entry points:
- .js: `PosGlobalState.load_server_data`
- .py: `pos.session.load_pos_data`
It is possible to make customizations in the loading, but is done in
several steps:
1. Override `_pos_ui_models_to_load` to include the new model to load.
2. Define `_loader_params_<model_name>` to define the `search_params` and
optional `context`.
3. Define `_get_pos_ui_<model_name>` to return the data that will be
included in the full `loaded_data`. Perform the organization in this method
whenever necessary.
4. Override `_pos_data_process` for further post processing. The final
form of `loaded_data` in this method will be sent to the frontend.
Removal of Backbone.js
----------------------
POS is no longer dependent from `Backbone.js`, but it's replaced by a
new dependency -- `reactivity.js`. It's invented by the js framework
team which will be available in owl v2.
The consequences of this change are the following:
1. The old `PosModel` is renamed to `PosGlobalState`.
2. The name of the other models are kept (except Paymentline which
is renamed to Payment).
3. The name `PosModel` is now used as the base model of the data models.
This is symmetric to our use of `PosComponent`.
4. The instance of `PosGlobalState` is made reactive in `Chrome` (the
root component). As a result, whatever mutation made in that instance,
`Chrome` will rerender. But rendering is batched so multiple mutations
in a single sychronous function call will only result to a single
render call.
5. `PosModel`s can be extended in the `Registries` the same way as we
extend the `PosComponent`s.
```js
// E.g.
Registries.Component.extend(Chrome, PosResChrome);
Registries.Model.extend(Order, PosResOrder);
```
Reorganization of assets declaration
------------------------------------
This is a simple change that replaced the explicit enumeration
of loaded .js and .xml files. Also, we now have regions in the
manifest separating:
1. Augmentations of dependencies
2. Assets for `point_of_sale.index`
3. Assets for the qunit test (soon will be improved)
Other notable changes
---------------------
- Automatic call to `Order.save_to_db` is batched.
- Instances of `devices.DeviceProxy` (`proxy`), `devices.JobQueue`
(`proxy_queue`) and `BarcodeReader` (`barcode_reader`) are moved
to `point_of_sale.env`. Together with `posbus` and `posMutex`
(previously `flush_mutex`).
- `ActivePrograms` is now passed a props.
- `cashier` is no longer saved to `localStorage`.
- `pos_cache` is overhauled.
- `cache` is taken out from `PosDB` to prevent infinite rendering
loop whenever `cache` is mutated. It's now called `CACHE` in
the `db.js` file.
- reactive version of `posmodel` is exposed globally when in debug mode.
This means that calling when calling a mutator, the UI will react.
- Added control buttons in the `ProductScreen` is sorted during `Chrome`
setup. As a result, we don't need to worry on the loading order of the
control buttons components.
- Model can be simply instantiated using `BaseModel.create(obj)`. This
takes into account the extensions.
- `pos_coupon`: rewards are now updated whenever set_order is called.
- Component unit tests were removed. It wasn't useful and it just blocks
the development. We'll be introducing better unit testing later.
closesodoo/odoo#82461
Related: odoo/enterprise#23344
Signed-off-by: Masereel Pierre <pim@odoo.com>
Co-authored-by: Jacky (trj) <trj@odoo.com>
- Activate multicompany
- In the company switcher select all company
- Launch a pos session
--> Issue all rpc request are make in all companies (len(self.env.companies) != 1). It create some error with taxes, fiscale position, ...
closesodoo/odoo#76522
X-original-commit: a553f86afc5e9ff3ddd58eb6b68ba7ff9cf936a5
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This branch adds request.redirect on all requests.
In case of a front end request, we do an url_for to the location.
We removed redirect_with_hash that was only for retro compatibility
local_redirect has been renamed to redirect_query, and param keep_hash has been
removed and moved.
Default code for redirect is 303 now instead of 302.
Now redirect and redirect_query make local redirect by default, you need to
pass local=False to make external redirect.
All werkeug.utils.redirect has been replaced by request.redirect.
Http.redirect now use an http.Response type, and it become easy to add an
override like 'set_cookies' e.g.
Dispatch of a website.page return an http.response too, so we first need to
check if it is a cached version before to check if it is an Odoo Response.
Migrate your code:
http.redirect -> request.redirect(location, code, local)
http.local_redirect -> request.redirect_query(location, query, code, local)
http.redirect_with_hash -> request.redirect
Courtesy of odony for help and review ;)
closesodoo/odoo#72599
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When you are opening a POS session, a number corresponding to count of
connection to this session is incremented, to be sure to have a unique
identifier on receipts.
In recent browsers, when you are reopening a recent tab (Ctrl+Shift+t)
the browser will load the response of last request and won't perform the
request. So the count of login won't be incremented, and this will
result of duplication of receipt number.
To avoid this behavior, we are explicitly say to the browser (through
the response header) that we don't want to cache the request result.
closesodoo/odoo#71770
X-original-commit: 21c92bf4d1a469f5ec1d0edcf2b2e08102df5b20
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.
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.
Pedram (PEBR)