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
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
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
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