Steps to reproduce:
-------------------
[A] Create an automated action with:
- Model: Tasks (project.task)
- Trigger: On save
- When updating: ID (to mimic "on_create" trigger)
- Execute code:
```py
record.message_post(body="This is a message from automated action (fields triggers: ['id'])")
```
[B] Create a server action (contextual action) with:
- Type: execute code
- Model: Tasks (project.task)
- code:
```py
record.write({})
```
[C] Test:
- create a new task --> message has been posted (OK)
- write some values on the task --> no message has been posted (OK)
- run the server action --> message has been posted (KO)
Issue:
------
No message should be posted as the ID field has not been modified.
Cause:
------
`if not self._context.get('old_values')` is considered as `True`
because we have an empty dict.
In fact, when we make a write on a record, old_values will be always a dict.
```py
old_values = {
old_vals.pop('id'): old_vals
for old_vals in (records.read(list(vals)) if vals else [])
}
```
Solution:
---------
Old values are not defined in the context during a create.
We can compare `self._context.get('old_values')` with `None`
to differentiate between creating and writing on records.
opw-3736068
closesodoo/odoo#155832
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Imagine the following situation: an automated action A is triggered when
some stored computed field F has a certain value. When a record is
created and no value is given for field F, then the automated action A
may be run twice: once when evaluating A's domain forces the computation
of F, and once again because A's domain is satisfied.
The implementation already uses context flags to reflect which automated
actions have already been run, in order to avoid automated actions to be
run recursively. The fix consists in enabling those context flags to be
shared among the evaluation of the domain and processing of the
automated actions.
opw-3731182
closesodoo/odoo#157272
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps:
- Create an automation rule with a model X
- Delete model X (need a way that keep the rule)
Actual result:
- Crash due to warning message
Expected result:
- Warning message is logged without issue
opw-3722953
closesodoo/odoo#153078
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
Create an automation rule for a field for which there's no onchange
yet. The rule type is "on_change" (on UI change).
This type of automation rule adds an onchange method on the
selected fields, which thus involve the onchange mecanism: the
"on_change" attribute will be set on that field nodes in views,
s.t. when the user changes it, onchange rpcs are done.
However, views are cached, and creating such a rule didn't clear
the cache. So if the view was already in cache, the rule seemed
not to work, because the client still received the old version of
the view, without the "on_change" attribute.
This commit clears the cache when such a rule is created, s.t.
after a client reload, the feature gets enabled as expected.
opw 3701125
closesodoo/odoo#152498
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
do not compare types, for exact checks use `is` / `is not`,
for instance checks use `isinstance()`Flake8(E721)
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Before the refactoring introduced at 0a744ac, it was possible to return
a warning from a `code`-type base automation with the `action` variable:
```py
if len(record.name) > 20:
action = {
"warning": {
"title": "Name too long",
"message": "The name of the record is too long",
}
}
```
This would trigger a visual dialog with the title and message in the
client.
Due to a louche `+=` operator change in the refacto, this kind of
automation raises a key error on the server, as the additive part of
the operator will try to access the 'warning' key in the result dict,
which may not (and usually will not) exist.
I assume this was done in an attempt to 'accumulate' warnings, but the
warnings in questions are dict that are not really additive anyway.
Better to support the *last* returned warning rather than none at all.
This commit basically returns to the previous situation for onchange
warnings.
closesodoo/odoo#148140
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Before this commit, and since [1], automated rules of type
"on_change" (i.e. on UI update) didn't run. This is because the wrong
field (trigger_field_ids) was used to record fields for which the
rule must be triggered. For that type of rule, the field to use is
on_change_field_ids. As a consequence, those rules were not
correctly created, and thus they didn't properly react to field
changes.
[1] odoo/odoo@8bdac7e26c
opw 3632084
opw 3595411
closesodoo/odoo#146780
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the sending webhook did not work well naturally
with the receiving end.
After this commit, it does since default values on base_automation have been adapted.
closesodoo/odoo#142710
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Set a webhook that executes a ir.actions.server of type python code.
Before this commit, the code had no access to any request's parameters. This was a limitation
in the basic flows that the feature is supposed to support.
After this commit, we pass in the context a key "payload" that contains a copy of the request parameters.
task-id-3599629
Part-of: odoo/odoo#142710
Before this commit:
If you select more than one trigger field on base.automation:
File "/home/odoo/src/odoo/17.0/addons/base_automation/models/base_automation.py", line 302, in _compute_trg_field_ref__model_and_display_names
relation = automation.trigger_field_ids.relation
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1146, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 5819, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: ir.model.fields(<NewId origin=3241>, <NewId origin=3238>)
After this commit:
trg_field_ref_model_name and trg_field_ref_display_name are only used for the
base_automation_trigger_reference widget, which is only used when trigger in
['on_stage_set', 'on_tag_set']. We only need to compute them in this case,
and there will be no errors since they use only one trigger field.
opw-3607314
closesodoo/odoo#144810
Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>
The issue is not easy to reproduce, so the fix is not a guaranteed one.
Estimation: the click on the "send message" buttons happens too early,
and it is either doing nothing, or being immediately reset by another
action that happens at page load.
Adding a little bit of extra delay (in particular waiting for messages
to be loaded) might resolve the issue.
Also back-port code allowing to use contains in tours.
runbot-27847
closesodoo/odoo#144435
X-original-commit: 3b261b6856e935f8fe9d4e23cfddc09df8ff7fdf
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, the ir.cron "Automation Rules: check and execute" crashed
because the "_check" method used get_eval_context where it shouldn't
This is due to b846d1ebe9, which makes _get_eval_context a record's
method, not a model one.
closesodoo/odoo#140153
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Since server actions names are computed automatically when (and only
when) they are linked to an automation, not having a dependency at all
between `sms` and `base_automation` meant that we would have either needed
a link module or an ugly `_fields` introspection to correctly name server
actions that send SMSes created through automation rules.
Since `sms` is a rather basic module which has very little impact on the
UI and no impact on pricing, it makes sense to add it to the list of
dependencies of base_automation instead, similarly to `mail`.
Task-3450200
closesodoo/odoo#138804
Related: odoo/enterprise#48987
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Changes to the UX of boolean field updates via server actions
required some adaptations of the views of base_automation.
Task-3450200
Part-of: odoo/odoo#138804
The goal of this commit is to make it simpler for users to match an
incoming Odoo webhook automation rules with an outgoing webhook action
from another Odoo by having a default record_getter that uses the same
syntax as the default payload of a webhook action.
Task-3450200
Part-of: odoo/odoo#138804
Thomas Lefebvre (thle)