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
Frédéric Garbely
Christophe Simonis
Odoo Translation Bot
Jeremy Kersten
Martin Trigaux
Denis Ledoux
Raphael Collet
Lionel Sausin
Xavier Morel
Olivier Dony
Nicolas Lempereur
qsm-odoo
Jesús Alan Ramos Rodríguez
Goffin Simon
Carlos Almeida