Problem:
When point_of_sale and pos_mercury are both installed,
_gc_old_tokens will get called by the scheduled action "Base: Auto vacuum internal data"
and it will try to remove the Vantiv tokens from POS orders that are 6+ months old.
However, there are fields named ref_no and record_no that exists for pos.order;
so the AttributeError will get thrown.
Solution:
It is safe to remove the entire method since the Mercury API documentation
does not explicitly mandate the tokens be removed from old POS orders.
It was recommended by JOV to not modify the method to prevent the modification of
potentially 8 years old POS orders from client's databases.
Since the method is removed, the error will not be thrown when auto vacuum is called,
pos_mercury is installed, and POS orders are 6+ months older.
opw-3082616
closesodoo/odoo#115466
X-original-commit: 41a82c3326150fba6948667c9e455ae82088bb6d
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
in v14 `_render()` on `ir.ui.view` returned `str`. In v15 it returns
`Markup` instead. This inadvertently changed the behavior of
`_do_request()`. The rendered view stored in `xml_transaction` is
added to the request as the SOAP body and is supposed to be
escaped. This is done by `html_escape(xml_transaction)` but since
`xml_transaction` is already `Markup` it won't escape. On top of that
concatenating the `soap_header` and `soap_footer` `str`s causes them
to be escaped when they shouldn't be.
This commit changes `xml_transaction` to be a single `Markup()` that
inserts the escaped view and password inside of
`<mer:CreditTransaction>`. This has the added benefit of solving an
issue when the password includes a character with a special meaning,
although I'm not aware of a real case where this happened.
opw-2919085
closesodoo/odoo#98759
X-original-commit: 8e51b1df76f35a7c01e5f86920c84b2c1c976d9b
Signed-off-by: Xavier Morel (xmo) <xmo@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>
As werkzeug.utils.unescape is deprecated in werkzeug 2.0 and the
markupsafe version of unescape just uses the built-in html.unescape [0],
we can use directly the same built-in method.
[0] pallets/markupsafe@c35603a903
Part-of: odoo/odoo#91927
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
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>
In order to limit encoding decoding, the _render method returns a
unicode string in the markup safe object instead of a MarkupSafeBytes
closesodoo/odoo#68299
Related: odoo/upgrade#2454
Related: odoo/enterprise#17270
Signed-off-by: Antony Lesuisse (al) <al@openerp.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.
The ir.autovacuum model purpose is to run several garbage collecting
operations like removing files from the filestore when no attachment
references them anymore.
The precedent strategy to register new garbage collection tasks was to
override the `power_on` method and to imperatively execute a vacuum
cleaning method on a given model. All calls were executed in a single
SQL transaction without any error handling, meaning a single fail during
any call resulted in a complete failure of the entire vacuum cleaning
chain.
We introduce a new `@autovacuum` api decorator, its purpose it to
register garbage collecting methods that will be safely executed in
their own transaction by the vacuum cleaner. In order to ensure this
new strategy is used, we deprecate `power_on` extensions.
By the way, garbage-collecting methods can be quite heavy and we don't
want users to directly call them. We now ensure they are private.
closesodoo/odoo#47842
Task: 2154079
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.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.
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.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>
Main goal of this task is to create single accounting entry
(AE) when closing a pos.session instead of individual AE for
each order in the session.
This significantly minimizes the number of created journal
entries by point_of_sale which also results to faster closing
of session when there is large numbers (order of thousands)
of orders. It also eases the reconciliation of payments because
on one hand, cash payments are automatically reconciled and on
the other, other payments are combine in a receivable line
based on the payment method.
**Important points to note**
1. Two new models (pos.payment.method and pos.payment) are
introduced replacing the functionalities of account.journal
(and account.bank.statement) and
account.bank.statement.line, which served before as payment
methods and payments.
2. The creation of single AE relies on the receivable_account_id
defined in each pos.payment.method. This receivable_account_id
is supposed to be different from the account module's receivable
account, thus, a new receivable account for pos is introduced
in each localization.
3. A simple example below can illustrate this change.
Given the following orders:
+---------+----------+----------+-----+-------+-------+
| order | payments | product | qty | price | total |
+---------+----------+----------+-----+-------+-------+
| order 1 | cash | product1 | 10 | 10 | 100 |
| | | product2 | 5 | 20 | 100 |
+---------+----------+----------+-----+-------+-------+
| order 2 | bank | product2 | 7 | 20 | 140 |
| | | product3 | 1 | 30 | 30 |
+---------+----------+----------+-----+-------+-------+
| order 3 | bank | product1 | 1 | 10 | 10 |
| | | product2 | 3 | 20 | 60 |
| | | product3 | 5 | 30 | 150 |
+---------+----------+----------+-----+-------+-------+
Instead of generating 3 accounting entries, a single
accounting entry (linked to the pos.session) will be created.
This accounting entry will have the following lines:
+---------------------+---------+------------+
| account | balance | reconciled |
+---------------------+---------+------------+
| sale | -590 | - |
| pos receivable cash | 200 | yes |
| pos receivable bank | 390 | no |
+---------------------+---------+------------+
| Total balance | 0.0 | |
+---------------------+---------+------------+
Note that the cash receivable line is already reconciled
because it can assumed that the payment is already received.
The unreconciled receivable line can be reconciled manually
using the reconciliation widget.
More examples can be seen in the tests.
TASK-ID: 1862388
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
Defined as this, the label of the selection field were translated during code
import, when building the python model, not when a user access the field values
as it should (and is already the case thanks to the ORM).
Trying to translate a string when no user-context is available is not only
useless but may cause bug on services with multiple databases (e.g. a SaaS).
In a multi-worker environment, when the code is imported, the _ method will use
multiple scenarios to detect the language and get a cursor.
As we have no available cursor in the frame (method _get_cr from GettextAlias),
the fallback is made on the cursor of the request.
In a multi-worker environment, this could be a cursor linked to a database in
another language than English.
In such scenario, the selections would be translated in the language of the
other database instead of displaying it in English
opw-1881956
Due to historical reasons the amount on a statement line is used to
find it again so the credit card information can be added to it.
Doing a search directly on 'amount' will fail in rare cases when
the currency rounding doesn't result in a float with the same amount
of decimals as the rounding specifies. E.g.:
>>> currency = env['res.currency'].browse(3)
>>> currency.rounding
0.01
>>> currency.round(74.85000000000001)
74.85000000000001
When that happens the credit card information is not saved in the
backend. To avoid this we do the float comparison properly with
float_compare afterwards.
PS. Ideally the logic in add_payment should be moved to an override of
_prepare_bank_statement_line_payment_values. This way we wouldn't have
to do these awkward things to find the statement line. But this
approach is not suited for a stable release.
opw-1832156
It used to be possible to run test transactions against mercurypay.com
using a regular swiper device, test credentials and test cards
provided by Mercury.
Mercury has recently disabled this saying this feature did not adhere
to certain PCI regulations.
It means that currently on the regular mercurypay.com network only
real cards (and thus real money) can be used.
Because we require a way to test without spending money this commit
allows to switch to the test network (mercurycert.net). It uses a
system parameter because we cannot introduce a Boolean on
pos_mercury.configuration in a stable release. It also changes the
test credentials to some that work on mercurycert.net.
Note that the regular 'production' swiper devices can not be used on
this test environment. This results in:
Error 004118: Failed to decrypt
The swiper contains embedded cryptographic keys specific to
mercury*pay*.net. Instead a specific 'development' swiper device with
embedded keys for mercurycert.net is required.
opw-1832156 (this is necessary to test that issue)
Purpose
=======
No way to fully set up a bank account from current form
Must go to journal form to simply apply bank sync, etc. Users cannot figure this out themselves, this is too much complicated
Also the meaning of Manual, Electronic, etc is not clear. What does it do? Field and options to rename or to explain very clearly in tooltip
Specification
=============
- Add some useful fields on the bank accounts form view to configure it completely
- Add tooltips on some selection fields to explain the meaning of each selection
- Reorganize fields in groups to be more structured
- Improve the field display for account journals that are used in pos
cgi.escape is unsafe (quote=False by default) and deprecated in Python
3. We already have an openerp.tools.misc.html_escape version which
forwards to the (modern and safe) werkzeug.utils.escape, just use that
everywhere, and convert extant uses of werkzeug.utils.escape to
utils.html_escape as well so that we do the same thing everywhere.
In Python 3, all of these were "consolidated" under urllib(.request,
.parse, .errors) which is inconvenient.
Since we already have hard dependencies on requests and
werkzeug(.urls, which is a backport of Python 3's unicode-aware
urllib.parse) migrate *everything* to that.
A sticking point is urllib2.URLError, those were (mostly) replaced by
the slightly more general IOError which URLError extends.
If there are open rescue sessions there will be multiple opened
pos.session records with the same user.
A better solution would be to make the POS client send back the
pos.session id it belongs to and use that instead, but this would be
unsuitable for a stable release. It will instead be done in master.
opw-743318
We generate the Mercury invoice number in JavaScript based on the uid
property of the order. That uid is generated by
Order.generate_unique_id() which generates a 12 digit number. A decimal
12 digit number can contain a maximum value of 10^12 - 1 which requires
40 bits to store. The issue is that Integer fields by default are backed
by a PostgreSQL integer type which is only 4 bytes. This means you can
end up with an invoice number you won't be able to store in the
database.
In order to resolve this we will update the field to be a Float field
instead which will result in a PostgreSQL double precision type which
allows values up to 10^308.
opw-671362
This new module integrate the 'Mercury Pay' electronic payment
provider with the point of sale.
This commit is the end result of a large branch whose main
author is Joren Van Onder <jov@odoo.com>, with additional
contributions from Martin Donies <mdo@odoo.com> and Frederic van
der Essen <fva@odoo.com>
Mylyna Hy