- Create two record with state == 'one' and with activities
- Create an automated action if state == 'two' then record.sudo().activity_ids.action_done()
- Set state == 'two' in same time of two record
In the loop line 261, for the first record self.action_record_id is in cache, but for the second record it is not in cache because of the unlink made by action_done(). When the orm raise during put in cache because he have no access to self.
closesodoo/odoo#82574
X-original-commit: 2207d8adbd37c6758f350cced68f285f8960c3aa
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
If an error append during an automation made by a standard user, the error is not correctly show.
closesodoo/odoo#82591
X-original-commit: d76d896400016f4ec504b34e113d5f42951970a1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The use-case that motivated this fix is the deletion of a project task
with many subtasks. The field 'project_id' on tasks is recursively
computed, and some automated action must be executed when its value
corresponds to a given project.
The issue occurs when the domain of automated actions is evaluated by
method search(), because the latter flushes the fields to search on,
which are also the ones being recomputed. Combined with the fact that
recursive fields are not computed in batch, this leads to a huge amount
of recursive calls between the automated action and flush().
The execution of task.unlink() looks like this:
- mark 'project_id' to compute on subtasks
- delete task
- flush()
- recompute 'project_id' on subtask1
- call compute on subtask1
- in action, search([('id', 'in', subtask1.ids), ('project_id', '=', pid)])
- flush(['id', 'project_id'])
- recompute 'project_id' on subtask2
- call compute on subtask2
- in action, search([('id', 'in', subtask2.ids), ('project_id', '=', pid)])
- flush(['id', 'project_id'])
- recompute 'project_id' on subtask3
- call compute on subtask3
- in action, search([('id', 'in', subtask3.ids), ('project_id', '=', pid)])
- flush(['id', 'project_id'])
- recompute 'project_id' on subtask4
...
closesodoo/odoo#80141
X-original-commit: e2788b580ef15ef3083ac919737a46d850143832
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
As create_uid has no value on mail.compose.message model when being in onchange
or new mode, 'Mail Compose Message Rule' record rule may crash. In this
commit we fix that issue by adding a value for create_uid. An unit test is
added to ensure it effectively fixes the use case.
Steps to reproduce this warning:
1. Create automated action for the 'mail.compose.message' model
2. Try to open 'Email compose Wizard'
Warning:
"Due to security restrictions, you are not allowed to modify 'Email composition
wizard' (mail.compose.message) records.
Records: mail.compose.message,NewId_0x7f8e99762310 (id=NewId_0x7f8e99762310)
User: USERNAME (id=2)
This restriction is due to the following rules:
Contact your administrator to request access if necessary."
Task-2641572
opw-2628005
PR odoo#76159
Closes#75369
X-original-commit: 26d64c0b84b76bb9164a8895bcc21b66754478ae
Part-of: odoo/odoo#77005
Co-authored-by: Thibault Delavallee <tde@odoo.com>
*base_automation,iap,im_livechat,point_of_sale
This commit introduces a new file in core/utils: hooks.js
This file contains custom hooks (useEffect, useService, useBus...).
The useHotkey hook is tightly related to hotkeys, so it has been
moved to core/hotkeys.
closesodoo/odoo#74535
Related: odoo/enterprise#20003
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, the error service bound its listeners onto window.
This may create pollution when executing more than one test instanciating an error_service
After this commit, we bind the handlers onto browser, which is fully in our control in tests.
- move dialog state handling in dialog service
- remove use of __destroy calls in dialog container
closesodoo-dev/odoo#964
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Some services are coupled with a Component. Usually the service
handles the state of the system, and the Component displays or uses it.
To enable the communication between the service and the component
while making it private, the services should add themselves their
Component in the relevant registry, with the proper means of communication
passed in props.
This mechanism relies on c1d49d494e0ae3a94b3943186eb6d1ebd7b98a6e
Before this commit, the function close on dialog trigger an event to close
the dialog. This could create an issue when the dialog is not yet mounted.
Now, the function close on dialog uses the dialog service to close the dialog.
closesodoo-dev/odoo#936
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
SPECIFICATIONS
Remove ``channel_ids`` field from ``ir.actions.server``. As we removed
support of (un)subscribing channel-based followers there is no need anymore
to have a field to add them through server actions. We can now safely remove
this field as it has no use anymore.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
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>
The recent change in the way debug=assets works (which now bundles all
files in a bundle instead of serving them statically) had a negative
impact on the stacktrace displayed in the error dialog in debug=assets:
it now display the bundle/linenumber instead of the actual file/line
number.
This is not a huge deal, most of the time, because the errors displayed
in the console display the correct information, and the debugging
process should work as before. But it can certainly be annoying in some
cases.
With this commit, we use the Stacktrace.js library to dynamically fetch
the sourcemaps and to decorate the displayed information with the
correct file and line numbers.
closesodoo/odoo#66318
Signed-off-by: Aaron Bohy (aab) <aab@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>
Commit 60106cf2 (task 2082503) introduced some changes on server
actions and automated actions, some changes were applied on server
actions but via the base_automation inherited view.
This commit move those change so they are directly applied on the server
action form view.
closesodoo/odoo#40964
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Currently, to activate/deactivate records with the 'active' checkbox
user has to switch to edit mode of the form.
So the purpose of the task is to allow the user to activate/deactivate
records from the readonly mode of the form view.
In this commit, we set widget='boolean_toggle' on the 'active' field in form
view.
closesodoo/odoo#46567
Taskid: 2206794
Related: https://github.com/odoo/enterprise/pull/8918
Related: odoo/enterprise#8918
Closes: #46567
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.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>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@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>
Purpose
=======
This module contains tests related to base automation. It makes no
sense as they have no business value.
Specification
=============
Move all the tests to a separate module as it contains models used only
to perform tests independently to functional aspects of other models.
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>
Florent de Labarre