* add configuration for `flake8[flake8-rst-docstring]`
* enable docstring-related checks
* fix invalid docstrings in odoo's core & `base`
* fix a few more bits (mostly missing or incorrect `:param:` info
fields) are out of scope for the lint but my editor catches
closesodoo/odoo#74604
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
After some analyze on a lot of customer databases, seems like most of the time
their are performance probleme, and big store, it is due to a lot of big file
uploaded without reason. E.g. barcode, photo, ... a small one will be enough.
Now, we decided (in stable) to auto resize these pictures to 1920x1920px
by default and compress it with a quality of 80 when the source is bigger.
You can bypass this behaviour in your specific use case,
using a context key: 'image_no_postprocess' set to True.
You can disable the resize (and quality implicitely)
using an icp: 'base.image_autoresize_max_px' set to '0'.
You can change the default resize (1920x1920) format using an icp:
'base.image_autoresize_max_px' set to '<width>x<height>' (e.g. '1024x768')
You can change the default quality (80) using an icp:
'base.image_autoresize_quality' with a value between 0 and 100 where 0 skip it.
You can change the type of file that will be post process using icp:
'base.image_autoresize_extensions' (subtype of the mimetype comma separated).
Api of image has not be changed in this commit, only refactored to allow to
work with image directly without the need to encode/Decode in base64 the raw.
We decide to keep 1920x1920 by default instead of 1080p to avoid to resize
portrait picture in 1080px and stay consistent with field image_1920 that
return a 1920px image for width or height whatever the orientation.
+ fix some lint diff for ci style in master
closesodoo/odoo#78556
X-original-commit: d9ce0507960f247e1187baf7bd8399f90be237aa
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
In a previous fix [0], the call to exif_transpose was kept to allow
rotation of images format different than `JPEG`.
After a small test, it appeared that the call would crash if the image
in another format had the same `LensInfo` tag.
So it's safer to not call this method at all.
With this commit, the rotation tag is retrieved disregarding the file
format by using the `getexif` method if available, falling back to the
private method for Pillow < 6 support.
As a bonus, a test is also added with a small embedded `JPEG` image,
crafted with an `Orientation` exif tag and, for reference, the
`LensInfo`tag that caused so much trouble.
The fix referenced in [0] was not forward-ported as it was only moving
the code the is completely removed in the present.
[0] b83c48d5c48954193
closesodoo/odoo#65823
X-original-commit: bfd3f857b44f31f8077182d10cab869f42076464
Signed-off-by: Christophe Monniez (moc) <moc@odoo.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.
Before this commit, some images would display incorrectly orientated.
This typically happens for images taken from a non-standard orientation
by some phones or other devices that are able to report orientation.
The specified transposition is applied to the image before all other
operations, because all of them expect the image to be in its final
orientation, which is the case only when the first row of pixels is the top
of the image and the first column of pixels is the left of the image.
Moreover the EXIF tags will not be kept when the image is later saved, so
the transposition has to be done to ensure the final image is correctly
orientated.
closesodoo/odoo#38717
X-original-commit: 0f8e132ec0495fcdfa0a47d5b9c98a2f6f10c7d8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- When trying to access an image that need to be resized and cropped,
the code could crashes.
This is due to the fact that PIL expect to work with integer for
sizes, but in some cases we provide floats
closesodoo/odoo#37442
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Follow up of 58a2ffa26f
Variant specific field `image_raw_original` was meant to be renamed to
`image_variant_1920` instead of `image_variant_max` to follow the same naming
convention as the other fields (having the pixel number in the name).
closesodoo/odoo#35493
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Follow up of 344614b54a
If base64_source is falsy, we don't need to check the other parameters.
closesodoo/odoo#35489
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
The onboarding modal for setting up the few base fields of a company
has now been moved to a wizard
It is accessible from the general settings, but also in the onboarding
section of sale and account modules.
The following company settings are editable with that wizard:
- Set report **layout**:
The user can chose the overall look of the report. The current choices
are : *Standard* (default), *Background*, *Boxed* and *Clean*.
- Set company **logo**:
Changes the company logo.
- Set report **colors**:
The user can set the primary and secondary colors of the report through
a newly added widget allowing to pick a custom color.
When changing the **logo**, colors are automatically set to its most dominant
colors.
> A "Reset colors" button also triggers the color calculation.
- Set report **font**:
Changes the overall font of the report. Only Google Fonts are used
for enhanced compatibility.
- Company **tagline**, also called "header"
- **Footer**
- **Paper format**
- Report **preview**:
A mockup of a final report
Automatically updates when changing **layout**, **logo**, **colors** or **font**
Co-authored by: Julien Mougenot <jum@odoo.com>
closesodoo/odoo#33863
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
All of those fields `__get__` and method calls have a cost, it is small but when
done for many records it adds up, so they are better not done.
When creating 1000 products without image, this compute takes:
47ms +/- 1ms before the commit
37ms +/- 1ms after the commit
That's around 20% less.
Part of task-1918881
closesodoo/odoo#34294
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* = web_unsplash, website
Remove iframe upload and replace it with a proper RPC. The route is now only
accepting one file at a time, which makes it easier to maintain, and allows to
process the first file as soon as it is ready, instead of having to wait on
everything.
Also fix a bug where a document could not be uploaded because it would try to
parse it as an image.
Remove filter after search result from the JS and add the corresponding
conditions in the domain to avoid processing and returning unnecessary records.
If multiple attachments exist with the same URL, now display them all to avoid
confusion.
Compute all the necessary values in the python model instead of in the JS.
Allow SVG in the widget (the server already accepted them before).
Disable multiple image upload when not in multiImages mode.
task-1930726
PR: #31208
Both for performance and to avoid reducing the quality of an image in unexpected
situations.
- avoid applying useless operations in the first place
- do not count an operation if it had no effect
- allow quality 0 as a safe default that does not forcefully re-save the image
PR: #31208
Since b0ff033d69
To reproduce this issue: give to the processing method a PNG with transparency
and which is already encoded in palette mode.
In 12.0 such image could be `addons/payment/static/img/codensa_easy_credit.png`.
In earlier versions of Pillow, adding an alpha channel to such image would have
no effect, but since version 6.0.0 they raise an exception when that happens.
The PNG spec forbids the use of a full alpha channel with palette-based images
according to http://www.libpng.org/pub/png/book/chapter08.html#png.ch08.div.5.2
task-1998639
closesodoo/odoo#33628
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* = tools, base, web, website_profile, website_slides
Before this commit it was impossible to pass those parameters in the URL because
they were received as string but expected as int.
The opportunity is also taken to properly use named parameters when calling
`image_process`.
closesodoo/odoo#33506
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This allows to more easily customize each method, and it gives more flexibility
regarding which operations to apply and in which order.
task-1958000
PR: #31811
Previously the image that we uploaded as a favicon of the website was not
resized, so it could be extremely excessive in size and resolution, and it also
was not guaranteed to be a square.
Now we always resize it appropriately and save it as an ICO file.
The default favicon is now applied to all websites instead of only the first.
task-1958000
PR: #31811
* = hr, im_livechat, mail, payment, purchase, web, web_editor, web_unsplash,
website_profile, website_slides
Since the merge of all image tools into one function, the intermediary functions
are not needed anymore.
task-1958000
PR: #31811
Make the image tools more consistent and easier to maintain by having a single
function handling all the cases, instead of several functions doing more or less
the same thing with obscure differences.
Also introduce a new function to guess the size based on a field name, to be
used in the following commit.
task-1958000
PR: #31811
Following commit: 6801baa662
Crop is always used when we know the target size. Therefore there is no point
to pass a ratio argument. However size is required now.
Also "center" is always used, so make it the default type.
task-1958000
PR: #31811
* = website_partner, website_profile, website_sale, website_slides
Before
======
Since commit: 2e3848b394
The images that are resized have additional borders if the target ratio is
different than the image ratio. Those borders are transparent if the image
format supports it, and are white otherwise.
With that current solution, if the background where the image is displayed is
another color than white, it is looking really bad.
Moreover, most images are stored resized like this, so it is not even possible
to decide if it should have borders or not depending on the context, the
original image and ratio is forever lost.
It is also inconsistent because if the image is already smaller than the target
size then it doesn't include borders. In that case it keeps the original ratio
instead of the target ratio. So it isn't even guaranteed that the target
ratio is going to be respected.
After
=====
This commit will solve all of those problems by always keeping the ratio of the
original image.
This implies the views should be taking care of adding borders when necessary.
task-1958000
PR: #31811
This commit introduces the possibility to resize and to select the quality when
optimizing an image for web.
This will be used by the media dialog in a future commit.
The arbitrary resolution limit of 42e6 has been increased to 45e6 to fit some
of the biggest images we might get from Unsplash, and this value has been moved
into a variable so it can be customized.
The mimetype computation has been moved after the image processing because in a
next commit the operation could return the image in a different format than what
was originally given. Eg. BMP -> PNG, or unsupported format -> JPEG.
task-1958000
PR: #31811
The image tools were accepting an encoding parameter but it was never used.
Indeed the given images are always encoded in base64.
`image_colorize` was the only method not taking base64 directly, so it has been
modified for consistency. This allows to change the code in partner to not
base64 decode the image in some case just to be base64 encode it again after.
`crop_image` and `limited_image_resize` have been slightly refactored to account
for this change, but in this commit their behavior was kept.
task-1958000
PR: #31811
Add support for a 256*256 image, to be used in the following commit.
Define sizes in named variables instead of being hard-coded in several places in
the code.
Allow parameters `preserve_aspect_ratio` and `upper_limit` to be passed from
the different helper methods.
Factorize the code inside `image_resize_images` to make it easier to read.
Add new function to compute whether the size of an image is above a given size.
task-34045
PR: #30656
The 7d85ab1eac refactor of 'ir.http' introduced changes in `web/image` that
caused the route to no longer return early (to avoid data processing steps)
in the case of redirection and that caused `binary_content` to not set the
mimetype of the `ir.attachment` when it was an URL.
This commit fixes those issues, allowing `web/image` to redirect properly.
closesodoo/odoo#30777
*: tools, web, website, website_forum, mail, im_livechat
This commit refactors ir_http to make it more readable
and flexible.
Move the resize function of web/image to odoo.tools
Co-authored-by: XavierDo <xdo@odoo.com>
Co-authored-by: Antony Lesuisse <al@openerp.com>
closes: #28563
task: #1908896
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
- Add a method for generating an image data URI, and expose it in QWeb context
- Fix reports, website templates or mail templates with data hardcoded
data URIs, to use the helper (Python cases), or the existing
kanban_image helper (for JS cases)
This will gracefully handle SVG support in addition to classical image
formats.
Closes#26635
Introduce official support for SVG files in the framework, including the
following parts:
1. When client-side SVG images are uploaded, the content is displayed until
you save using data URI scheme according RFC 2397 [1]. This scheme requires
to specify content format. Using hardcoded "image/png" works for all images
types except SVG.
Type-sniffing is done using "magic byte" detection via the first base64
encode byte, so that the proper data URI scheme can be used.
This should not cause SVG-related security problems as the file is
displayed through `<img>` tag, which does not allow SVG scripting [2].
2. Make /web/image controller compatible with SVG
3. Add support for SVG files for company logo, which uses a dedicated
controller.
4. Resizing of SVG files is a no-op, as it makes little sense for a
vector-based format. We also want to avoid micro-alterations to the SVG
document (in "natural" viewport parameters) as we would store multiple
copies of the files in the filestore.
5. Because SVG files are inherently dangerous, upload of SVG files is
restricted to administrators, either by blocking it directly before
saving it in the database (binary fields with attachment=False), or by
neutering them to text/plain mimetype (for binary fields with
attachment=True)
6. Add tests for the SVG upload cases and for the non-admin uploads.
[1] https://tools.ietf.org/html/rfc2397
[2] https://www.w3.org/wiki/SVG_SecurityCloses#26635
- the image.crop_image method doesn't defaults the format to PNG anymore.
Instead it uses the format of the original image
and defaults to jpeg as a last resort as the save method requires
a type if it is called with an image object.
When cropping the image with a size, we crop it first and then we make a thumbnail out of it
Before this commit, the same byte stream was used, meaning that the thumbnail was
appended to the original
After this commit, we reset the stream
OPW 1876496
closes#26575
This commit is the counter-part of an enteprise commit introducing
the Documents app.
Here is a summary of what has been done:
- tweak unlink of ir_attachment to prevent unlink recursivity
(when attachments are attached to ir_attachments)
- improve ir_attachment kanban view
- add several arguments to binary_content controller:
- 'force_ext': to force the extension in the filename, base on
mimetype
- 'share_token' and 'share_id': to autorize download from a
share link
- add 'thumbnail' field on ir_attachment to optimize Kanban view
- add 'upper_limit' argument to image to allow to bypass the
500*500 size limit
- DocumentViewer now handles text files
More information available on task 1853490
Co-authored-by: Pierre Paridans <app@odoo.com>
Co-authored-by: sri-odoo <sri@odoo.com>
Co-authored-by: ThanhDodeurOdoo <tso@odoo.com>
Purpose of this commit is to finally stop adding extra padding to
website logo. Indeed not giving square logos lead to padding added
to images, leading to not so beautiful logo that makes people sad.
Before this commit
* partner's image was resized to square 1024x1024. Extra padding was added
if user provided rectangle image;
* due to this website logo resized to square when rectangle logo provided;
After this commit,
* sizes dict can be passed in image resizer of tools;
* e.g. tools.image_resize_images(vals, sizes={'image': (512, 512),
'image_small': (128, 128)})
* image field in partner will resize with max width 1024 and height based
on given image ratio (still image_medium, image_small will be default
square images);
* now website logo will respect actual aspect ratio
This commit is related to task ID 31994 . Future commits should probably
clean all that mess, but at least it seems we have something that works.
Fixes#20046
Simply reverting e5ef1c5917 looks to
work *but* since I didn't note the repro case for the issue and don't
remember what it was it may re-introduce previous breakage. Instead,
ensure all "sizes" for the image are reset if any of the sizes is
present *and* Falsy by adding a final case to the conditional.
If any of the image fields is present and non-falsy one of the
previous branches will be taken, so we can just check that any of the
image fields is present at all (this implies it's falsy).
Fields sent from the client are pretty much always *text*. This can be
problematic for image fields sent as base64 *text* as in Python 3 the
base64 routines only work between bytes.
Alter the core field-resizing function (image_get_resized_images) such
that it ensures text base64 sources are encoded back to bytes before
being forwarded to the main resizing routines (which I don't think
should deal with *that* issue).
Fixes#18985: error when trying to update a company's logo
Xavier Morel