Purpose:
- Move PoS settings in general settings to be consistent with the rest
of Odoo (PoS being the only app where settings are split in two locations)
- Clean settings by enabling obvious settings or dropping unnecessary ones.
closesodoo/odoo#84719
Task-id: 2753430
Related: odoo/upgrade#3260
Related: odoo/enterprise#24425
Signed-off-by: Masereel Pierre <pim@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>
*: extensions of `adyen_platforms`, namely:
- pos_adyen: remove related code, records, views, ...
- payment_odoo: remove the module
- sale_payment_odoo: remove the module
Modules related to Odoo Payments are already all merged since 14.0 and
14.4 (depending on the module). As the plan is to merge the final
version of Odoo Payments in 15.0 soon after the release, we want to
avoid all the complications that inevitably come with huge diffs, model
changes, XMLID collisions, etc. when merging in a stable version. Even
though it is possible to install these modules since 14.0, no
information could be lost during the upgrade since the entry point of
the application has never been activated.
task-2637770
closesodoo/odoo#75852
Related: odoo/upgrade#2804
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Antoine Vandevenne (anv)
- Dropped adyen.payout model
- Show pos.payment on adyen.transaction
TaskID: 2129218
Closesodoo/odoo#68952
Related: odoo/upgrade#2501
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The goal is to add a nice payment solution to our users.
- Why Adyen?
- Worldwide
- Manages local payment solutions
- Easy onboarding
- For both PoS and eCommerce
- Why Adyen for Platforms?
- The onboarding will be done directly from the customer's DB.
- It's quite complicated for SMEs to get a partnership with Adyen as
they have high requirements for transaction volume. By registering
Odoo as a Platform with Adyen Marketpay, we allow our users to
register as sub-merchants under a common account, removing this
constraint.
As all users are grouped under a common account, all requests need to
provide the same API key. As this key cannot be shared, all requests to
the Adyen API will need to be proxied. A new proxy will be created on
`paymentproxy.odoo.com`.
To initiate a payment, 3 values are required:
- `account_holder_code`: This code is provided by Adyen and is used to
identify the sub-merchant under the common account.
- `adyen_uuid`: This ID is used internally to identify the user.
- `proxy_token`: This token is generated by the proxy during the
account creation and is used to sign all requests.
The DB of the customer is the only host who has all the information
required to modify the sub-merchant info or initiate a payment. If
this information leak, the `proxy_token` can be reset on the proxy to
revoke all access to the API.
Before accessing the form to create an account, users will be
redirected to www.odoo.com where they will be asked to log in. This
ensures that we have contact information for this sub-merchant.
TaskID: 2129218
This allows Adyen's POS terminals to be used in the POS. The
architecture is as follows:
Odoo <--> Adyen server <--> Adyen payment terminal
It means we don't have to communicate directly with the
terminal. Instead we send HTTP requests to Adyen's API and they take
care of the rest. Therefore this integration doesn't require an
IOTBox.
Unfortunately this module is more complicated than it needed to be due
to Adyen's API not supporting CORS. Because of this we can't directly
call their API from JS. Instead we need to proxy requests through the
Odoo backend. This complicates things further because this means we
can't use their synchronous API. With this API an HTTP request remains
open for the entire duration of a transaction. We can't afford to
block an HTTP worker this long. So this implements their asynchronous
API which calls us back when a transaction completes.
In addition to the regular sale requests we also poll the status of
the terminal using DiagnosisRequests while transactions are in
progress. This is to handle cases where a payment terminal loses
connection after a payment transaction is initiated. It also handles
cases where a terminal was recently disconnected (<1 min). In this
last case Adyen will process the payment request as usual, without
notifying us the terminal is offline. It's important to notify the POS
user to check the terminal, otherwise he'll have no idea something is
wrong. We store the DiagnosisResponse's unique ID and every time the
POS requests a status update we launch a new DiagnosisRequest. When we
no longer receive DiagnosisResponse ID updates we can notify the user
of this in the POS.
To test this locally use something like ngrok so Adyen can call you
back.
API docs: https://docs.adyen.com/point-of-salehttps://www.odoo.com/web#id=1981799&model=project.task&view_type=form&menu_id=
Joseph Caburnay