*: l10n_co_pos, l10n_fr_pos_cert, l10n_gcc_pos, l10n_in_pos,
l10n_sa_pos, pos_adyen, pos_discount, pos_epson_printer,
pos_epson_printer_restaurant, pos_hr, pos_loyalty, pos_mercury,
pos_restaurant, pos_restaurant_adyen, pos_restaurant_stripe, pos_sale,
pos_sale_product_configurator, pos_six, pos_stripe
We are about to refactor most of the Javasript code base of the point of
sale and related modules. In doing so, we will move a lot of files and
modernize the entire code-base. In order to avoid diffcult rebases,
their conversion to odoo-modules is done as a first step to avoid
getting lots of conflicts on files that were unindented, which marks the
entire file as being in conflict. Conflicts will occur during forward
ports but they will be easier to manage as the changes will be much
smaller in scope, and the author will have the context of the change
that causes the conflict in mind when dealing with it.
closesodoo/odoo#107621
Related: odoo/enterprise#34910
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit:
If we remove a payment line using an Adyen payment method,
`pending_adyen_line()` return `undefined`.
With the `_poll_for_response` still being executed,
it will pop some JS traceback each call with:
```js
TypeError: Cannot read properties of undefined (reading 'terminalServiceId')
```
After this commit:
No JS traceback loop
OPW-3032391
closesodoo/odoo#106470
X-original-commit: 52a517ca74e563a0ad5538e8a7fc1fe19528856c
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
If the credential of Adyen are not correct and refresh POS after a payment
The cashier are unable to cancel or remove the payment line
Because the longpollong continue to reach Adyen to try to get a response.
This issue come from the last on POS_adyen commit:
262e50e2b2fb70d882fef536deb8ba253833639b
With this commit we stop the polling if we can't reach Adyen server
So the correct status is setted at the payment line and the cashier
can delete it.
closesodoo/odoo#103582
X-original-commit: 3a649dddb6d13bc96d281becc6387953c053223a
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
Currently the "abort" function in the pos_adyen module did not include
all the information necessary to cancel the current payment.
With this commit this information is added and the status is correctly
returned to the JS in order to have the correct status on the payline
https://docs.adyen.com/point-of-sale/cancel-a-transaction#cancel-from-registerclosesodoo/odoo#102747
X-original-commit: 897e9ed1ae5b828017b0cff02281685e757d5e14
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
With this change, we are now assuming each field that starts with
'pos_' to be a 'pos.config' field that has value that will be saved
to the 'pos_config_id' record. We made that modification because by keeping
some related fields not written at the same time can trigger contraints at the
wrong moments that would lead to validation errors when not supposed to be.
Part-of: odoo/odoo#97032
Actually we send request to check if the terminal is available when we poll
the status of a payment.
We remove it and need check the availablity before we start the session
closesodoo/odoo#95102
X-original-commit: 215c8fc7cebdb566a008bf2badb6a934af84150a
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
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>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit: whenever we left the PaymentScreen when we were paying (either by reloading the page or by backing to the ProductScreen), the real payment status was not properly saved even tho the payment has been paid or cancelled.
With this commit: whenever we go to the PaymentScreen with a pending payment line with Adyen, we fetch the latest status from the back end. This way, the front end will always have the latest status of the payment.
opw-2802676
closesodoo/odoo#90083
X-original-commit: 07b30c519b101a2998f5320dde5203bfc964b7e9
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Trinh Jacky (trj) <trj@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>
Actually the last status is deleted by the fist request who can reach it
So if a request is lost the answer too
With this fix we delete the last response only when we start a new one
closesodoo/odoo#79706
X-original-commit: 63abab836d95df9a45f6f7d038bb18df88f864b4
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
When making a payment intent from Adyen terminal with the POS, the payment intent was validated by Adyen
but Odoo stopped polling because a connection failure happened.
With this fix we use the remaining_polls already implemented to get the adyen status with a interval of 3 secondes.
If after 3 tries of 3 seconds each it still fails we can retry manually.
Related to dcb1e2b4823c917f4c547d2cad604187f893948d and f83d1b13a96f8df559918b5905b949009d2ece88
opw:2587625
closesodoo/odoo#76768
X-original-commit: 325b7dde0da6cca27f0d468d1358702d52b8cbaa
Signed-off-by: Quentin Lejeune (qle) <qle@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)
When there is a connection failure (eg. server restart) while we are
polling adyen for payment status during the payment process, we would
show a connection error and when clicking on retry, we would do a new
payment even if the first one was successful causing a double payment.
After dcb1e2b48, the retry after failure should just continue the
polling as if there was no connection failure, so for example:
- order 1: pay with adyen => connection failure during payment
- order 1: retry => payment successful
But in this particular case:
- order 1: pay with adyen => connection failure during payment
- order 1: close adyen payment line and pay with another payment method
- order 2: pay with adyen => we will receive the response from order 1
With this changeset, we only continue the polling for adyen status if we
are retrying to pay the same order.
opw-2587625
closesodoo/odoo#75640
X-original-commit: f83d1b13a96f8df559918b5905b949009d2ece88
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Steps to reproduce the bug:
When making a payment intent from Adyen terminal with the POS, the payment intent was validated by Adyen
but Odoo stopped polling because a connection failure happened and then on retry it made second payment
even if the first one was successful.
Fix:
Now after a failure, it will try to poll again the last transaction (with get_latest_adyen_status)
and set the payment as successful or cancelled based on the last response.
opw:2587625
closesodoo/odoo#75053
X-original-commit: dcb1e2b4823c917f4c547d2cad604187f893948d
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Co-authored-by: nle-odoo <nle@odoo.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
- 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>
- Improved onboarding / KYC flow
- Display KYC stage for each "document" (identity, bank account,
shareholder, etc.)
- Only update to the API what's been updated by the user to prevent
undergoing another full round of data verification
- Show new pricing
- Support refund of adyen.transaction
- Simplify payouts (let Adyen automatically handle them)
- They are now automatically handled by Adyen and not manually
triggered by a cron
- "Balance" dashboard
- Show the balance per currency
- List of payouts and their status
- Handle account/transaction notifications
- Show split of fees
- Details on payment method (card country, card type, etc.) used
- Display details from the linked payment.transaction
- Verify proxy signature for notifications
- Notifications are now signed and authenticity verified
TaskID: 2129218
Closesodoo/odoo#68952
Co-authored-by: Antoine Prieels <anp@odoo.com>
`_(xyz)` will wrap them in an underscore.js object, which when used in
a string context will just return the string. So it's basically a
no-op, but it certainly doesn't translate the terms.
closesodoo/odoo#70476
X-original-commit: 92352ed2b5524c97b0aeeba3193c6a8d93ed82a1
Related: odoo/enterprise#18172
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
Show a nice error message when starting negative transactions on Adyen
terminals.
opw-2368978
closesodoo/odoo#60985
X-original-commit: 4dc790629e49c6e78a009fde3a22915944bb5583
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
- The Adyen sync cron didn't call the function to sync terminals
- Do not specify the merchantAccount when creating a store, the proxy
will add it itself.
closesodoo/odoo#59868
X-original-commit: d5b456a1f75320c8fdf1e989afad91fc74ec9ef3
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@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
Revert commit e6372c3, the concurrent updates were solved by the change
in the order of the lines, not by the fact that functions were defined
as api.model
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>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Samuel Degueldre