Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
After a customer has paid via an Adyen terminal, the Adyen server sends
a request containing the payment confirmation to the webhook on the odoo
server.
At the moment, the pos frontend continuously polls the backend in order
to find out whether or not the confirmation from Adyen arrived.
This pattern is wasteful and over complicated.
In this PR I replace the polling logic with websockets communication.
closesodoo/odoo#125593
Task: 3342693
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit: it was possible to create two PoS terminals in two
companies with the same `adyen_terminal_identifier`. So it's possible,
after each payment, it would add the response to the wrong payment
method's `adyen_latest_response`.
The solution is to bypass multi-company record rule in
`_check_adyen_terminal_identifier`.
opw-3131814
closesodoo/odoo#112080
X-original-commit: 8a9d7ddf0739b3f7c3224f53f7593be40be0b15a
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@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>
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>
*: 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>
- 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>
- 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>
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.
Disqualify the constraint in the adyen identifier if it is empty because
it is not needed in other payment methods that are configured with other
payment terminal.
closesodoo/odoo#36702
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
For now when you are using payment terminals in the point of sale, you
have different way to configure payment temrminals, for the IOT, you
have to select the payment terminal in the pos config, and for adyen and
ventiv you have to configure them in the payment method.
So we've modified it to always configure payment terminal on payment
mehthod, and not on the pos config anymore, with iot you'll be able to
select the specific device you want to use, even if it is not on the iot
box set on the pos config.
closesodoo/odoo#35665
Task-id: 2042382
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Every time we check the status of a request (every 3 seconds) we also
launch another request to check the status of the terminal. This way
we can notify the user if the terminal is no longer reachable.
Even though we call Adyen's async endpoint for this it can still take
a while to complete (>2 seconds). Before this change the
pos_payment_table would be locked for this entire duration. This means
it's now likely that during this time Adyen calls us back to say the
transaction is finished. It needs to write on the payment method which
causes the concurrent update error.
Odoo's automatic retry mechanism would usually handle this fine but
it's not pretty solution.
Instead let's convert the methods that do the async call to @api.model
functions and pass in all the data they need. This solves the problem
because now we won't need to lock pos_payment_method for the duration
of the request.
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=
Xavier Morel