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>
Gorash