| Age | Commit message (Collapse) | Author |
|---|
|
When invoking onchange() on a line in a one2many field, the inverse
many2one field is given as a dict of values. Those values are the ones
of the "container" record in the form view, and they include the "id" of
the container record. The method onchange() instantiates the container
record as a new record with the given values. Fix the code to set the
expected "origin" of that record to the record with the given "id".
closes odoo/odoo#71474
X-original-commit: ebfb5d90fd4ff65ee1d2fc73faf8f9eaa18f4521
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
|
|
`./odoo-bin -h` prints unnecessary spaces between sentences.
---
task-2431630
Finetuning of #71130
closes odoo/odoo#71331
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
|
|
This legacy package was supposed to be an alias to `odoo.upgrade`.
However, depending on how your import its sub-packages (and in which
order), we were ending with the module being loaded multiple times,
breaking the expectation of a singleton.
```python
In [1]: from odoo.addons.base.maintenance.migrations import util as m1
In [2]: import odoo.addons.base.maintenance.migrations.util as m2
In [3]: m1
Out[3]: <module 'odoo.upgrade.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>
In [4]: m2
Out[4]: <module 'odoo.addons.base.maintenance.migrations.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>
In [5]: from odoo.addons.base.maintenance.migrations import util as m3
In [6]: m3
Out[6]: <module 'odoo.addons.base.maintenance.migrations.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>
In [7]: m2 == m3
Out[7]: True
In [8]: m1 == m3
Out[8]: False
In [9]:
```
Now, with this import hook, we ensure that the modules imported from
`odoo.addons.base.maintenance.migrations` are aliases to ones imported
from `odoo.upgrade`.
```python
In [1]: import odoo.addons.base.maintenance.migrations.util as m2
In [2]: m2.__name__
Out[2]: 'odoo.upgrade.util'
```
closes odoo/odoo#71323
X-original-commit: b2ea37f185bc18ecc3701a4f1f1f7a9d37a23078
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
|
|
Technical name is not added to test_tags since https://github.com/odoo/odoo/commit/95b4f2ab4b5698ab3a28c9c35ac8da6fb6def983
at_install tag is added by default since introducing @tagged decorator: https://github.com/odoo/odoo/commit/b356b190338e3ee032b9e3a7f670f76468965006
Clarify how special tags at_install/post_install work.
Also, add dots for @tagged doc, because otherwise we have a mess in sphinx docs.
---
task-2431630
closes odoo/odoo#71130
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
|
|
Before this commit the PyInotify filesystem watcher used by the code
autoreload feature (`--dev=reload`) would not get a chance to free
it's inotify watches before the reexec, hence at each reexec triggered
by a code reload the inotify watches where accumulated until potentially
reaching the kernel limit `fs.inotify.max_user_watches`.
This patch ensures that inotify properly closes it's file descriptor
before we reexec:
https://github.com/dsoprea/PyInotify/blob/f77596a/inotify/adapters.py#L79
closes odoo/odoo#71284
X-original-commit: 8703ff1e3d9be6f2f5fce2e8c4e62589b05133fb
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
Steps:
- Install Website
- Go to Website
- Click "Go to Website"
Bug:
The default phone number on the website is not fictional and may cause
unwanted spam.
Explanation:
In North America, only 555-0100 through 555-0199 are specifically
reserved for fictional use.
> The industry also reserved a block of 100 numbers as fictitious,
> non-working numbers (555-0100 through 0199) for use by the
> entertainment and advertising industries.
Source: https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf
opw:2530388
closes odoo/odoo#71281
X-original-commit: 5a047574dde6b207697244c866749d3cd439922c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
|
|
The method filtered_domain() is broken for domains with hierarchical
terms ('child_of'/'parent_of').
To see *one* of the ways the implementation is broken, let `A` be a
model with `parent_id` pointing to `A`, and `a1` a record of model `A`
without parent (`a1.parent_id` is `False`), then this fails:
assert a1 in a1.filtered_domain([("parent_id", "child_of", a1.id)])
The reason it fails is that on
https://github.com/odoo/odoo/blob/f5519586d214a9b34ad24683a7f97c47802a3bad/odoo/models.py#L5377-L5380
`data` is empty since `a1` has no parent, thus
https://github.com/odoo/odoo/blob/f5519586d214a9b34ad24683a7f97c47802a3bad/odoo/models.py#L5403-L5404
fails, therefore the result of `filtered_domain` is empty.
Note: the implementation of the hierarchical operators is full of quirks
that are hard to emulate otherwise than by reusing the original code.
As a consequence, the current implementation may be broken in more than
one way.
Let's see another way the implementation is broken: let `B` be a model
without a `parent_id` field and with a `friend_id` field pointing
to `B`, and let `b1` be a record of model `B`. Then
b1.filtered_domain([("friend_id", "child_of", b1.id)])
throws an exception of the form shown below:
ValueError: Invalid field 'parent_id' in leaf "<osv.ExtendedLeaf: ('parent_id', 'child_of', 1) ...
Meanwhile the following code is still valid and returs b1:
B.search([("friend_id", "child_of", b1.id)])
closes odoo/odoo#71233
X-original-commit: e7a5ba95d8b7df5bbf545ef8afe0a1f5d0f70272
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
|
|
As part of the Python 3 compatibility effort,
01e35141479b8dfc4a390518f89fc52e7cec5396 moved all uses of urllib(2)
to werkzeug & requests as the packages were renamed and reorganised
between P2 and P3.
For `module.py`, it looks like I confused the `urls` local variable
for an already imported `werkzeug.urls` and just tried calling
`url_parse` on that. Which doesn't work, because `urls` is a
dict.
Fixes #71076
closes odoo/odoo#71117
X-original-commit: 0cfe528de82c1de8971e5bb5f66103447eae781c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
|
|
The requests_toolbelt package < 0.9 uses `from collections import ...`
which is deprecated in python 3.8 [0].
The request_toolbelt package is not a dependency of Odoo but is needed
by zeep [1]. Unfortunately, the Ubuntu python3-requests-toolbelt package
is still 0.8 [2].
This commit filters out the warning.
[0] https://github.com/requests/toolbelt/commit/979f95266c2044893b05cb2314e94c899915748c
[1] https://packages.ubuntu.com/focal/python3-zeep
[2] https://packages.ubuntu.com/focal/python3-requests-toolbelt
closes odoo/odoo#70137
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
Manually adding a line should not trigger the computation of the field,
just like modifying the line fields that occur in the field's domain.
In other words, the dependencies of the field should be limited to the
ones declared on field or its compute method.
closes odoo/odoo#71027
X-original-commit: 9000a50582db827ff12acdecf8ef91749122452d
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
When there is a materialized view that has not been populated any select
on it will fail.
Example of traceback:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/12.0/odoo/service/server.py", line 1162, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/12.0/odoo/modules/registry.py", line 86, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/12.0/odoo/modules/loading.py", line 367, in load_modules
registry.setup_models(cr)
File "/home/odoo/src/odoo/12.0/odoo/modules/registry.py", line 262, in setup_models
env['ir.model']._add_manual_models()
File "/home/odoo/src/odoo/12.0/odoo/addons/base/models/ir_model.py", line 321, in _add_manual_models
cr.execute('SELECT * FROM %s LIMIT 0' % Model._table)
File "/home/odoo/src/odoo/12.0/odoo/sql_db.py", line 148, in wrapper
return f(self, *args, **kwargs)
File "/home/odoo/src/odoo/12.0/odoo/sql_db.py", line 225, in execute
res = self._obj.execute(query, params)
psycopg2.errors.ObjectNotInPrerequisiteState: materialized view "x_bi_sql_view_report_copy" has not been populated
HINT: Use the REFRESH MATERIALIZED VIEW command.
```
Several upgrade requests have or had had this error which has been
solved with specific scripts.
Related to #40930
closes odoo/odoo#71002
X-original-commit: b208570ce8399bc6d3e4a8ba02eef6558e0a6ccc
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
Before this commit, link to the API documentation was referenced
to the master version, instead of the current one, 14.0.
Furthermore, the link wasn't adapted correctly following the documentation
reorganisation, which is also fixed by this commit.
closes odoo/odoo#61905
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
|
|
Purpose
=======
We want to be able to force the FROM headers when we sent email in
SMTP. So we can avoid the emails to be considered as spam.
Specifications
==============
This is done with 2 system parameters.
If the system parameter `mail.force.smtp.from` is set we encapsulate all
outgoing email from with the given value.
If the previous system parameter is not set and if both
`mail.dynamic.smtp.from` and `mail.catchall.domain` are set, we
encapsulate the FROM only if the domain of the email is not the same as
the domain of the catchall parameter.
Otherwise we do not encapsulate the email (same behavior as before this
commit).
Task 2367946
See odoo/odoo/pull/61853
closes odoo/odoo#70854
X-original-commit: 044532aed6f796cd93e37556b4a8ce47d2c23a7c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
|
|
the documentation in 12.0+, the majority of the documents have been moved and their old links are no longer valid. Some redirection rules will soon be deployed, but those rules might be dropped in some years and we want the links to still work, which is why we still replace the links to the new ones.
FW-Port of odoo/odoo#70675 (13.0)
closes odoo/odoo#70728
X-original-commit: 85c24961ab9ff5c1c79eb7415c97c46d9a77cca3
Related: odoo/enterprise#18283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
|
|
We have observed that in some circumstances, there is no field to
reflect on a given model. Avoid an exception in that case.
closes odoo/odoo#70774
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
|
|
When building a domain `(=|!=)` with
a Binary field stored in attachment and
the right part of the domain is not null,
the full binary content is logged, giving
the logs a huge size.
Now, the content of the binary is cropped to
20 chars as it is useless to log more.
opw-2527629
closes odoo/odoo#70699
X-original-commit: d54b30bb7feed52de86f4302dc4a01f2d4009782
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
Bug
===
1. Create an event which allows track proposal
2. Follow it and subscribe to "New Track"
3. Log in in incognito and submit a proposal
The email is not sent, because it's sent as the public user, which has
no email address set. And so it the 2 system parameters
<mail.catchall.domain> and <mail.default.from> are not set, we can not
know which email address used to send the email.
Note that this bug also occurs if you create a track with a user without
an email address set.
Task 2510181
closes odoo/odoo#69890
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
|
|
Base: seems related fields take only 1 extra query instead of 3
Crm: assignment seems to have been slightly improved. Some randomness still
happens.
Hr Holidays: seems it was further improved beyond space frontier
Test mail: those tests were a bit random, seems random is gone (hopefully)
Test mail full: updated local counters
Test mass mailing: seems we gained one query, updated local counters
closes odoo/odoo#70486
Related: odoo/enterprise#18180
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Have in a purchase order a first row with unit price 0
Export the PO adding unit price in the list of fields to export
The unit price is not reported
This occur because the first line of the order lines is meld with the
purchase order line but in the process the 0.0 values is discarded
opw-2510917
closes odoo/odoo#70355
X-original-commit: 242bf5024ce6ae9c32176cd1a65a4f57a242dd45
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
|
|
The only purpose of the module `test_documentation_examples` is to test
a few of the code examples shown in the developer documentation.
As de86b3fb79e removes the documentation sources from the repository,
the test module is removed as well.
DOC PR: https://github.com/odoo/documentation-user/pull/945
task-2352371
closes odoo/odoo#70178
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Antoine Vandevenne <anv@odoo.com>
|
|
still linked to it
Description of the issue/feature this PR addresses and current behavior before PR:
There is a discrepancy in the wording of the error message provided. The error reads that an 'internal user' is linked but really its a 'portal user.'.
Desired behavior after PR is merged:
The wording of the error is clearer, and it now says 'portal user' instead of 'internal user'.
OPW: 2498139
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closes odoo/odoo#69925
X-original-commit: cdd94cddc2ba3478bb41227896609aded2bd8548
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Kamen Zhekov <kzhekov@users.noreply.github.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.
closes odoo/odoo#70000
Related: odoo/enterprise#18001
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
Scenario:
- add a file in mass mailing editor => an icon is added linking the file
- save
- edit => the icon is replaced by a generic icon
- save
- send mail => no icon is shown in email received
The system is using eg. `data-mimetype="pdf"` to show the icon, before
12.0 this worked but in saas-12.3 the system uses mailing.mailing
body_arch's field that is sanitizing attributes and remove it on save,
so the icon is only working in received email if you save one and only
one time after adding file inside the mass mailing.
opw-2474053 (ticket for similar issue in 14.0)
closes odoo/odoo#70046
X-original-commit: 7e14515b84d8081557517df7e9dc7d8c0d17f2be
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
According to the app-store guidelines we are not allowed to sell from
the iOS app.
Our updates are currently blocked because of this.
In the rush, we have no choice but to hide the 'learn more' button
displayed on each app. This redirects the customer to the documentation
page where you can find subscription links.
And this is unfortunately not allowed by Apple...
Source: https://developer.apple.com/app-store/review/guidelines/#business
Related PR:
https://github.com/odoo/mobile-ios/pull/102
https://github.com/odoo/mobile-ios/pull/103
Task-ID: 2483253
|
|
|
|
The try/except is there to check that the string can be interpolated, so
it is catching a ValueError. But if there is a singleton error (when the
length of `self` is bigger than 1), it will raise a ValueError too.
The UserError raised in the except is then weird/wrong.
closes odoo/odoo#69538
X-original-commit: 36ebbb6f312d488b33bae098546ff71baf578a08
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
|
|
Have a large number of attachments with res_field set
Then go to Settings -> Technical -> Attachments -> add a filter "Res
Field" is set.
You will have traceback. This occur because the `_search` function will
omit from results records with res_field set, forcing recursive calls
until either we scan the whole table (80 records at a time) or we hit
max recursion limit
opw-2463634
closes odoo/odoo#69443
X-original-commit: 08fb44a1f8af9684c28c0dd5e82121193d9bef9a
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
|
|
Without the f-string literal the XML ID is not printed.
closes odoo/odoo#69359
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
1. Create a new user with only "Administration / Access Right"
2. Login as the user
3. Turn on debug mode (via plugin or by editing url)
4. Go to "Settings -> Users and Companies -> Groups"
5. Open any group form / Press "Create" button.
Bug:
Error "You are not allowed to access 'View' (ir.ui.view) records."
A user who is managing "Access Right" must be able to create/edit groups
opw:2492803
closes odoo/odoo#69306
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: mart-e <mat@odoo.com>
|
|
For customer invoices:
* do not set default date because if you prepare an invoice (and it gets
a default date), then validate it the next day, the date will be wrong
* set the date when posting if it wasn't set, because why not?
For vendor bills:
* do not set default date because you rarely encode a bill at the bill
date. Forcing the user to enter it reduces risks of user error
(duplicated vendor bill)
* do not set it when posting, same reason.
opw-2492862
Related #68368
Closes #68367
closes odoo/odoo#68689
Related: odoo/enterprise#17502
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
|
|
|
|
PyPDF2 can't read some PDFs due to bugs, lack of fault-tolerance and not
supporting some encryption schemes. When invoices are uploaded directly
through the Invoices / Accounting app, that will fail for those files
because it will try to read part of them. When invoices are uploaded
through the Documents app, they're not read, which means the customer
can end up in a situation where read and merge operations (like when
printing a selection of original vendor bills) will fail.
The structural solution for this is to replace PyPDF2 with a more capable
library, like pikepdf: https://github.com/odoo/odoo/pull/64356 .
This change is too impactful for stable, and there are compatibility
concerns as well.
A possible workaround is merging the PDFs we can and bundling the rest
together in a zip file. This is possible on the level of just
_merge_pdfs, but the PDF extension and mimetype are pretty hard-coded
and the changes required to switch them to ZIP based on what happens in
_merge_pdfs seem too impactful.
Instead, this fix detects as early as possible if the PDFs can't be
read and reports it to the user. The excluded PDFs can still be
downloaded individually. In this way the user has a workaround
and does not need to resort to trial and error to figure out which PDFs
are causing the problem.
Related tickets: 2359929, 2389679
closes odoo/odoo#68964
X-original-commit: 7a3fb09dbc68797522a3191a3358db296f279b36
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
Doing domains like [('something_ids', 'in', 4)] crashed the emulator because it was trying to check something was 'in 4', instead of reversing the check (as real form views do).
closes odoo/odoo#68966
X-original-commit: eb14583442f2729182ffb8ec7b069e2505df3577
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
What are the steps to reproduce your issue ?
1. Go to Contacts > Configuration > Localization > Countries > Select a country
2. Edit the 'Layout in reports' (enable debug mode) and add an invalid field
3. Create a Quotation and search for a customer from the country you edited.
What is currently happening ?
Traceback is raised and you can't select the customer anymore
Why is this happening ?
Because the key is not defined.
How to fix the bug ?
Handle KeyError to detect if the user put an undefined key
Handle ValueError to detect if the user put an invalid format key
opw-2447078
closes odoo/odoo#68974
X-original-commit: 7d6529fa91062393a257ffbf01c4fd09e2f128bd
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
|
|
When using "Generate Missing Terms" we export all translations and
reimport them with `create_empty_translation` so they empty translation
are made available.
But since we export all modules in the same PO file, the same terms that
might have different translation in different modules would get the same
translation value after using "Generate missing terms" which is
unexpected => usually we import/export PO file by module and so a term
translation is unique for one module only.
With this changeset, we import translation module by module.
When testing speed of Generate Missing Terms with 90 modules and 37000
translations, the timing taken change like this:
- original code: 21 seconds
- exporting/importing 1 PO file per module: 45 seconds
- exporting 1 TGZ file total/importing 1 PO file per module: 23 seconds
opw-2439029
closes odoo/odoo#68663
X-original-commit: f1dd07a7fb1b3c99839072521725cca8cef1eb2e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
|
|
partner without country_id
Before this, when making a partner without any country_id, any VAT could be set to it, which was inconsistent with the module's purpose.
closes odoo/odoo#68492
X-original-commit: 4c962437bd59a1e9302d8034e8870880994eb713
Related: odoo/enterprise#17358
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
|
|
A domain with a negated thruty leaf raises an exception here
https://github.com/odoo/odoo/blob/835197e48fbbee1c8ac35d52287537fa6f0bdd36/odoo/osv/expression.py#L614
due to
https://github.com/odoo/odoo/blob/835197e48fbbee1c8ac35d52287537fa6f0bdd36/odoo/osv/expression.py#L670
and the fact that `FALSE_LEAF != (1, "!=", 1)` and `TRUE_LEAF != (0, "!=", 1)`
Current wrong behaviour:
```
>>> distribute_not(['!', TRUE_LEAF])
[(1, '!=', 1)]
>>> is_leaf((1, '!=', 1))
False
```
This issue was noticed when adapting domains for fields that have been
removed during migration. Example (extract of) traceback:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/13.0/odoo/http.py", line 624, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
...
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 677, in __init__
self.parse()
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 814, in parse
self.stack = [ExtendedLeaf(leaf, self.root_model) for leaf in self.expression]
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 814, in <listcomp>
self.stack = [ExtendedLeaf(leaf, self.root_model) for leaf in self.expression]
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 562, in __init__
self.check_leaf(internal)
File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 618, in check_leaf
raise ValueError("Invalid leaf %s" % str(self.leaf))
ValueError: Invalid leaf (0, '!=', 1)
```
closes odoo/odoo#68657
X-original-commit: e20c23658d15a135e5f35b0e8dec6e3202cecaab
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
User may use Settings menu just to click "Manage Users" buttons. Such simple
navigation sends ``create`` request, which may trigger a chain of
recomputations. To avoid that we redefine ``create`` method to check if a value
is really changed.
The previous explicit implementation lacks in v14 two fields at least:
* from module `account`
```
qr_code = fields.Boolean(string='Display SEPA QR-code', related='company_id.qr_code', readonly=False)
```
* from module `enterprise/account_reports`
```
account_tax_fiscal_country_id = fields.Many2one(string="Fiscal Country", related="company_id.account_tax_fiscal_country_id", readonly=False)
```
Performance Tests
=================
In this test we click "Manage users" and check stats for
``res.config.settings/create`` request.
Demo database with eCommerce and Accounting app installed:
```
| | Number of queries | Query time, sec | Remaining time, sec |
|--------+-------------------+-----------------+---------------------|
| Before | 707 | 0.325 | 0.215 |
| After | 382 | 0.283 | 0.174 |
```
The same, but with extra 1400 invoices:
```
| | Number of queries | Query time, sec | Remaining time, sec |
|--------+-------------------+-----------------+---------------------|
| Before | 715 | 0.459 | 0.349 |
| After | 382 | 0.176 | 0.107 |
```
---
opw-2489335
closes odoo/odoo#68486
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
This reverts commit a6c26aedf4c8043ac79b241acf6d69d1498f0acd.
closes odoo/odoo#68461
X-original-commit: 18281db9c918ff7b2b0c2fba841ffd8a141f046f
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
When printing barcodes for a large amount of records, wkhtmltopdf will
make the same amount of http requests to the server in order to retrieve
barcodes. This can lead to performance issues or wkhtml to crash.
Fortunately, an already existsing qweb widget exists that include
barcodes images as inline base64.
With this commit, the web widget is a bit improved to accept attributes
for the generated image tag. Each option dictionary key starting with
`img_` will be converted into a tag attribute with the corresponding
value.
e.g.: `'img_alt': 'Barcode'` will result in `<img alt="Barcode"...`
The `alt` img attribute now defaults to `'Barcode %s' % value` with the
barcode value.
Finally, if the `symbology` option is not given, the widget defaults to
`Code128`. If `symbology` is set to `auto`, the action report will try
to guess the barcode type, based on the len of the value.
Cherry-pick of db8b3f1dbf780287fe807ab8d05f2858f3fa03f1
This backport of an improvement will permit to fix existing databases
that use the route `/report/barcode/...` in their reports with a large
amount of barcodes to print.
A `Mea Culpa for my sins` improvement was also done in this cherry-pick
and will be forward-ported up to master: a safer lxml.html Element is
used to build the img element.
closes odoo/odoo#68414
X-original-commit: c3eafec76c75b4e3b02e358bab66e2a05938b9db
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
|
|
Correct small typo that the module when exporting translations as CSV
file might have been the wrong module because we used variable from
previous loop.
This did not seem to cause any issue since in this given case in import
we got the module from the part before . in XML ID ({module}.{name})
that was right.
found when working on opw-2439029
closes odoo/odoo#68284
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
When importing transtlation from CSV, we:
- cut at `:` character to get the model
- used a model for types other than model and model_terms
This caused error that do not happen in PO import because:
- the model is before the `,` character
- the imd_model column is constrained to 64 characters, and a name that
is not a model could be over that size.
With this changeset, the CSV import match better current PO import.
opw-2439029
closes odoo/odoo#68260
X-original-commit: cff91c6acbb7ef6a884d4dc4170574b83ff6e4cb
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
