Client issue: when updating the company of a contact, the Display Name
keeps using the previous company's name, so given Bob in company A, if
Bob is moved to company B the form's title remains "A, Bob" instead of
becoming "B, Bob". More annoying, if Bob is moved back to A the name
becomes "B, Bob".
On res.partner, `display_name` is a stored computed field which
depends on `commercial_company_name` (via `name_get` -> `_get_name` ->
`_get_contact_name`). This is an other stored computed name, which
depends on `commercial_partner_id`, which is yet another stored
computed name, which depends on the `parent_id`.
The dependencies are meh but usually resolve fine, the issue occurs
when a base.automation rule is created with a non-empty
domain (including an empty literal list, which was the case here):
when the first field of the sequence is computed, base.automation's
`_compute_field_value` is called. This calls `_filter_pre`,
which (because `filter_pre_domain` is non-empty) calls `search` on the
model.
This would normally be innocuous as `search` will only flush the
fields used in the search, however for `res.partner` the default
`_order` is... `display_name`. Meaning we flush that computation,
forcing the computation of `commercial_company_name`, but since
`commercial_partner_id` is being computed we reuse its old value (or
something), which is not re-recomputed after the
`commercial_partner_id` computation ends.
So rather than resolve a full search involving an order, filter the
records in-place.
OPW-2427264
closesodoo/odoo#67987
X-original-commit: 221ea6079b2beeb66c4cfa48b237791e1b380c5e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If we change ``active_model`` in context, we have to reset active_id(s),
otherwise we read a random records which may not exist.
STEPS:
1. Activate Developer mode
2. Go to Settings > Technical > Automation > Automated Actions
3. Define a new Automated Action with the following settings:
- Model: Lead/Opportunity
- Action To Do: Execute Python Code
- Trigger: Based on Form Modification
- Trigger Fields: Customer (crm.lead)
- Python Code:
```
raise Warning(records)
```
4. Go to Contacts, create a new contact and save it.
5. Click on the "Opportunities" Smart Button on the top left of the contact record.
6. Click "Create".
BEFORE: ``records`` in context read crm.lead, while id is for res.partner
record
AFTER: ``records`` is None
---
opw-2424392
closesodoo/odoo#64421
X-original-commit: 6fd6d68ee6eee6460ffda8b7dd691c0ef93b7a30
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Create a automated action on deletion that send an email, delete a
related record. The email is not sent.
Email are linked to their chatter message, when the later is deleted the
former is deleted in cascade too. This is a known limitation of the mail
model.
closesodoo/odoo#62616
Task: 2151519
X-original-commit: f8904eb19d82d1d255c1ef091d1e47e0e016a62f
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Steps to reproduce the bug:
1.Create an automated action with the following:
- Model: Task (project.task)
- Active: True
- Trigger: On Update
- Action To Do: Create Next Activity
2. Open or create a task in Project module
3. Edit
4. Change or set customer (partner_id)
Bug:
An error message was raised.
opw:2376492
closesodoo/odoo#61812
X-original-commit: b3415d9dd0bcc1053e47b8a0082c772ca4a8220f
Related: odoo/enterprise#14772
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The user executing an action triggering an base automation may not
have access to the base.automation record itself (regular employee or
portal)
Added test test_on_create_restricted failed before this patch as the
portal does not have the rights to read the base.automation record
Fixesodoo/odoo#59680
X-original-commit: 33a7142f298eeda7808d6d07e80231836442a0ce
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Installing base_automation module the methods: create, write, unlink and compute_field
are patched.
So, they will be used for all models.
It is important to save resources as possible.
The patched methods in base.automation read the original data
before to change so run all base.automation records.
But What about if there are not base.automation records?
So, we can save an extra read for all models
The same to pre-filter and post-filter
It adds a return early in order to skip this extra task when it will be useless.
closesodoo/odoo#52134
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If there is cron worker timeout logger error, there is a log for the
last cron running
If a "Base Action Rule: check and execute" fails, we need to know what
is the last base automated action based on-time running
This logger helps to looked for it
closesodoo/odoo#50493
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
If some filter domains use M2O to models current user cannot access,
using sudo() permit to filter even when user cannot access linked
models.
for the accuracy of the fix, add a unit test which reproduce the exact
reported bug.
closesodoo/odoo#44923
X-original-commit: 30e2153539643491fad889811a54a8e580fa9c58
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
If an automated action raises an exception, in the traceback modal:
- For admins, display Disable & Edit automated action buttons
to be able to directly know with wihch automated action the error occurred,
and to give the possibility to edit or disable it quickly,
- For regular users, just add a paragraph to tell with which automated action the error occurred,
so they can give this useful information to their administrator
This is specially useful for databases which have just been
upgraded to a newer version, and for which the server action
is failing because its code is no longer supported.
closesodoo/odoo#44513
X-original-commit: 8f3940c132bbbc99e47fa3f0cba0e768159d9af2
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The current 'Base Action Rule: check and execute' CRON search every
four hours for delayed actions to run. This mean, any action scheduled
later can be delayed up to four hours.
We now dynamically reset the CRON frequency according to the least
delayed automated action to minimize the potential gap.
closesodoo/odoo#40633
Task: 1998809
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Below points are improved in automated action
- Set no_create on model_id, crud_model_id, partner_ids, and channel_ids
- Set widget many2many tags and change string for trigger_field_ids
- Rename 'Trigger Condition' to 'Trigger'
- Change on_change_fields into a many2many to ir.model.fields
- Set 'Hours' as default of field trg_date_range_time
- Rename label of crud_model_id to 'Target Model'
- Rename label of sms_mass_keep_log to 'Log as Note'
- On creation of template set the default model
- Hide the 'Security' tab
- Set no_create on fields resource_ref and col1
- Make 'value' readonly when col1 is not set
- Rename 'Link using field' to 'Link Field'
Task-2082503
closes odoo/odoo#39622
Closes: #39622
Related: odoo/enterprise#6515
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The issue is the following: if both fields F1 and F2 are computed by the
same compute method, actions based on changes on F1 may not be triggered
when F2 forces their recomputation. This is caused by the API of the
method `_compute_field_value` that takes as parameter the field that
triggered the recomputation. The method must consider all the fields
computed by the method.
closesodoo/odoo#39440
X-original-commit: ceddb710a17e552061b9ad3cbc2647d7eae6567d
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The reloading of the registry causes cache misses when creating or
modifying automated actions via Odoo Studio. Right after the reloading
happened, some field is computed in an environment `env` that no longer
appears in `Environment.envs` (collecting existing environments),
because the latter has been explicitly reset. Performing `sudo()` or
`with_context()` in the compute method creates a new environment that
appears in `Environment.envs`, and uses a different cache from `env`.
The recomputed field is thus stored in the other cache, and retrieving
its value from `env` issues a cache miss...
The fix consists in re-patching the registry models without reloading
the registry from scratch.
opw:2082497
closesodoo/odoo#39342
X-original-commit: c99ad25d4c6affeed75b40e8bc8eeffe87873e48
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, automations triggering on new records caused onchanges to break out-of-context record rules, hence preventing to create the record.
This commit filters out new records from the list of records matched by the domain of an automation.
task-1998636
closesodoo/odoo#37360
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Co-authored-by: Raphaël Collet <rco@odoo.com>
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>
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
vals may be an empty dict
This may happen a write is done on a computed field, the call to _write will
be empty (still needed to update write_uid/date).
Before this commit, all fields were read in the read call.
This was unecessary and may produce acess-rights errors or other side effect
(e.g. in odoo/enterprise#3778 the technical field ticket_count was read, even
if not present in the view or the write call)
Only compute old_values on the fields that are modified
Fixesodoo/enterprise#3778
opw-1949911
closesodoo/odoo#31737
Signed-off-by: Raphael Collet (rco) <rco@openerp.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
The original issue is described in #29528, and the commit was reverted
in eb19016ba3.
The root cause of the issue was that the module `base.automation`
performs a `commit()` in `_update_registry`, which is called during a
`create`. This conflicts with the `savepoint` created in `load_demo`.
We postpone the registry reload after installing the demo data. Note
that we only do this in `base_automation`, to limit the potential side
effects.
opw-1920636
Co-authored-by: Raphael Collet <rco@odoo.com>
closesodoo/odoo#29863
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>
When used on a large db with lots of records to process, `last_run`
date that was written on the base.automation could be a few seconds
later than `now` that was used to check whether to run the automated
action. This caused some small time frames to be never checked, and some
records to be missed. We fix this by using exactly the same timestamp.
opw-766182
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
Purpose
=======
Some field labels are not very explicit
Specification
=============
- Rename "Base Model" into "Model"
- Change "Trigger condition" (Condition Frist char(C) uppercase)
- Rename Domain into Apply on
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
Problem: the update of custom models/fields is not fully transactional, and may
potentially lead to an inconsistent database. An other problem is creating two
custom fields by writing on a model: if the second one fails, the first one has
been committed without notice. Retrying the request will give an unexpected
error (duplicate field name).
Solution: never commit in the middle of a request. If the changes have an
impact on the registry, then mark it as invalid (with a new flag), and signal
registry invalidation after everything has been committed. If the request
fails, reset the registry. Both registry and cache invalidation are handled
the same way.
Old methods are still present since a long time and are deprecated since
saas-3. This compatibility layer adds unnecessary complexity to the module
API. Those methods should now be removed. Some renaming is also performed
to ease resource api understanding, notably to better differentiate
internal methods from other methods.
All addons are updated accordingly.
Xavier Morel