This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Purpose
=======
Fields `customer` and `supplier` on `res.partner`
are mostly used in domains of many2x fields.
Those domains can confuse end users because they don't
see the partner they are looking for; and it's not obvious why.
Some identified problems:
1. It can lead to duplicated partners: the user does not find
the partner, so he creates a new one.
2. The user imports supplier contacts in the Contacts app, so they
don't get the `supplier` flag. Then the user wants to make a purchase order,
and cannot find the new suppliers in the list
3. A user removes the customer flag on a prospect, because they don't think
it's a customer yet - except now they can't make a quote for that customer...
Specification
=============
Remove the two mentioned fields.
Since fields `customer` and `supplier` have been removed, all partners
are now shown in many2one dropdowns.
But in some cases, not all partners are relevant or some are more likely
to be relevant than others. e.g. when creating a PO, top suppliers have a
higher priority than other partners.
So, adapt the places where those fields were used with the new mechanism to
display the searched the partners, according to the number purchase/sales
orders they made.
TaskID: 2031147
Co-authored-by: Yannick Tivisse <yti@odoo.com>
When users create an automated action to trigger when a record is updated,
they assume each update is 'atomic' in some sense.
It is not the case, as one write may trigger many write, some in recompute.
As a result, any update may trigger a dozen actions (or more).
We add a field wich allows us to specify which field we want to watch.
For instance, you could select the field 'state on quotation',
and thus only action would be triggered on confirming the quotation.
The link_field_id is a field that allows to link a record of the source model
to a new record of the target model, through a many2one.
However many target records can be created, so every one of them
(except the last) ends up orphan.
We allow for one2many and many2many fields to be used,
and in these cases we add the newly created record to the list.
opw 1910671
Together d60f2ab0e2 and
24ca67b545
corrected the triggering of automated actions at *each* recompute of a field
It is problematic since, maybe, the field that should trigger an action
*is* a computed one. It often happens with "state"-like fields
This commit aims at applying the logic of those two commits,
except in the case we do want the action to be triggered
even in a recompute case
OPW 1935727
closesodoo/odoo#31422
Signed-off-by: "Lucas Perais (lpe)" <lpe@odoo.com>
bad ux: it's difficult to understand why there is two way to do the
same thing. (4 fields for domains, instead of 2)
Example of confusion:
What happens if you set both a filter and a domain?
What happens if you change the filter? does it change the
automation?
The new domain widget is good enough. We don't need such extra fields.
Purpose of this commit is to continue to clean server actions, scheduled
actions and automated actions. Server actions hold code execution and
automated actions hold triggers and conditions.
This commit make automated action inherits from ir_actions_server.
Automated actions do not hold several server actions anymore. Instead
each new automated action creates its own server action holding the code
or actions to perform. Automated actions that held several server actions
should now simply use a server action of type multi. This commit also
features:
* rename 'kind' field to trigger
* remove 'act_user_id' as this should be done by the server action itself
not the automated action. This can be achieved using a write or code
server action;
* remove 'act_followers' as this is replaced by a followers server action;
* use a primary form view inherited from server action. This way automated
actions use the same base form as server actions with triggers and
conditions added;
Thanks to @fpodoo for the original idea and preliminary work. Thanks to
@jpr-odoo for first developments. Thanks to @jem-odoo and @rco-odoo
for reviewing.
First step towards cleaning and improving automated actions is to
correctly name things. base_action_rule module is therefore renamed
to base_automation. Model is also renamed to base.automation.
Yannick Tivisse