The C implementation of the JS minification gives speedups between 6
and 55 times faster than the regex-based Python port, depending on
how compressed the input it (which is what our default implementation
does).
This is measurable when generating compiled assets bundle from scratch,
e.g. after installing/updating modules or source code.
As an illustration, the minification of a 2MB JS bundle can be 50x
faster:
```py
import rjsmin
from odoo.addons.base.models.assetsbundle import rjsmin as rjsm
js_source = open("web.assets_common_lazy.js").read() # 2MB JS
%timeit rjsm(js_source)
# -> 339 ms ± 495 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)
%timeit rjsmin.jsmin(js_source)
# -> 6.88 ms ± 213 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
```
It's also a drop-in replacement, as long as you rjsmin 1.1.0 or better
is available (to support format strings properly, a.o.).
See also the documentation of rjsmin: http://opensource.perlig.de/rjsmin/closesodoo/odoo#104283
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
All major systems (debian stable, ubuntu lts, windows) support py3.8
and all dependencies used by Odoo come with wheels for that version.
Most developers at Odoo SA uses 3.8 already and runbot is using ubuntu
jammy (which comes with py3.10) to test the current 16.0/master.
closesodoo/odoo#119492
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Maxmind offers multiple ip-geolocalization databases, historically we
have been using the City database which contains records on a
city-basis. Many years later it turns out we are primary using geoip to
know the country of the user. Geolocalization in the City database is
considered slow by our standard and we have been clever in order not to
geolocate each request by saving the info in the session.
On the other hand, the Country database that is offered by Maxmind is
much more lightweight and geoip using that country is considered a fast
operation by our standard.
In this work we make Odoo compatible with both the City and the Country
databases. Using multiple database at the same time, we can be smart and
only query each of the two on-demand. If a user ask for its country,
we'll use the fast Country db. If a user ask for its city/timezone we'll
use the slower City db.
By default it loads both database from the `/usr/share/GeoIP/` folder,
respectively the files `GeoLite2-City.mmdb` and `GeoLite2-Country.mmdb`,
you can provide alternative paths using the `--geoip-city-db` and
`--geoip-country-db` CLI options.
In the same mindset as #86015, geoip is still lazy. It is done on-demand
and the result is cached on the current request. The different with the
related PR is that as we know consider geoip to be fast, we no longer
cache the result in the session.
Task: 2848206
Part-of: odoo/odoo#91337
Also, as the rpm is not built from the deprecated bdist_rpm anymore, it's
time to remove useless requires from the `setup.cfg` file.
On the other hand, the soft requirements in the `setup.py` are now
synchronized with the hard requirements.
closesodoo/odoo#102849
X-original-commit: 20920ae968d6d5d2e51c970e9a2536e55965c53b
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
We have our own html2plaintext, already used in lot of use cases instead of
just a few for the html2txt library.
Notably for emails: most emails going through Odoo stack use our simple
html2plaintext to format the body alternative. When no body alternative
is given to ``build_email`` an alternative is built using the library to
remove. Using our own parser allows to have the same results compared to
using ``MailMail.send()``. Difference lies in spaces and new lines as well
as markdown. Our html2plaintext is a bit simple and does not try to generate
Markdown but generates a simple plaintext version.
This also helps solving some issues with depending on that library.
Task-2702034
closesodoo/odoo#82486
X-original-commit: b3b9627b655cd7cb928925affed6cc8d92661e8d
Related: odoo/enterprise#23364
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Mako is not used anymore for a long time.
closesodoo/odoo#78781
X-original-commit: fb9f89afbc7a22e82309150617e8b5de5c995ff9
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
With the release of Debian Bullseye the time has come for the balancing
act by trying to update the requirements.
The constraints are the following:
* Stick as close as possible to python3-* Debian packages versions
of the current Debian stable.
* Same but for the Ubuntu LTS version.
* When one of the above package is patched by Debian or Ubuntu
maintainers, set the upstream version that includes the patch if any.
Also, as support for python < 3.7 is dropped, some cleanup can be done.
The `reportlab / pillow` combo is a special case:
* Pillow has to be updated to 8.1.2 as this version includes the
security patches that were added to Ubuntu package 7.0.0 (Focal).
* Reportlab crashes with 8.1.2 with version prior to 3.5.54 [0].
The problem does not occur on Ubuntu Focal as both versions from
the Ubuntu packaging are compatible.
So the reportlab 3.5.59 is chosen as it's the Debian Bullseye version
and to avoid multiple lines for a few minor versions.
[0] https://hg.reportlab.com/hg-public/reportlab/rev/0cf382dab63b
X-original-commit: 794677fb6a3391379200eb2144a6ed372e89c17a
Part-of: odoo/odoo#78781
A dependency on python pyopenssl package was added in #61853 and flew
under the radar. As this package is pure python, it should not cause any
arm.
Also, it seems that the gsfonts package is needed on Debian to print
things like barcode badges. Previously, the gsfonts package was a
dependency of python3-renderm package which is itself a dependency of
odoo. The gsfonts dependency was removed in the python3-renderpm Bullseye package.
With this commit the gsfonts dependency is set on the odoo Debian
package directly.
X-original-commit: 248762c80fbf3396d44ea9b55153dcd1d36d3490
Part-of: odoo/odoo#78097
As Fedora 32 was the current release when Odoo 14.0 was released, this
should be the supported version.
Also, a few old libs were still in mentioned in the packaging files.
They flew under the radar because they never broke the packaging.
This is not the case anymore, those libs disappeared from the Fedora
repos.
It seems that pyparsing is not used anymore since 5a1c06a19 and thus can
be safely removed from `requirements.txt` too.
pychart is not used anymore since 3425752ea.
While at it, remove mix of tabs and spaces in package.dffedora, also add
missing packages to avoid installation at test time.
Now that I started down the slippery slope, also removed some `-dev`
packages in package.dfsrc as wheel's are available.
Finally, the rpm install script now detects the python ABI version in
order to avoid update this file at each ABI change in Fedora.
Fixes#63719closesodoo/odoo#65288
X-original-commit: a8deb1dd433e3a1690d593e83ade6af46326a26b
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
It has been a recurrent request from customers to be able to send email
messages to email addresses containing non-ascii characters. [IDNA] is a
domain extension to allow unicode characters in domain names. [SMTPUTF8]
is a SMTP extension to allow unicode in any header.
IDNA defines the [punycode] encoding which translates unicode to an
ascii representation. This encoding MUST be used to encode domains.
SMTPUTF8 is an SMTP extension that allow utf-8 in all headers on the
envelope.
[IDNA] https://tools.ietf.org/html/rfc5890
[SMTPUTF8] https://tools.ietf.org/html/rfc6531
[punycode] https://tools.ietf.org/html/rfc3492
Task: 2116928
opw-2229906
opw-2248251
closesodoo/odoo#47709
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
At 795c7b0a94 the external dependencies was changed from trying
to import 'ldap' to checking than 'pyldap' package was installed.
The problem is that pyldap is a unmaintained library that should no
longer be used, as explained on the package page:
https://pypi.org/project/pyldap/
"The pyldap fork was merged back into python-ldap, and released as
python-ldap 3.0.0."
Having pyldap version >= 3.0 installs python-ldap automatically and
will not cause any issue.
The Debian control file package name is adapted to use the latest.
The "ldap" externalm dependency defined in __manifest__.py will cause
pkg_resources.get_distribution() to fail in both case ("python-lap" or
"pyldap"), but the "import" fallback will succeed. For that reason, the
log warning is turned into a log info.
closesodoo/odoo#43769
Note: This library should be replaced by the pure python "ldap3" library.
X-original-commit: 1afd0ccf20881ba97e3c07dffb33e9a3a0b2cda4
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
In 12.0 it was 3.5 but for 13.0, it is acceptable 3.6.
Debian Buster has 3.7 and Ubuntu 18.04 LTS has 3.6
This will avoid undeterminist errors with OrderedDict
CentOS 7 still does not ship python3 by default but it is possible to
install it and CentOS 8 with python 3.6 was released in septembre 2019
closesodoo/odoo#38827
X-original-commit: 14e3e7524c2edd08ddf19afe512cb4462d070c0b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since commit 632fa044c3, polib is used instead of a custom pofile
reader. The setup.py file was forgotten in packaging, leading to a
faulty source package.
closesodoo/odoo#34585
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
As stated in issue #27752, some Debian packages are only recommended.
As a consequence, these packages are not installed on the Official
Docker image. In that case, if the user wants to install an Odoo module
that needs one of these package, the Docker container has to be
modified.
python3-qrcode and python3-vobject are now part of the latest Debian
stable (stretch) and the latest Ubuntu LTS (Bionic Beaver).
Also, they are pure python, and very small.
Thus, the Debian package can depends on them.
co-author: @sbidoul
Fixes#27752Closes#28588Closes#28371Closes#28372
PKG-INFO is generated during the setup phase and is not needed anymore.
Also this file contains outdated informations.
py2exe is not used anymore to build the windows installer.
closesodoo/odoo#28494
When trying to import an OFX bank statetement under MS Windows, a
Traceback states that BeautifulSoup is missing.
During the build process, py2exe didn't autodiscover that BeautifulSoup
is needed by the ofxparse package.
With this commit, BeautifulSoup is explicitely added to py2exe packages.
The Nightly VM was updated accordingly.
opw-1848202
Purpose:
The psycogreen module is unmaintained. Last source update was in
2015 and last pypi package was in 2012. Odoo only use a small
part of the psycogreen module that could be written directly in
the odoo code. This commit reproduce the small function from
psycogreen used in ODoo and remove all depencies from it.
Also the copyright and license are honored and the documentation
is updated accordingly.
pypi pckage: https://pypi.python.org/pypi/psycogreen
bitbucket repos: https://bitbucket.org/dvarrazzo/psycogreen/
The vendored html2text is *really* old and absolutely not
P3-compatible.
There is a maintained version on Pypy which is, so use that and stop
vendoring html2text.
PyPDF is unmaintained and abandoned (as noted on its home page
http://pybrary.net/pyPdf/) and was never updated to Python 3. PyPDF2 is
a fork which provides a mostly compatible API and is P3-compatible.
Replace PyPDF by PyPDF2.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
- RML Reports
- Webkit Reports (most part already removed by 13b9982c62)
- LocalService in netsvc.py
- rename attributes like rml_% to report_%
- rename ir.actions.report.xml to ir.actions.report
- allow rendering directly on an ir.actions.report by calling render method
- remove 'controller' report_type
- remove unused res.font stuff
- remove print_report method in models.py (not used)
- restore removed call to pdftotext process in test_reports
The use of an entry point was considered in order to provide
an `odoo` command in the path for the packages users, but the
generated entry point will first check that all the things in
install_requires were provided in a not bright way: it'll check
that it matches a distribution name. This does not work because
python-chart does not have the distrubtion name "pychart" which
is provided by the python-pychart package in debian jessie. Same
for suds-jurko which is provided by python-suds in debian stretch
but does not have the distribution name "suds".
Also, adapted the packages tests to these cli changes.
and move it under the setup package. Since the rename of the
openerp directory into odoo, having a script named "odoo.py"
conflicts with a package named "odoo".
* use a special arg in odoo.py
* note that the previous implementation was relying on the fact that
the openerp-gevent file was located in the same directory than the
odoo.py file. This was no longer true since rev a0eb172cab
This commit brings back this behavior.
This reverts commit a0eb172cab and thus
allow to actually use the longpolling feature.
The commit was made originally to better follow the debian packaging
guidelines.
A better solution will be implemented for v10: removing the `openerp-gevent`
script to replace it with a special argument in `odoo.py`.
There is still a dependency issue as we need psycogreen but this dependency
is not met in debian wheezy. This will be made a hard dependency for v10 as
it is available in debian jessie.
opw 678334
This data file is required when making HTTPS requests
with Python's `requests` package. Without it, modules
such as account_yodlee/account_plaid won't be able
to call their secure API.
+ minor refactoring (3 strikes and the code is out)
Olivier Dony