Commit Graph
8 Commits
Author SHA1 Message Date
Christophe Simonis 44515bc7be [MERGE] forward port branch saas-12.2 up to c9f832d9f0
closes odoo/odoo#31790

Signed-off-by: Christophe Simonis <chs@odoo.com>
2019-03-13 14:24:51 +00:00
Nans Lefebvre ee775c7548 [IMP] base: add to automated actions the fields to watch during update
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
2019-02-15 12:37:25 +00:00
Lucas Perais (lpe) 12df5a9325 [FIX] base_automation, mail: automated action on computed fields
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

closes odoo/odoo#31422

Signed-off-by: "Lucas Perais (lpe)" <lpe@odoo.com>
2019-02-27 13:55:49 +00:00
Christophe Simonis 2df5faa551 [MERGE] forward port branch saas-14 up to 2f68e9e93a 2017-03-28 18:05:31 +02:00
Christophe Simonis 2f68e9e93a [MERGE] forward port branch 10.0 up to 72fa3e8bda 2017-03-28 17:27:19 +02:00
Fabien Pinckaers cbb7c2442a [IMP] base_automation: removing domains based on filters in automation
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.
2017-02-10 14:10:27 -08:00
Yannick Tivisse aedde9a46c [REF] base_automation: cleaning and refactoring
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.
2017-01-03 19:11:08 +01:00
Yannick Tivisse 319a939339 [MOV] base_action_rule: rename and move base_action_rule to base_automation
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.
2017-01-03 19:11:07 +01:00