Considering the valid odoo version in the manifest version
The message before of this commit was:
Modules should have a version in format ``x.y`` or ``x.y.z``
It looks like it enforces to removing the odoo version part as invalid
But it is not, in fact, it is already supported
It is important since OCA enforces ``{odoo.version}.x.y.z`` format
It was already discussed here:
- https://github.com/odoo/odoo/pull/118420#issuecomment-1635047100
The message after this commit is:
Modules should have a version in format `x.y`, `x.y.z`, `16.4.x.y` or `16.4.x.y.z`.
Notice the Odoo version "16.4" is the current {odoo.version} for the moment this commit was done
It avoid confusing about the valid formats to use
closesodoo/odoo#128810
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
On Debian based systems, the `tzdata` package is maintained to reflect changes
in timezones and there is no need to upgrade the `python3-tz` package.
On the other hand, for those who are using `pip` and thus our `requirements.txt`,
the package needs to be up to date. By unpinning it in the requirements.txt:
- new installations based on pip will be up to date
- older installations based on pip can easily upgrade
- debian based installations have to maintain the tzdata package
- mixed installs like on runbot will rely on Debian tzdata
closesodoo/odoo#117527closesodoo/odoo#120155closesodoo/odoo#120205
X-original-commit: bb0fe71388c04cf26884eba89d2e0d9d0c00a185
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The method constraint to validate the Check Number is slow
1. Analyzing the following query:
```sql
SELECT
payment.check_number,
move.journal_id
FROM
account_payment payment
JOIN account_move move ON move.id = payment.move_id
JOIN account_journal journal ON journal.id = move.journal_id,
account_payment other_payment
JOIN account_move other_move ON other_move.id = other_payment.move_id
WHERE
payment.check_number::integer = other_payment.check_number::integer
AND move.journal_id = other_move.journal_id
AND payment.id != other_payment.id
AND payment.id IN (1085159)
AND move.state = 'posted'
AND other_move.state = 'posted';
```
The output is:
Planning Time: 3.354 ms
Execution Time: 2514.660 ms
Discarding null values
```diff
AND other_move.state = 'posted';
+ AND payment.check_number IS NOT NULL
+ AND other_payment.check_number IS NOT NULL
```
The output is
Planning Time: 3.216 ms
Execution Time: 0.140 ms
2. The constraint is computed even if the payment is not a check (check_number is empty)
Returning early save useless extra computating
It is not needed to compare falsy values for duplicated for whole table
3. The validation to check is it not a number is not optimal
It is transforming the string -> integer -> string to check if the string is not a number
but it is enough using only string -> integer not needed to transform to string again
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[str(int(i)) for i in check_numbers]"
> 1 loop, best of 5: 323 msec per loop
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[int(i) for i in check_numbers]"
> 2 loops, best of 5: 135 msec per loop
It is better but not enough, using `str.isdigit` method is 5x faster than original approach
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[i.isdecimal() for i in check_numbers]"
> 5 loops, best of 5: 64 msec per loop
closesodoo/odoo#83851
X-original-commit: 31e0ed8c957e8a6af7f6bd5d449b450967206eab
Signed-off-by: Olivier Colson <oco@odoo.com>
It helps to debug queries executed in postgresql from Odoo
in order to know where they were called
Enabling the postgresql logs with the following `log_line_prefix`
log_line_prefix='%t [%p]: [%l-1] db=%d,user=%u,client=%h,app=%a '
You will see the following output in the postgresql.log:
... UTC [394452]: [371-1] db=odoo,user=odoo,client=127.0.0.1,app=odoo-740755 LOG: 00000: duration: 0.074 ms statement: SELECT 1
Notice `app=odoo-740755` it is the odoo pid that executed the query
and the postgresql PID `... UTC [394452]:`
Then you will be able to match the odoo.log and postgresql.log using the PIDs
740755 DEBUG odoo odoo.sql_db.connection: ConnectionPool(used=1/count=2/max=64) Create new connection backend PID 394452
740755 INFO odoo odoo.addons: Running SELECT 1
Notice the Odoo PID `740755 INFO` and the postgresql PID `backend pid 394452`
Note: It will require enable the sub-logger
- `--log-handler=odoo.sql_db.connection:DEBUG`
It will helps to debug what process is executing each query in the database
or if a postgressql PID is showing a error log related to connection (not even from a query)
e.g. The livechat stuck and you don't know what happen but you can see the postgresql.log the following message
for the same PostgreSQL backend_pid related to longpolling odoo pid
[394452]: [371-2] db=odoo,user=odoo,client=127.0.0.1,app=odoo-740755 LOG: XX00: Could not receive data from client: Connection time out
closesodoo/odoo#82857
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* [FIX] test_lint: Consider variables for sql-injection
Using the following code:
```python
var = 'SELECT name FROM account WHERE id IN {}'
values = (1, 2, 3)
self._cr.execute(var.format(values))
```
It has a risky sql injection ignored before of this change
And allow psycopg2.SQL way mapping the variables declaration
* [FIX] sql-injection: AttributeError: 'NoneType' object has no attribute 'parent'
Using the following code:
queries = [
"SELECT id FROM res_partner",
"SELECT id FROM res_users",
]
for query in queries:
self.env.cr.execute(query)
The check sql-injection shows the following error:
- AttributeError: 'NoneType' object has no attribute 'parent'
So, Now it is validating if it is not None
* [REF] sql-injection: Using better naming for node_ofc -> node_assign
* [FIX] sql-injection: Fix false positive using BinOp "+"
Considering the following valid case:
cr.execute('SELECT ' + operator + ' FROM table' + 'WHERE')
The representation tree is:
node.repr_tree()
BinOp(
op='+',
left=BinOp(
op='+',
left=BinOp(
op='+',
left=Const(value='SELECT '),
right=Name(name='operator')),
right=Const(value=' FROM table')),
right=Const(value='WHERE'))
Notice that left node is another BinOp node
So, it need to be considered recursively
closesodoo/odoo#77864
X-original-commit: ce1a0171f61d2808470c185a91e9f8299e4efd25
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Column mappings are updated in-place, if multiple users are importing records
of the same model at the same time, this will trigger concurrency errors.
This is made worse by the error only being reported on commit (after having
processed the entire import) and being retried automatically, so it slows down
the user and the entire system, the more concurrent imports the slower.
Log except:
INFO dbname odoo.addons.base_import.models.base_import: done
ERROR dbname odoo.sql_db: bad query: UPDATE "base_import_mapping" SET "field_name"='name',"write_uid"=%s,"write_date"=(now() at time zone 'UTC') WHERE id IN (%s)
ERROR: could not serialize access due to concurrent update
INFO dbname odoo.service.model: SERIALIZATION_FAILURE, retry 1/5 in 0.8720 sec...
closesodoo/odoo#57655
X-original-commit: 3f5e9ca625b53021c100245f5786bda4069974ad
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Install "account_check_printing" module
Open "Accounting" icon from the main menu
It opens the journal dashboard by default
It runs the following search domain in account.payment model:
domain = [
...
('payment_method_id.code', '=', 'check_printing'),
...
]
It runs the following query:
SELECT "account_payment".id
FROM "account_payment"
WHERE ...
AND ("account_payment"."payment_method_id" in ($2)))
...
The average duration of this query is 37ms
It query is ran for each journal created
If you have created 600 journals (real case) so it will run 600 times
It will spend more than 22 seconds opening this dashboard
After that, you are available to create accounting actions since that
the menu is not available before of this dashboard
So, it is important to open it faster
Creating the following index:
- account_payment(payment_method_id)
The average duration of the last query is reduced to 0.935ms instead.
It means, it will spend 0.5s opening this important dashboard with 600 journals
44x faster
closesodoo/odoo#56831
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Currently the method `read` uses by default the parameter `load='classic_read')`
- `self.read(fields, load='classic_read')`
So, it computes `name_get` for all m2o fields for all records in `self`.
If you want to avoid computing the `name_get` to save time and process
You can use an empty string in load parameter:
- e.g. `self.read(..., load='')`
The method `self.search_read` call to `search` and `read` methods
but `search_read` method is not possible to assign `load=''` argument
(or other arguments of the method `read`)
- e.g. `self.search_read(..., load='')`
So, you need to use 2 lines of code:
records = self.search(...)
records.read(..., load='')
This commit changes `search_read` method to receive all keyword arguments of the method `read`
So, you can use `self.search_read(..., load='')` and the `read` parameter will be propagated
closesodoo/odoo#46391
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Installing base_automation module the methods: create, write, unlink and compute_field
are patched.
So, they will be used for all models.
It is important to save resources as possible.
The patched methods in base.automation read the original data
before to change so run all base.automation records.
But What about if there are not base.automation records?
So, we can save an extra read for all models
The same to pre-filter and post-filter
It adds a return early in order to skip this extra task when it will be useless.
closesodoo/odoo#52134
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If there is cron worker timeout logger error, there is a log for the
last cron running
If a "Base Action Rule: check and execute" fails, we need to know what
is the last base automated action based on-time running
This logger helps to looked for it
closesodoo/odoo#50493
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Change the decimal point and thousands separator for es_PE and es_CR
Set the currency symbol and position for Colon CRC
closesodoo/odoo#48535
X-original-commit: 88f420f37c305a7451be31ee36c479c2dffd4db8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
It was discussed previously from:
- https://github.com/odoo/odoo/commit/b79d05fff0cacb4d99ebc1b60f44d8dab757b806
I quote Olivier Dony commit message:
"""
Having it in INFO should be sufficient for its purpose, and will avoid
impacting all CI builds done on a system that does not have the lib
installed.
For the record, this is not a hard requirement because the lib was not
available in Debian stable packages at the time of release. It is only
enabled on demand for those who want the feature and can install it
manually.
Fixes#22426Closes#22459
"""
closesodoo/odoo#40788
X-original-commit: 0394f5e95702087b38357070aad43f2b477c374e
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Running the following 12.0 tests: https://github.com/odoo/enterprise/blob/b7768337d88990e403338c39e461ecb1796413ab/l10n_mx_edi_landing/tests/test_landing.py#L126
raise the following error using anglo-saxon:
```bash
File stock_account/models/account_invoice.py, line 60, in invoice_validate
File stock_account/models/account_invoice.py, line 89, in _anglo_saxon_reconcile_valuation
File 10n_mx_edi/models/account_move.py, line 12, in reconcile
File account/models/account_move.py, line 957, in reconcile
File account/models/account_move.py, line 948, in _check_reconcile_validity
odoo.exceptions.UserError: ('Account Mercancías en tránsito (115.05.01) does not allow reconciliation. First change the configuration of this account to allow it.', '')
```
closesodoo/odoo#34463
Signed-off-by: Josse Colpaert <jco@openerp.com>
Go to Menu / Accounting / Vendors / Bills
Search a partner with too many opened invoices
- E.g. 713 opened invoices (709 local currency, 4 foreign currency)
Choose all them
Press Open Action -> Register Payment
Wait to open the view.
Before this patch line_profile result
Total time: 1141 s
Line # Hits Time Per Hit % Time Line Contents
================================================================
243 2922 1,139,417,018.0 389944.2 99.9 amount_total = sum([MAP_INVOICE_TYPE_PAYMENT_SIGN[i.type] * i.residual_signed for i in payment_invoices])
After this patch line_profile result
Total time: 12 s
Line # Hits Time Per Hit % Time Line Contents
================================================================
243 2862 11,733,108.0 4099.6 98.1 invoice_datas = invoices.read_group([('id', 'in', invoices.ids)], ['currency_id', 'type', 'residual_signed'], ['currency_id', 'type'], lazy=False)
It means 95x faster
closesodoo/odoo#31313
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
It was already present in the accounting and purchase application but not in
sale menus.
Apply the same logic as in purchase and use a group_no_one
Closes#22862
It was already present in the accounting and purchase application but not in
sale menus.
Apply the same logic as in purchase and use a group_no_one
Closes#22862
The custom filters created through the search view are still private by default
but the ir.filters created manually (e.g. through xml files) are most of the
time global.
In odoo core addons, all ir.filters defined add the line
<field name="user_id" eval="False"/>
This should simplify the development while not changing the behaviour for
actual users.
Closes#8218
Since af9d6b86a1 and
5a57c29ff2 , python3.7 can be used to run
Odoo. This commit ensures that python3.7 compatibles versions of gevent,
greenlet and lxml will be installed without breaking compatibility with
Debian Stretch packages versions when using the Debian packaged Python.
Closes#25841
This makes sorting and indexing independent of the cluster/machine
configuration, and allows simple b-tree indexes to be used for
prefix-searches on VARCHAR columns without needing special operator
classes (and therefore without needing duplicate indexes).
The 'C' collation is built-in and always available on any postgresql
installation. It also allows any encoding/locale to be used, contrary to
other LC_COLLATE values, so it should never conflict with custom db
templates.
Admins who want to apply a special collation can still do so by creating
the database manually, instead of letting the system do it.
Closes#25196
Instead of use the original string by default.
Currently odoo export a PO translation file using the logic:
"If there is not a translation then use the source."
This generate a false 100% of file translated for tools based on PO
files.
This commit change this logic to:
"If there is not a translation then use empty string."
Odoo import a PO translation file supporting empty string because
if a item is empty string odoo use the original source.
Closes#17925
for computed street fields.
Qweb reports delete the node if the value is Null but won't if the value is an empty string. And then, l10n_mx_edi module has errors because there are nodes with empty string and the minimum value is one char.
Courtesy of Vauxoo. Was PR #17169
Backport in Saas-14 from opw-770430
9a07a459 added "override=True" to silence a Sphinx warning in about
the address node already existing, however the override=True parameter
was added in Sphinx 1.4 (alongside the warning), so this breaks in
1.2.
Only pass in override=True if we're in 1.4 or later.
Closes#18232
The old release of wkhtmltopdf are no longer published on the download page.
The developer explicitely asks to use the github link
cf: wkhtmltopdf/wkhtmltopdf#3524
wkhtmltopdf/wkhtmltopdf#3521
wkhtmltopdf/wkhtmltopdf#3518
wkhtmltopdf/wkhtmltopdf#3508
Closes#18146
for computed street fields.
Qweb reports delete the node if the value is Null but won't if the value is an empty string. And then, l10n_mx_edi module has errors because there are nodes with empty string and the minimum value is one char.
Courtesy of Vauxoo. Was PR #17169
This module adds some extra fields to the partner model, in order to be able
to manage extended addresses. However, those extra fields were not present
into the company model, thus making partner's addresses and company's
addresses displaying somewhat inconsistent.
This change takes those fields that were already present into the partner
model, and adds corresponding fields into the company model and view, so
addresses from both models are now shown the same way.
Closes#16547
If the company currency is not active (that should not happen but nothing
prevents it, probably happening with some CoA installation), the variable
company_currency_format is undefined and an error is raised.
Closes#15799
More information from https://en.wikipedia.org/wiki/Decimal_mark section:
"examples of use"
`The following examples show the decimal mark and the thousands separator in
various countries that use the Arabic numeral system.`
`Style: 1,234,567.89 Countries: Malaysia, Mexico, New Zealand, Pakistan,
Philippines, Singapore, Taiwan, Thailand, United Kingdom, United States`
Closes#14402
Historically, developers had to use the `eval` attribute to set
a False value for boolean fields in XML data files:
<field name="active" eval="False"/>
This is a source of errors for beginners, who tend to provide
a string value directly, as for char/text fields.
Unfortunately string values always evaluated to `True` booleans:
<field name="active">False</field> <!-- active == true! -->
This patch adds detection of some well-known falsy strings
(case-insensitive): `0`, `false`, `off`, as similarly supported
for the `noupdate` and `forcecreate` attributes of XML data records.
Closes#13152
closes#3336
Implicit relative imports have been removed in Python 3, and developers
should be encouraged to use explicitly relative imports to avoid
confusion between local and global modules
See https://www.python.org/dev/peps/pep-0328 for PEP on the subject with
reasonings and justifications
Moises Lopez - https://www.vauxoo.com/