The dates of an event on the website was always
within the user timezone. If not signed in,
it was within the public user timezone
(which is quite not user-friendly to change)
For this purpose, we weed get the context
from the record (the context used when using
`record.with_context`), and therefore
the QWeb field
`ir.qweb.field.datetime` is slightly altered,
to use the context from the record.
opw-675427
In version 3, process.memory_info() returns only rss and vms
In version 4, it now returns rss, vms, shared, text, lib, data and dirty
Automatic unpacking is no longer possible in 4.0
Fixes#11052, Closes#11459
Users may sometimes need to edit their own partner records directly,
although indirect access by writing on `res.users` directly works
fine in most cases.
Could not edit t-field content if modified by inherit xpath,
and could not inherit qweb views with non "xpath" nodes with
`position="attributes"`.
Examples:
Can't edit: `<data><xpath expr="div[@t-field='object.test']"
position="replace"><div t-field="object.test"/></xpath></data>`
Inherit doesn't work: `<data><h1 position="replace"/><h1
class="test">tata</h1></data>`
Closes#11561Closes#11547
As its documentation notes[0], Jinja2 only processes unicode template
data (or pure ASCII, which will implicitly decode to unicode).
The scaffolding system would read raw scaffolding data in memory (both
templates and passthrough non-templates), but fail to decode templates
before handing them to Jinja, blowing rendering up if templates
contained non-ascii.
Fix#11331 by always decoding templates from UTF8 before handing them
to jinja. This is backwards-compatible, ascii templates work as they
used to, non-ascii UTF8 templates now work correctly, non-ascii
non-UTF8 templates what are you doing?
[0] http://jinja.pocoo.org/docs/dev/api/#unicode
To reproduce the bug:
- Create a partner.
- Set it state "Alaska".
- Country becomes "United States".
- Set a country for YourCompany, such as Spain.
- Create a partner.
- Set it state "Alaska".
- Country remains blank.
Also, `node.xpath("//field")` was running over every `<field>` in the
view, not just those inside the `<div class="address_format">`. Now it
only traverses the right nodes, which renders every affected view
faster.
The ir.actions.todo record base.open_menu is used to redirect the user
to a menu after installing a module.
To do so, a new module override the record changing its action (toward a
menu) and setting its state to "open".
But with f7fe753 when one such changed action is removed after
uninstalling a module (or removing the action by any other way) the
base.open_menu would also be removed. Thus thereafter the open_menu will
not work anymore (since type "automatic" is lost).
With this commit, when whenever base.open_menu is removed, instead its
action will be replaced by base.action_client_base_menu which is the
original action.
closes#11224
related to: #11216, opw-660269
In the case of a `raw_data` export, a boolean which has the value
`False` will not be exported correctly.
The fix handles the `False` value as a valid value for a field.
opw-666142
Specifically, when one API implementation calls the other one, it has to call
the method *from the same class*. Otherwise, overriding the method may result
in an infinite recursion. Consider:
class A(Model):
_name = 'stuff'
@api.v8
def foo(self):
return 42
@api.v7
def foo(self, cr, uid, context=None):
return self.browse(cr, uid, [], context).foo()
class B(Model):
_inherit = 'stuff'
def foo(self, cr, uid, context=None):
return super(B, self).foo(cr, uid, context=context) + 1
and now call: `env['stuff'].foo()`. This invokes `B.foo` (new-API), which
calls `B.foo` (old-API), which calls `A.foo` (old-API), which calls `B.foo`
(new-API) instead of `A.foo`!
This issue would not be present if old-API `A.foo` was defined as:
@api.v7
def foo(self, cr, uid, context=None):
return A.foo(self.browse(cr, uid, [], context))
When generating SQL queries, `column._symbol_c` must be used as placeholder as
for the method 'set' of the column itself. Otherwise it is not possible to
define specialized columns.
This is related to revision 80b373f.
The above revision leads to the inability
to import new records without any `xml_id` set
Technically speaking, this is because
you cannot concatenate `False` with `'_'`, in
`xml_id + '_'`
opw-668962
The result of searching on a o2m field for a missing ID was
the whole set of records which do not have any lines in the
o2m fields. This is definitely not the desired behavior,
and could lead to disatrous performance, because the
returned set could be extremely large.
One example of such behavior is for recomputing fields
in the env cache in 8.0+. When a o2m line gets deleted,
it triggers the recompute of any dependent fields.
In order to locate the records to recompute, the ORM
searches for the 'parent' records in the comodel table.
When this operation is done by 2 users concurrently
the o2m line may not exist anymore, and the bug
is triggered: dependent fields are recomputed on a possibly
very large set of records that did not need any recompute!
The recursion was based on an incorrect assumption: the cache of the target
environment is initially empty. If another computation left some value there,
the copying is incomplete, and that causes bugs in onchanges.
While the signature makes sense in an old API context (sort-of) it's
very easy to misuse in a new API context as one'd expect `has_group` to
use the subject (recordset), not the user in the environment, compounded
by ``env.user`` being browsed as administrator, resulting in the
"obvious" ``env.user.has_group(foo)`` checking if the
administrator (rather than the current user) has the specified group.
Adds a divergent v8 version of has_group which first checks if it's
called on a non-empty recordset, and in that case use the recordset id,
otherwise fallback on the context user (to handle new API conversions
which used the "correct" call convention rather than the obvious one).
fixes#9649
When writing on a recordset with duplicates, the ORM raises a `MissingError`
because the rowcount gives a difference with the injected ids. The fix simply
eliminates duplicates from ids.
When a record is exported, an external ID, in the form of __export__.<model>_<id>
is created on this record.
When the translations are generated (e.g. "synchronise terms" wizard), the
translations may be duplicated for records that have been exported. If a
translation is submitted before the export (when the record had no external ID
yet), a new empty translation is created as the module differs in the import.
Creating a new translation may be a problem as the new term (equal to the source
term) will be used as the translation value.
Fixes 9480
According to PEP302, the signature of `Finder.find_module` should be
`find_module(fullname, path=None)`.
Ever since it was introduced in 64ec5f36df the addons import hook
defines the second parameter as mandatory, which is an issue for
systems relying on the specified behaviour (and not needing to
provide a path) like the stdlib's `pkgutil.find_loader`.
fixes#10670
Borrowing a cursor each time you access `field.digits` may be costly, because
of the connection reset. Moreover, in most cases, the cursor is not used at
all, since the decimal precision are kept in cache.
For the installation of module `product` with its demo data, the number of
cursor allocations was reduced from ~1500 to about 50!
Traversing new records in a different cache requires that all new records on
the path are copied across caches. Make the copy across caches recursive when
the first record on the path is a new record.
or in @onchange for that matter. They should already generate a warning,
but only the first time they're used.
This is done lazily because it introspects the instance/class which can
be costly when performed during the repeated setup of registry setup.
closes#5595
The keep_query() function has to **keep** all or selected query parameters
or add new ones but not change them by merging those with the same name.
That unnecessary parameter merge breaks the *Change language* feature in the
website_sale module when *Website -> Customize -> Product Attribute's filters*
is enabled and there's 2 or more select type attributes created and at least
one of them is selected.
Merging params was added in:
* 8.0: commit 7759af7c4c
* 9.0: commit daf8bdf688
When inheriting from a view in extension mode created in the same module, this
view was not loaded during check_xml of the last view.
This caused an error when the last view wants to modify elements added
by its direct parent view.
Example :
- View1, created in module "account"
- View2, mode extension, created in module "customer", inherits View1
- View3, created in module "customer", inherits View2
During update of module "customer", when loading View3, the check_xml
call didn't load View2, because it's defined in the same module (and,
obviously, this module has not be totally loaded at this point)
This is fixed by adding direct parent of each loaded view in the
check_view_ids list in context, to force them to be loaded.
Closes#9135
user_has_groups is used to check for groups in e.g. view attributes (`@groups`).
When trying to format lists of groups in views, it would break down as it would
pass e.g. `\n some.group` to `res.users.has_group`, which would look for
an xid with the module `\n some` and (oddly enough) not find it.
Theoretically could also handle that inside res.users.has_group but it seems
ever-so-slightly more risky, and has_group is only used programmatically and
should thus already be called correctly.
fixes#9797
According to the RFC1034
https://tools.ietf.org/html/rfc1034
A TLD can use up to 63 octets.
The regex checking that an email address is valid
should there allow emails using a TLD with such a length.
Besides, the use of TLD domains exceeding 6 characters is more
and more common, nowadays.
e.g. using a domain `.amsterdam`
opw-660014
Description: When updating the product module, if the "Service"
product.product has been deleted, but not the corresponding
"product.template" part, the update will crash on a "duplicate xml id"
error.
This commit fixes the bug by :
- Adding the link to existing inherited model xml id in values
- Avoid creating the duplicated XML ID
If the XML ID is found, but orphan, it's simply deleted.
Closes#8966
opw-658454
When sending a mail.mail with email_to, the processing split the email_to into
a list of addresses. However if the found addresses use the form name <email>
the name if lost in the process. A new email_split_and_format method is introduced
in tools and used to avoid loosing that information.
Once set for the loading of terms for a lang,
the flag `overwrite` was propagated to all
other following languages, even if not actually needed.
Use case:
- Installed languages: en_US, de, fr_CH, it
- Update of the `sale` module
- In `load_module_terms`, the system iterates through the languages:
1. en_US: No problem
2. de: No problem
3. fr_CH: The flag `overwrite` is set to `True`,
because the sub-language `fr_CH` should overwrite the `fr` terms
4. it: The flag is still set to `True`, because of the previous iteration,
while it must not.
opw-654042
When a new column has been added after that some data already exists,
the old lines will keep an empty/null value. So when we search is the new field
is equals to False or if it is different of True, we need to match the null
values.
Backport of de3b64018a
When a new column has been added after that some data already exists,
the old lines will keep an empty/null value. So when we search is the new field
is equals to False or if it is different of True, we need to match the null
values.
close#9925
When creating translations (click on blue flag) of a duplicated record, it used
to have the module information of the duplicated record.
It is also not useful to check the module when trying to find if a translation
exists on this record as the res_id is present in the query.
Fixes#9480
When a translated term is modified (e.g. content of an email.template),
reloading the translations of the module (e.g. when updating the module) used to
recreate a new, duplicare translation for the modified term (instead of ignoring
the existing one).
This was due to the fact the matching expression (find_expr), when loading
translations, used the field 'src' (source term) as criteria for (almost) all
ir.translation records.
While this is true for type 'code' or 'selection', this is not true for 'model'
where the source content may have been changed.
In case of translation of type 'model', matching on the name and res_id should be
enough for the matching expression and then, avoid creating duplicated
translations.
Note: this patch must NOT be present in 9.0 due to the xml_translate
attribute that splits an xml content into small parts.
opw 654031
When creating missing translations on an object (e.g. using blue flag icon on a
field), the value of the module was not set.
This was problematic as could create a duplicated translation when the module
was updated or the translation reloaded (as the module is used in find_expr).
opw 654036
This revision back-ports revisions
983d5eb9fa
&
ccbb8e09a6
regarding this signature regex.
Besides, it adds the fact the dashes have to
be at the beginning of the line
to make them detected as a signature.
opw-655834
res.users form contains virtual fields in_group_ID to be added in res.groups.
Groups with boolean share=True (added by share module) must not be displayed in
the form and should not be modifiable through the user interface.
However, if a module adding/modifying a res.group is earlier in the dependency
graph than 'share' (e.g. only depends from 'base'), the update of the user view
is done before share is loaded and the overrride of 'get_application_groups' is
never executed.
As we can not guarantee that the module is share loaded, put the logic of
hidding the module in base instead of share.
This workaround is quite hacky but is necessary in stable version.
Better fix in 9.0 at cf63d4d
Fixes#6324Fixes#5820
This revision is related to 1b8c9aed9f
As `manual` is now the default value of the `state`,
if `state` is not given in the values when passed to
`create` or `write` of `ir.model` and `ir.model.fields`,
we must assume the value is `manual`, so the columns and tables
are instanciated in database
opw-657750
This was possible to create custom fields `x_*`
but seen as base fields.
For instance,
- Go to Settings > Technical > Database Structure > Fields
- Select a field (any)
- Click on the model link, to be redirected to the model form
- Edit & add a custom field from there.
- Save
- Notice that the field you just added is saved as a base field.
We solve this issue by assuming that all created fields and models
are customs, except the ones created by the ORM, by the database
initialization, the fields coming from the modules in python.
We therefore remove the mechanism on which a field was set
as custom according to the fact `manual` was set to True within
the context: This is now the case by default.
No change was required for the base fields: The `state` `base`
was already forced for those fields, that are created using
direct SQL requests `INSERT INTO`.
opw-657312
As atexit function are inherited by subprocess, the pidfile was always
deleted when the first worker (http or cron) died. Now, only the
process that created the pidfile will delete it.
Add the possibility in the decorator to specify the `upgrade` and `downgrade`
functions that convert values between APIs. Both function have the same API:
upgrade(self, value, *args, **kwargs)
downgrade(self, value, *args, **kwargs)
The arguments ``self``, ``*args`` and ``**kwargs`` are the ones passed to the
method, following its new-API signature.
Fixes#4944, #7830.
The attribute `data-oe-*` (`data-oe-id`, `data-oe-model`, ...)
must not be added when rendering the assets, to avoid
having different assets content,
e.g. a different content for the assets_common,
according if the user is signed in or not,
if the user can edit the website or not.
A different content for an assets according to the
users rights or the user being signed in or not means
that the assets are permanently re-written in the filestore,
which is against the point of the assets.
The content of the assets (assets_common) must not be
different from time to time, it must always be the same
(except when installing a new module, obviously).
Adding the `data-oe` attributes was pointless for the assets
anyway, and prevented having an identical content all
the time, therefore rewritting the assets all the time
in the filestore.
opw-657046
The current code when applying negative operator on an expression used
recursion which in extreme case is not best friend with python.
e.g: on instance with a lot of wharehouse, some simple action could lead
to a domain with lot of elements which could easiliy go over the python
maximum recursion limit.
This commit fixes this by replacing recursion with iteration.
We have a stack of negation flags and loop on each token of the domain
as follow :
- when we iterate on a leaf, it consumes the top negation flag,
- after a '!' operator, the top token negation is inversed,
- after an '&' or '|' operator, the top negation flag is duplicated on
the top of the stack.
closes#9433
opw-653802
In the `product.template` model,
when searching products within a category that doesn't exist,
all products were returned, while none should be returned.
For instance,
In Sales > Products,
In the search input, search with internal category:
"A category that doesn't exist",
all products were returned.
opw-649548
When making on model A a read_group with groupby equal to a many2one field F1 to a model B
which is ordered by a inherited not stored field F2, the group containing all the
records from A with F1 not set was not returned.
Example:
model A= "hr.applicant"
model B= "res.users" (_order = "name,login")
inherited model= "res.partner"
field F1= "user_id"(to "res.users)
field F2= "name"(inherited from "res.partner")
In this example, the query generated by the function "read_group" was:
SELECT min(hr_applicant.id) AS id, count(hr_applicant.id) AS user_id_count , "hr_applicant"."user_id" as "user_id"
FROM "hr_applicant" LEFT JOIN "res_users" as "hr_applicant__user_id" ON ("hr_applicant"."user_id" = "hr_applicant__user_id"."id"),"res_partner" as "hr_applicant__user_id__partner_id"
WHERE ("hr_applicant"."active" = true) AND ("hr_applicant__user_id"."partner_id" = "hr_applicant__user_id__partner_id"."id")
GROUP BY "hr_applicant"."user_id","hr_applicant__user_id__partner_id"."name","hr_applicant__user_id"."login"
ORDER BY "hr_applicant__user_id__partner_id"."name" ,"hr_applicant__user_id"."login"
which always returned "hr.applicant" groups of records with a "user_id" set due to the inner join maked on res_partners.
This inner join on "res_partner" is coming from function "add_join" calling by "_inherits_join_add"
in _generate_order_by_inner.
Introduced by dac52e344c
opw:651949
In some complex use case of a workflow instance with several workitems,
a given workitem processing could itself somewhat recursively process
one of the following workitems.
This situation was currently not taken into account, so in that given
case, the already processed workitems would be processed again.
opw-647580
This reverts commit bd9cbdfc41.
The above revision solved the SQL constraints not being
translated when raised. They were not translated because
the context, containing the lang, was not located as expected
in the `kwargs` dict.
While it solved this issue, it had as side-effect to raise
`current transaction is aborted,
commands ignored until end of transaction block` errors more
often when using the web client.
This can be explained by the double check, when the first
check raised this error
- which can happen, e.g. when the cursor is closed,
there is a retry mechanism in such cases -
and by the fact the transaction was not rollbacked.
This issue could have been solved as well by rollbacking
the transaction, but it is regarded as not-so-clean.
Therefore, to solve this issue, while still having
the SQL constraints translated, we apply the
second patch proposed in bd9cbdfc41
commit message, which is not-so-clean as well, but
which is a proper solution.
opw-651393
Avoid "patching" the registry, as this introduces inconsistencies (some field
attributes are lost). Instead, proceed as follows:
- update the definition of custom fields in database;
- clear the corresponding cache on the registry (this was missing);
- setup the models in registry (this reloads the custom models and fields);
- update the database schema of the models based on the registry.
This makes the update of custom fields simpler and more robust.
In case of different directory for stroing po and pot files than 'i18n'
(e.g. 'i18n_extra'), a po could be linked to a wrong pot file.
Use the same folder as the po file to look for pot.
Closes#4323
If multiple warnings were returned by a cascading onchange
call, only the last warning was displayed.
This revision concatenates the warnings in such a case.
opw-649275
The "Synchronise translation" wizard almost doubles the number of translated
terms in database.
This is due to the loss of the module reference at the synchronisation
(`module_name` is empty as updating all modules)
Only overwrite the module when it is set (default None)
Fixes#6149
Second part of the patches avoid inserting translations without any module for
locale xml ids.
If an error happens in an overload of setUp, the already-open cursor
is likely not to get properly released before the next test,
deadlocking the db, because tearDown only runs if setUp has
succesfully completed.
Cleanups were added specifically to run every time, after tearDown has
(potentially) been executed.
closes#8327
Note: cleanups run in LIFO order (as they should).
In 5efac22043 and
1cf5723835 the computation
of the decimal precision of float fields was modified to
reuse a random cursor from the request environments.
Environment.envs is a WeakSet, subject to unpredictable
garbage collections.
This could cause hard-to-diagnose problems by executing
a SELECT query in a cursor that is supposed to be
otherwise idle and untouched.
As an example, this could cause a transaction start in a
cursor that was just committed/rolled back,
and was waiting for another operation to complete.
One such case happened semi-randomly during a module
installation triggered from the web client, where the request
cursor is committed and waiting for the registry
initialization done with a different cursor,
in the middle of _button_immediate_function()
After the registry initialization, the request cursor is
used again to determine the next action (ir.actions.todo),
and this could cause a TransactionRollbackError if the
request cursor was used during the initialization.
Using a new cursor every time is much safer, simpler,
and will not cause any significant performance hit,
because it will usually grab an available connection
from the connection pool, rather than create a new one.
Fixes opw-649151
Denis Ledoux
Stephen Medina
Olivier Dony
Odoo Translation Bot
Alexandre Fayolle
Christophe Matthieu
xmo-odoo
Jairo Llopis
Nicolas Lempereur
Nicolas Martinelli
Raphael Collet
Laurent Mignon
Cedric Snauwaert
Xavier Morel
Goffin Simon
Martin Trigaux
Yuriy A. Apollov
Holger Brunn
Sathors
Eric Antones
Jeremy Kersten
Sylvain GARANCHER
Thibault Delavallée
andreparames
Frédéric Garbely
Christophe Simonis
Lionel Sausin
qsm-odoo
Jesús Alan Ramos Rodríguez
Carlos Almeida
Leonardo Rochael Almeida
Ronald Portier (Therp BV)
dufresnedavid