This commit introduces the computation of the image size from a webp
binary source without relying on PIL.
This is needed by eCommerce to determine which image to fetch when using
the zoom functionality on the product page.
task-2774352
Part-of: odoo/odoo#85494
The library used to generate PDFs does not support the WEBP image
format. For those images to be included in reports, they need to be
converted. For security reasons, this conversion cannot be done on the
server, therefore it was decided to keep an already converted copy of
such images.
This commit converts uploaded WEBP images to JPEG and uploads them both
so that the report generation can use the JPEG instead.
This commit also pre-generates the resized version of images - and JPEG
versions of each of them.
task-2774352
Part-of: odoo/odoo#85494
*: mail, mrp, test_website, web, web_editor
Before this commit '.webp' images could not be used in odoo.
After this commit '.webp' images can be uploaded to odoo.
- can be used in image field
- can be used in HTML field image
- can be used in mails and website
- can be transformed (shape mask, filter effect, crop, rotate, resize,
adjust quality)
task-2774352
Part-of: odoo/odoo#85494
The `-i`/`--init` and `-u`/`--update` cli options behavior is only
defined when using a single database with `-d`/`--database`/`db_name`.
Using those two cli options along with multiple databases is undefined
and can have disastrous consequences[^1].
The server now crashes in this situation.
Fixes: #107188Fixes: #128273
[^1]: https://github.com/odoo/odoo/issues/107188#issuecomment-1627996425closesodoo/odoo#128306
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
When investigating an issue on a customer database, the diff view modal
can be pretty useful. However it is not very good looking and therefore
poorly readable.
This PR improves the CSS styling of that modal so that it resemble more
the diff view of GitHub. This is done by:
- Increasing the width of the modal
- Aligning the text to the top of the table cell, that way there is no
text floating in the middle of two lines
- Lightly coloring the whole line when there is a change on it while the
actual change is on a darker background
- Putting in red all types of change on the left and in green on the
right (instead of mixing green, red and orange together)
This commit is improving the tool that was made at [`96d3fa4`](https://github.com/odoo/odoo/commit/96d3fa4e01bf8afc35dbf0b7301ce75c6bf3a5c7)
closesodoo/odoo#127765
X-original-commit: bf412f6920b10376a979c9f95c4508dedfec5d5f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
A TypeError is thrown when an AST node is passed to `literal_eval`
because a string is expected and the object has no len().
Check the type of the expression and make sure it's a string before
calling len() on it.
closesodoo/odoo#126874
X-original-commit: 28b5cbb33a99cdca00daa35e5ae598cc8d4b2dae
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
This commit fixes the malformed comment that would sometimes comment out
the rest of the html resulting in an improper display.
this is due to the new html5 notation --!> not behing understood by
our parser.
this commit replaces any --!> into -->.
this commit also remove <!--> or <!--->
opw-2812488
closesodoo/odoo#126148
X-original-commit: 4fed0c36fedf271acc3520d8219763964753dabe
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Revision odoo/odoo@cabb9e7e57 introduced a
regression: This is no longer possible to import a data module
using `<field file="..."/>` in their data file.
This revision targets to restore the feature as expected.
The unit tests added covers the feature, so that regression
no longer happens in the future.
It introduces a new concept of temporary directory `file_open`
can read from.
e.g.
```py
with odoo.tools.file_open_temporary_directory(self.env) as module_dir:
with zipfile.ZipFile('foo.zip', "r") as z:
z.extract('foo/__manifest__.py', module_dir)
with odoo.tools.file_open('foo/__manifest__.py', env=self.env) as f:
manifest = f.read()
```
Note that `file_open` will be allowed to read from that temporary
directory only if `env` is passed to `file_open`,
and if the `env` is part of the same transaction/request than the `env`
passed to `file_open_temporary_directory`.
This is to avoid having users, whether from other databases,
or even the same database,
trying to access these directories not belonging to them.
e.g. If an admin uploads sensitive data in this temporary directory,
no one than him must be allowed to read from these files, not even
another user from his database.
closesodoo/odoo#126326
X-original-commit: ea5cfe2e9493e4ef5a9b81851af452c8c51e407e
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The Gevent worker has specifc needs in term of maximum concurrent
connections to the database and those needs are not compatible with the
default limit that is primerly set for http workers.
This PR makes it possible to supply a configuration dedicated to the
gevent worker.
task-id-3193565
task-id-2146565
closesodoo/odoo#125190
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Current behaviour:
If we add a blockquote in the `website_description` of a product on
the e-shop, we cannot checkout the product. Silent HTTP 400 error
code, due to an exception raised by
https://github.com/odoo/odoo/blob/bf772181933ce5334da35c8368455963b2478399/odoo/fields.py#L1987-L1993
Expected behaviour:
You should be able to checkout products even if they have blockquote
in their `website_description`.
Steps to reproduce:
- Install eCommerce, sale_quotation_builder (issue is present only
after installing sale_quotation_builder)
- On a product, with the website editor, add a `blockquote` to the
description of the product > Save
- In a private browser window, as public user, visit the product on
the e-shop and try to checkout with it.
- Observe there is no visible error, and we do not proceed in the
checkout process.
Reason for the problem:
The exception mentioned above is triggered when there is a
difference between the html content that is saved in the DB and after
sanitization, meaning that someone with escalated privilege saved
the HTML content by overriding the sanitization with
`sanitize_overridable`. In our use case the only diff is the
presence of the attribute `data-o-mail-quote-node` which is removed
after the sanitization.
Fix:
This issue can be resolved two ways:
1) Adding `data-o-mail-quote-node` to the list of save attributes,
meaning it will not be removed during the sanitization process.
Since this is an attribute that we add on `<blockquote>` nodes,
it can be considered safe, just like `data-o-mail-quote`.
2) Remove the attribute sanitization of the `website_description`,
just like it is done in the website_sale module.
Since the `website_description` and `quotation_description` are both
computed from one-another, they should have the same sanitization
level.
I am implementing both solutions, 1) because adding the attribute to
the safe list seems safe in general, and may prevent future
issues of this sort. 2) because it is the root cause of the issue,
since the bug is present only after installation of the
`sale_quotation_builder` module.
Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- master
opw-3297237
closesodoo/odoo#122154
X-original-commit: 23022144cb1a338db05870b28f17360b92c46a9c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
When passing a very large expression to `literal_eval`, the odoo server crashes.
To avoid this behavior, a limit needs to be set by using the env varaible `ODOO_LIMIT_LITEVAL_BUFFER`.
If the variable is not set, it defaults to 100Kib.
closesodoo/odoo#121882
X-original-commit: 0e4f3ac464b80573b3dab8761dfba54771da0128
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Signed-off-by: Dalcq Jordan (joda) <joda@odoo.com>
The function `drop_view_if_exists` only works when the view in question is a
regular view. Here we allow for materialized views to be dropped without any
extra logic added from the caller side.
closesodoo/odoo#121814
X-original-commit: f0db3454bde6759af9aa1b3c2751845a3b2949e7
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
One of the most costly part of a page loading when the ormcache is cold
is computing the assets node, the unique identifier of an attachment to
validate whether the existing attachment is still valid with the current
version of the static files.
This operation needs to glob assets path in the filesystem,
get the modification date, check attachments, ...
Right now this task is not really optimized and can take some time
because of an excessive number of glob on the filesystem, unnecessary
exists to define absolute path, double computation of file list and
modified times when getting js and css bundle separately, ...
A list of modifications mainly discussed in the pr message are made
with this commit to speedup things.
- split css and js unique
- prepare api for an in memory glob
- change api to propagate absolute path and meta information through
`ir.asset._get_paths`-> _get_asset_paths -> `_get_asset_content` ->
`AssetsBundle`
closesodoo/odoo#121159
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This issue is generated when the user uploads an image of more than
50.0 million pixels, so error would be generated. But, currently it raises a
`ValueError` which results in traceback. So, we replace it with
`UserError` so the user has an idea about Image size or pixel being excessive.
closesodoo/odoo#121396
Sentry: - 4075426049
X-original-commit: ac2a3966cb035f112bf6aebb1244dc8d67831d1a
Signed-off-by: Rémy Voet <ryv@odoo.com>
Before this commit:
Files that should be ignored in the manifest but aren't (js library for example)
it can happen that files have huge lines, the regex to substract the
comments will overuse memory.
For example, a file of 13M with a line of more that 8M characters, the
memory consumptions peak at 1.7G
The results might be different, but it's an acceptable compromise
closesodoo/odoo#120376
X-original-commit: 63b13af2e49a83168d4304a06b6489c4b86eabf6
Signed-off-by: Thibault Francois <tfr@odoo.com>
Steps to reproduce:
- Go to a website page > Add a 'Form' block > Add a new 'Selection'
field.
- Go to the page (in 'edit_translations' mode) > The selection field
options are not translatable.
The goal of this commit is to make the select options translatable
by adding an intermediate `.o_translation_select` element.
This element will handle option's text translations from the linked
`<select/>`. The final values are copied to the original element
right before save.
opw-3233360
closesodoo/odoo#120363
X-original-commit: 5ff53d7f289ec531f8369a47d02bd58252bb98a5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit makes the `dependencies` param of
`odoo.define` mandatory. It was optional and when
omitted, a regexp read the function to find the
dependencies. We can simplify it now almost all js
modules have been converted to esm.
The transpiler already adds the param for the es
modules except if the module has an alias.
task id: 3271352
closesodoo/odoo#119145
Related: odoo/enterprise#40040
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
There was two issues regarding the slides public views counter
1. If the `public_views` is set to `NULL` in database,
`increment_fields_skiplock` wasn't properly incrementing the count.
Indeed, in SQL, doing NULL + 1 returns NULL
```sql
16.0=# SELECT NULL + 1;
?column?
----------
(1 row)
```
To have the result we expect, COALESCE must be used
```sql
16.0=# SELECT COALESCE(NULL, 0) + 1;
?column?
----------
1
(1 row)
```
2. There is a mechanism, using the session,
supposed to prevent incrementing the public views
counter when a same user visits multiple times the same slide.
However, since 84d17e57e8
the visited slide was never actually added in the session,
because it was adding the slide id in a copy of the set
in session rather than adding in the set from the session.
Or, as this commit does, to re-assign the new set in the session.
closesodoo/odoo#119370
X-original-commit: fa5962d6f08979017842985004b3ec43416ee181
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
__Current behavior before PR:__
The size of an image field is guessed using the field name. For instance, an image field with `field_name = "XXXX_123"` is resized to 123 pixels when fetched.
This is can be an issue if a user creates an image field using studio in a form view.
If the user sets the label of the field as "Image 1", the technical name will become `x_studio_image_1`. Therefore, the image field will be resized to 1 pixel width.
__Description of the fix:__
Refactor the `image_guess_size_from_field_name` method to return `(0, 0)` when the field name starts with `x_studio_`.
__Steps to reproduce the issue:__
1. Open a form view (of any model)
2. Open studio
3. Add an image field with label "Image 1" (notice the technical name becomes in `x_studio_image_1` in debug mode)
4. Close studio
5. Upload an image on the created field
6. Save... The image is resized to 1 pixel width
opw-3242084
opw-3249632
opw-3253133
closesodoo/odoo#118960
X-original-commit: 3318f0e67da40983f52595aba933d8c8fd0f5cc5
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit changes the js transpiler to write sync module.
The goal is to remove all async module and simplify the
module loader in the future.
task id: 3265979
closesodoo/odoo#119186
Signed-off-by: Géry Debongnie <ged@odoo.com>
With the introduction of Knowledge Behavior Component, came a need to create
html nodes which would have limited interactions with the editor. i.e. an Odoo
view already has everything it needs to function properly, and when it is
inserted in the editor, any manipulation on the selection or on the style that
could be done with it should be prevented. Another example would be the
/template block (will be renamed /clipboard in the future) that has a
non-editable part (buttons which have a definite action in Odoo, and which
should not be interacted with) as well as an editable part inside of it).
To solve this use case, this commit proposes to mark specific html nodes with
a `data-oe-protected` attribute which could have one of three values:
- "true"
- Only mutations of type "attributes" can be registered on the node itself
which has the `data-oe-protected="true"` attribute
- Prevent mutations of children (and sub-children) from being registered by
the mutationObserver of the editor
- Prevent the selection handling when its anchor is inside a
`data-oe-protected="true"` element, even if it is `contenteditable="false"`
- Prevent the command hint
- Prevent the usage of the wysiwyg toolbar
- Prevent the dblClick tooltip
- Prevent the editor sanitization `Sanitize.js`
- "false"
- Designed to be contained inside a node with `data-oe-protected="true"`
- Re-enable all features disabled by a parent node with
`data-oe-protected="true" for the children of a node with
`data-oe-protected="false"
- ("")
- This is considered equivalent to have the `data-oe-protected` attribute
set to "true" (like other html attributes).
Another attribute is added: `data-oe-transient-content`, with the following
values:
- "true"
- Prevent the serialization of the children of the node, so they are not
shared during a collaboration.
- Transient nodes will be removed during `cleanForSave`, meaning that they
will never be part of the html_field value in the database
- ("")
- equivalent to "true"
The use case is an embedded view: there is a large quantity of nodes that
are not relevant to share nor to save, since it will be recreated with the
lastest data from the database, with the information relevant to the
currently active user each time it has to be rendered.
Note:
This commit does not handle the dynamic switch from a specific value for
`data-oe-protected` to another (i.e. switching from "false" to "" or "true").
This could cause a number of problems like:
- some mutations from when the value was "true" are not yet handled when the
switch (to "false") happens => those mutations will be registered as if they
were always under the "false" value, even though it is not the case.
- in collaborative, some nodes with oids that were not relevant (under the value
"true") won't necessarily have the same oids in between collaborators.
Therefore we cannot suddently listen to their mutations and expect the changes
to be shared by switching to "false".
In conclusion: the `data-oe-protected` attribute value should stay the same
during the entire edition.
Task-2821374
Part-of: odoo/odoo#104680
At the moment, XSD files are automatically downloaded at database
initialization, which is quite unnecessary.
The idea is to change Odoo's use of XSDs from being systematically
downloaded and used for validation to simply being available if desired
(e.g. for development or for customers who want them).
To achieve this, this commit does the following:
- remove the XSD download crons;
- provide a 'download XSDs' button in the Settings (next to the debug
mode button) which is available in debug mode;
- skip XSD validation if any required XSD file is not present; and
- deprecate the 'force_reload' option.
Entreprise PR: odoo/enterprise#38350
Task id: 3010716
closesodoo/odoo#118790
X-original-commit: c8174c7914e567489de74b574b076467440bdb2d
Related: odoo/enterprise#39879
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Prior to this change the convert tool did could mangle
the value of html fields when importing static data.
This is because html does not support 'self-closing'
except for HTML5 where it is allowed on void elements (such as img).
Browsers will assume that they are opening tags, left unclosed.
<span/> becomes <span>
They will then try to repair them with variying degrees of success.
Example where it fails:
`<t><t/></t><t><t/></t>`
should become
`<t><t></t></t><t><t></t></t>`
but it becomes
`<t><t></t><t><t></t></t>`
i.e. instead of closing the 'self-closing' tag immediately,
it puts everything inside a single t node
More concretely:
```
<t t-if>
<t t-out />
</t>
<t t-else>
<t t-out/>
</t>
```
becomes
```
<t t-if>
<t t-out></t>
<t t-else>
<t t-out></t>
</t>
</t>
```
which is invalid
-------------------------
The fix is simply to tell lxml that we want to print the xml nodes
as HTML nodes. This will make sure the output is compliant with
the standard and keep the semantic clear for the browser.
The issue does not appear before 16.2, as jquery used to fix it
for us until an update here 9c41ee5091ac06ac3ca71aeac607195c70061e4a
task-3162320
X-original-commit: 8ff2e1018264972107f19755ecda352d78dfa829
Part-of: odoo/odoo#118710
17c4f47b0a updated table_kind to return
`pg_class.relkind`, however the semantics are *not* the same, and that
was ignored: `relkind = t` is for *toast* tables, not *temporary*
tables. In `pg_class` the temporary-ness is instead signaled by
`relpersistence` (which applies to both tables and sequences), temp
(and unlogged) tables have `relkind = r`. `existing_tables` does that
correctly, possibly unwittingly.
While at it, upgrade `table_kind` to return an `enum` (whose value is
the old discriminant).
closesodoo/odoo#117444
Related: odoo/enterprise#39185
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before revision 5bf1207c8c
a new environment was created for each call
at `xml_import` or `convert_file`,
with `odoo.api.Environment(cr, SUPERUSER_ID, {})`
meaning the context was empty, meaning the lang was never set
Now that we pass from end to end the environment,
the caller of `xml_import` or `convert_file`
passes his own environment, therefore propagating
his `context` variables, therefore potentially passing
a lang in the context.
Therefore, since this change, the lang of the user
is taken into account when calling `xml_import`/`convert_file`,
and it updates the translation term rather than the source term
for translated fields.
This could be an actual/intended valid behavior,
this needs to be discussed,
but currently the places where `xml_import`/`convert_file`
is called expects to update the source term,
not the translated term.
See for reference
https://github.com/odoo/odoo/pull/116780#issuecomment-1486506663
Therefore, as this is an unexpected/unintended change of behavior
of the refactor 5bf1207c8c,
and as code blocks calling `xml_import`/`convert_file` have not
been adapted, we prefer to play it safe
and revert the behavior to what is was.
This is very possible other context keys will need to be dropped,
but one of the desired change of the refactor was to be
able to pass keys in the context, currently we prefer
to not wipe the environment context and just blacklist the one we
do not want to propagate, such as the lang.
If other related issues arise, we will then re-consider.
closesodoo/odoo#117621
X-original-commit: 44fa57e52fbc853b7756a96c73c94baa469c99ca
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
A visitor could visit a web page having a lang in its context that is
not installed in the databased he is connected to. The problem is that
visitors are not logged-in thus it is not possible to determine their
lang via their `res.users` preferences. The lang used instead is the
lang set in the `Accept-Language` header of the incoming request, that
header is set by various browsers in accordance to the user system
preferences or browser settings.
The browser lang (`Request.best`) is only parsed according to the
`babel` database, it is a lang syntactically speaking but not necessary
a lang that is installed in the database.
At the moment the browser lang is set in the context (inside of
`Request._get_dbname_and_session`), it is not possible to verify it is
installed in the database as no connection to any database as been
established yet. Instead the lang is validated inside of
`ir.http._pre_dispatch` which is the method responsible to prepare/fix
various stuff on the request/session/context.
In regard to 93b684d3c7, we prefer to fallback on English, hence the
modification in `get_lang`.
closesodoo/odoo#116683
Reference-to: 93b684d3c7 ([FIX] base: lang should fallback on english instead of arab)
X-original-commit: 743e97667e44cdaab6db334d807cf3d409cea621
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
before this commit, code in files for Odoo core which are outside of
root_path/addons/
e.g. odoo/models.py, odoo/service/model.py
cannot be translated. Because the translation tool thinks they don't
belong to any module
after this commit, by reusing the same logic while exporting these code
translations,
they will be translated by using po files of the 'base' module
closesodoo/odoo#116602
X-original-commit: e29aca207e95725d4072fe2a6dfc928128c1e47b
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
When upgrading a database with `l10n_multilang` installed, the
translations kept were not the right ones.
Here is the process that was executed during the upgrade:
* `base` is loaded: registry is loaded with `translate=True`, which
calls `convert_column_translatable`. This has the effect of setting
the value of the field to `{'en_US': name}`, with only that language
installed.
* `l10n_multilang` is loaded: the function `lang_install` is extended to
copy the translations of the templates on the instanciated records.
* `l10n_*` is loaded: the translation values are loaded from the `.po`
files. `lang_install` is called after the loading on the templates,
copying the value on the records. The value on the records is now
something like `{'en_US': name, 'fr_BE': nom, 'nl_BE': naam}`.
* `base/end-migrate` is executed: it copies the values coming from
`ir_translation`, without overriding the values that are already on
the record because of the order of the `||` operator.
This means that any value inputed by the user[^1] will be overriden by
the value in the `.po` files.
opw-3175383
closesodoo/odoo#115254
X-original-commit: 5d46cdee878d752b9a61a74762a8710be0890e9d
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Co-authored-by: HydrionBurst <cwg@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
With the special support for postmortem debugging removed, the
likelihood of needing / wanting the werkzeug remote debugger seems
even more remote (as it works in strictly less situations, only for
frontend non-json requests).
So remove that as well.
closesodoo/odoo#115176
X-original-commit: a2022783b652299155c460294c00dbced9b619ac
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
It's done nothing since #78857 and it doesn't seem like anyone has
cared (found no issues or tickets).
Rather than restore the feature, just remove the leftover bits.
X-original-commit: 4a7cfc8844eb9b754f16f9d013452d5bde8770b5
Part-of: odoo/odoo#115176
This field has been introduced in
https://github.com/odoo/odoo/commit/c68600cc5397700df4f40095c27723a2b1f90a22
The reason why is not really clear, given the commit message.
But, it looks completely unused nowadays.
We can therefore safely remove it.
In addition, this will save a lot of transferred data to the web client,
as currently all the fields of an action are read when the web client
loads an action,
including this one, which contains a long xml content.
For instance, with just base and the contacts modules installed,
to load the action of the Contacts menu,
it goes from 5.51kB to 1.05kB.
closesodoo/odoo#114041
Related: odoo/upgrade#4390
Signed-off-by: Rémy Voet <ryv@odoo.com>
This fulfills the goal of searching and fetching fields in a single SQL
query. We introduce the new method search_fetch() for that purpose.
Also introduce method fetch() to fetch some fields for a recordset if
they are not in cache yet.
The call graph is as follows:
search() calls search_fetch()
search_read() calls search_fetch() and _read_format()
read() calls fetch() and _read_format()
search_count() calls _search()
search_fetch() calls _search() and _fetch_query()
fetch() calls _search() and _fetch_query()
The methods _search() and _fetch_query() are usually the ones to
override to implement business-specific logic. The method _search()
returns a Query object to retrieve the records that satisfy the given
domain and are accessible for reading. The method _fetch_query() uses a
Query object to retrieve fields from the database and store them in
cache.
Also use search_fetch() to save one query in search_read() and the
reading of one2many fields.
Part-of: odoo/odoo#112126
Goal: make _search() always return a Query object, in order to make
search_read() in a single query when possible
Adapt the overrides of _search() towards the given goal.
Part-of: odoo/odoo#112126
This simplifies the use of subqueries by avoiding some costly default
order on the model or the idiotic order='id'. Method _flush_search()
has been adapted accordingly.
Part-of: odoo/odoo#112126
The parameter in search() is redundant with method search_count(), and
was making the calls less readable.
The method _search() is aimed at always returning a Query object. The
method can therefore never return an integer, hence the removal of the
parameter. This does not actually remove any functionality from the
method; counting result is simply given by using it differently.
Part-of: odoo/odoo#112126
The goal is to be able to use Query objects for both subqueries and
known ids tuples. This provides a single API for injecting either a
subquery or its resulting ids into another query.
Part-of: odoo/odoo#112126
Refactoring send&print wizard.
==============================
Main reason for this commit is that we want to let the user
decide when to generate the relevant documents / approvals
for its invoices. The natural choice is when the information
leaves Odoo. So now, each time the users decide to
download/send its invoices, he will be able to select the
relevant documents to be generated and the approvals to be
requested from the send&print wizard.
This used to happen automatically during the posting with lots
of undesirable behaviors (difficulty to update/revert, hard to
know exactly what will happen,...)
Main changes:
1/ Send&print wizard
- The model 'account.invoice.send' has been replaced by
'account.move.send' and became models.Model to handle
asynchrounous generation of documents (webservice,..) in
case of more than one invoice.
- The wizard is meant to be overriden in order to add
checkbox and document to be generated. A comprehensive exemple
can be found in account_edi_ubl_cii.
2/ Import invoice from attachments
- The decoding logic has moved from account_edi to account
on the attachemnts.
- The function _extend_with_attachments() serve as a common
entry point for import (from chatter, dashboard).
3/ Export invoice pdf / document
- All the specific actions to export attachments should be
implemented on the account.move and called from the wizard in
_generate_documents()
- The official pdf for the invoice is now only generated once
the user request it. In order to regenerate the pdf and
documents, it needs to be deleted.
task-id: 3117238
[enterprise](https://github.com/odoo/enterprise/pull/36757)
[community](https://github.com/odoo/odoo/pull/111857
)
[IMP] web: enable close on ir.actions.act_url in wizard
Before this commit, calling ir.actions.act_url on a modal
leaves the modal open. Which feels ackward in the send&print
wizard.
We now enable 'close' parameter on ir.actions.act_url. If set,
the wizard will close after act_url.
closesodoo/odoo#111857
Related: odoo/enterprise#36757
Related: odoo/upgrade#4387
Signed-off-by: Laurent Smet <las@odoo.com>
When python expression is evaluated in odoo form an action or qweb, we
are checking the opcodes generated by the evaluation of this code. We do
such a verification, because the code from actions and templates can be
written by someone having not access to the server and we don't want to
let them perform actions out of the scope of their database.
In python 3.11, some opcodes from previous versions of Python have been
renamed, grouped or sepcified. There are also new ones that have been
introduce.
In this PR, we are whitelisting the new ones that are needed by odoo to
properly work in this version of Python.
Part-of: odoo/odoo#112450
Benoit Socias