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>
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
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>
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>
The goal of this revision is to re-use the environment among the
different steps of the registry loading,
instead of creating a new environment for each step.
1. Simply To avoid to repeat the line
`env = api.Environment(cr, SUPERUSER_ID, {})`
multiple times in the code
2. This also allows to share the context among the different
steps. This is not yet used in this revision, but it could
be, for instance to avoid the current repetition to add the keys
`install_module`, in `convert_csv_import` and `xml_import._tag_record`
Part-of: odoo/odoo#108254
When a record is `forcecreate=0` and a reference of one of its fields is missing, the update of the corresponding module fails. In this case, we can skip the creation of this record.
An example of this issue is this [record](https://github.com/odoo/enterprise/blob/6411ae071ace980834befeb8040c94b1a05c8034/documents_account/data/data.xml#L17) in `documents_account` module (enterprise) when the reference of this [field](https://github.com/odoo/enterprise/blob/6411ae071ace980834befeb8040c94b1a05c8034/documents_account/data/data.xml#L20) is missing.
This can be reproduced as follows:
1. Create a DB with `documents_account` module
2. Uninstall `documents_account` module
3. Remove `documents.documents_finance_status`
4. Reinstall `documents_account`
```
Traceback (most recent call last):
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 680, in _tag_root
f(rec)
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 567, in _tag_record
f_val = self.id_get(f_ref)
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 663, in id_get
res = self.model_id_get(id_str, raise_if_not_found)
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 669, in model_id_get
return self.env['ir.model.data']._xmlid_to_res_model_res_id(id_str, raise_if_not_found=raise_if_not_found)
File "/home/ayman/src/odoo/15.0/odoo/addons/base/models/ir_model.py", line 1943, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)[1:3]
File "<decorator-gen-35>", line 2, in _xmlid_lookup
File "/home/ayman/src/odoo/15.0/odoo/tools/cache.py", line 90, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/home/ayman/src/odoo/15.0/odoo/addons/base/models/ir_model.py", line 1936, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: documents.documents_finance_status
```
closesodoo/odoo#107766
X-original-commit: 2e4f0667397d2d6670df50b9088fa9c23f1f9f5a
Signed-off-by: Christophe Simonis <chs@odoo.com>
When a record is created through xml data, its HTML fields should
receive a `type="html"` attribute, not a `type="xml"` attribute.
When important XML data with XML type instead of HTML type will have 2
differences:
- The field value will be prefixed by `<?xml version="1.0"/>`
- If the HTML contains multiple root nodes, the value will be wrapped in
a `<data/>` tag.
See `_fix_multiple_roots()` and the `xml_import` class for more details.
closesodoo/odoo#98239
Related: odoo/enterprise#30491
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Let's imagine this data
```xml
<record model="my.model" id="1">
<field name="name">parent</field>
<field name="children_ids">
<record model="my.model" id="1.1">
<field name="name">child</field>
</record>
</field>
</record>
```
Loading this data the first time, everything works fine.
But if we update it, this is what happens:
* load `my.model,1`: write on `name=parent` and `children_ids=None`
* load `my.model,1.1`: write on `name=child` and `parent_id=my.model,1`
The write on `children_ids=None` can unlink all the children if the
field is declared as `ondelete=cascade`
That will leade in all the records to be deleted and recreated, but
without keeping links with other documents.
For instance, when upgrading the `account` module, all the
`account.account.tag` are removed from `account.move.line` because when
the `account.tax.report.line` are updated, all the tags are deleted and
recreated.
closesodoo/odoo#82793
X-original-commit: de00316fa42173f3a5c394458bb4418e59e298cd
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
Co-authored-by: jva-odoo <jva@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
closesodoo/odoo#82238
X-original-commit: 5164739b835445fa11b2efc53e2ff839a4bad10a
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Those were not accounted for, leading to fstrings passing through
unflagged.
Also update the SQL checker to be stricter but smarter:
The previous version would "fail open", unknown nodes would be allowed
through hence f-strings not being flagged when they started appearing
in arg0 position, should now fail-closed, anything that's not allowed
is forbidden.
This flags a few more cases, all of which seem acceptable upon review.
However the previous version would also only resolve arg0 (in case it
had a `NAME`, to see if that resolved to an acceptable form of
query-building). The new version performs resolution during
`_check_concatenation` and should thus allow e.g. format strings to be
separate variables (though not e.g. module-level constants, yet
anyway).
In resolution, replace the ad-hoc process by astroid's built-in
`lookup` which seems to provide the same information. Slightly more in
fact, as it yields every assignment in case of e.g. conditionals, but
making use of that would require a lot more changes in the checker so
leaving the behaviour as-is for now.
It's important to *not* use `ilookup` here, because ilookup is not
"iterable" but "inferring", and we don't want values, we want
expression ASTs for analysis.
NOTE: previous improvements as well as fixes to existing code were
only implemented in 14.0, hence this being merged in 14.0 not 13.0
despite 13.0 still being supported.
closesodoo/odoo#81721
X-original-commit: 376ccf0944dae1bc53ae9c5385977c4e6b23e083
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Some data are formatted as a tree structure with a relation of parent.
We are adding meaning to the structure:
* This improves readability and allows to fold/unfold records in
editors.
* This could be done before using `eval`, but this allows to have an
xml_id for those records. It also allows to update the records without
having to rewrite on the parent x2many field.
Part-of: odoo/odoo#76675
Without the f-string literal the XML ID is not printed.
closesodoo/odoo#69419
X-original-commit: d0cbe52c111af923f0df5d0d231b164a150bf2db
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
A context is attached to the ValidationError object when elements in the
view arch are broken. This context helps to locate the error in the
source file. When the view processing fails outside of the arch
evaluation, such context is missing.
closesodoo/odoo#68157
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
When installing/upgrading a module with broken xml views, the module
installation fails with an error message that should help the developer
locate and correct the error.
Before this commit, a 3-level traceback was thrown at the developer:
1. The initial ValueError containing the original error message and some
view context information.
2. The noisy re-cast of the ValueError to a ValidationError with no
additionnal information.
3. An additionnal re-cast of the exception to add the original source
file path plus the entire XML source code that failed to be parsed.
We argue the error contains too much noise as developers are mostly
interrested in correcting their erronous tag of their view, they are not
interrested in `ir_ui_view` internals.
The new exception report is much less talkative, the two tracebacks from
`ir_ui_view` are logged at the `DEBUG` level. The new exception still
contains the original error message with some context on the view record
and the original source file path but it only show 5 lines of XML around
the erronous tag.
closesodoo/odoo#62757
Task: 2366612
Related: odoo/enterprise#15104
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
We provide a new helper class to help redact x2many commands for create
and write methods. To ensure best compatibility with the xmlrpc layer we
do not change the protocole, the commands are still 3-elements tuples
where the first element is still an integer in between 0 and 6. The
helper class provide the cannonical constants and static methods to ease
working with the commands. The new helper class is also available in QWeb.
Developers are encouraged to transition their code so it uses this new
helper class.
Task: 2366606
XML loading always raises a ParseError, however when an XML loading error is triggered from an HTTP request (e.g. a button) the final ParseError logged & shown to the user would not be properly chained to its ancestor, leading the original cause to be lost and issues being much harder to diagnose.
This cause is lost in _handle_exception where we duplicate the exception in order to chain it correctly, the __cause__ of the source exception was not properly copied over, and would thus break the chain.
The fix also requires explicitly chaining the ParseError to its cause, this should not be necessary but the cause is also lost if this is missing, it is not clear why.
opw-2381776
closesodoo/odoo#62117
X-original-commit: 650476812ee7d57f1d954be5557a3856448ffe5e
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
That's a not-very-useful subset of OdooTestResult, so:
* make results merge-able (aka add ability to update a result with the
contents of another)
* remove support for test data files, and transmission of the
assertion report thing through the data-files loading
* replace "legitimate" uses of assertion report by test result
* have run_unit_tests manipulate and return a result instead of weird
flags & ternaries
For clarity, some data files are formatted as pseudo-tree
structure. This is somewhat confusing and dangerous when the structure
has no meaning... so add meaning:
* allow nesting menuitems, nested items are set as children to the
parent they're nested in
* update schema to allow an icon *or* a parent on regular menu items,
and neither on nested (they have an implicit parent meaning can't
have an icon)
* remove attributes which don't actually exist from the menuitem
schema
* also type sequence as an integer while at it
Convert two large-ish menuitem data files to recursive form.
closesodoo/odoo#54564
Related: odoo/enterprise#11887
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
odoo/odoo#28519 removed large parts of pycompat, but left reraise
despite that not having much value.
Remove that helper and replace it by just a `raise` in most cases:
when raising from an except block, the old exception is automatically
chained to the new one, no need to mess around.
There is one exception: in http we have to re-raise an existing
exception explicitly (aka `raise exc` rather than just `raise).
This is less than ideal as Python *concatenates* stacks: the
previously reified stack (from the except clause) is stacked on top of
the new stack (from this raises), this leads to tracebacks "jumping
around" at the break point of the handler and is somewhat confusing.
So we want to use explicit chaining (`raise a from b`) with the
"source" providing the caught exception's original traceback and the
child providing the rest.
However since callers rely on the exception making sense, we need the
re-raised exception to be the original[0]. Copying the exception
doesn't work (see [0]), chaining an exception to itself doesn't
do anything useful, and while we could probably copy exceptions using
the pickle method[1] that's still risky.
So the most reliable option seems to be to create a new "cause"
exception, move the old traceback over to it, then re-raise the
original exception having cleared its traceback, chained to new the
cause.
[0] or a copy thereof but Odoo exceptions don't all work properly with
copy.copy and we don't want that to fail so not really an option,
we can't rely / bet on every new exception being cleanly copy-able
[1] create an "empty" instance using __new__ (or an instance of
something else onto which we re-set the __class__ in case the exctype
actually overrides __new__) then copy the __dict__
closesodoo/odoo#39709
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
*= website, website_livechat, website_rating
///// Tracking Product /////
Now when a user browse products in eCommerce, we keep track of the
products he looked at. We use the website_visitor
to store the products viewed. A cookie is added with a TTl of 30 min it
will prevent the RPC for that time. We track the page only if the
product view is tracked.
The recently viewed products are displayed as a snippet but also
with the customize option in product pages of website_sale.
Products that are in cart will not be returned as recently viewed.
It is possible to add a recently viewed product to the cart directly
from the carousel, it will not redirect to the cart. If we are on the
cart page, the product is displayed in the cart.
The Visitor page in website now references products viewed
///// Tracking Page /////
Feature to track a view was remove in: https://github.com/odoo/enterprise/pull/4834
That feature is now reintroduced and will use website_track instead of
leads to be stored.
The track field is now on the view instead of the page.
url field is added to website.track, it will store the url for pages and
views
The Visitor page in website now references urls viewed
Add some tests
task-1984575
closesodoo/odoo#35810
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Traceback generated when trying to pass a datetime object into a function tag
in xml.
<function name="action_name" model="model_name" eval="datetime.date.today"/>
Used to fail.
With this commit now one can pass time, datetime, timedelta, relativedelta,
version, ref, pytz in function tag in xml
Task-id: 1772614
Closesodoo/odoo#29212
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Dhaval Limbuwala <dli@odoo.com>
A long-standing issue with data files is that lxml (libxml2) has
trouble reporting useful errors, often going no further than "the file
is not valid" (libxml2 apparently has issues reporting useful errors
within non-trivial <choice>, which Odoo's data file schema makes
extensive use of) e.g. if a data file has some stray text in an
unexpected place (in this case, after a `</field>` tag in a
`<record>`), libxml2 will report:
ERROR:RELAXNGV:RELAXNG_ERR_EXTRACONTENT: Element odoo has extra content: data
Jing (the reference implementation) provides significantly better
error reporting:
error: text not allowed here; expected the element end-tag or element "field"
It's in java which is inconvenient and expensive for baseline
validation (and as a hard dependency), but there's now a "jingtrang"
package which bundles the relevant jars & invocation on
pypi (https://pypi.org/project/jingtrang/), making for a convenient
optional dependency for better development experience.
closesodoo/odoo#33666
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Task 1843603
* src_model is redundant with binding_model_id
* multi -> binding_view_types (if empty => all views) (maybe should be
empty by default yo?)
* in convert, type => rec.get(type) but no @type possible on <act_window>...
* removed deprecated auto_refresh & auto_search (not used anywhere (?))
closesodoo/odoo#24738
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
_tag_delete was not properly converted when the _tag_ calling
convention was modified in 4d581e26c2,
so <delete> tags would all blow up if encountered.
closesodoo/odoo#29149
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.
When installing/updating a module, verify existence of foreign records
before updating them. Also handle forcecreate=False records.
Also fix misprefixed XML id in sale_quotation_builder.
closesodoo/odoo#27659
* ir_set and url were accepted by the RNG despite ir_set having been
removed back in 2015 or so and <url> having possibly never existed in
the first place (could not find any reference to an <url> element
outside of sitemap qweb templates)
* <assert> was essentially deprecated/removed in 2015 with the v9
accounting having stopped running account_assert_test.xml, which was
the last file using the tag so far as I can tell. The file itself
remained as dead code until 2018
Denis Ledoux