This commit adds a new service "overlay" that will be used as a base
for other service which displays a component on foreground like
"popover" or "dialog". The services "popover", "dialog" and "effect"
already uses this new service to have a common container.
The "overlay" service also fix a stacking context issue that could
happen when a popover opened a dialog and this dialog then opened
another popover thanks to the common container.
task id: 3233266
closesodoo/odoo#115308
Related: odoo/enterprise#38786
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
`base_automation` module patches `write` method to detect changes that trigger
the automated actions. It's implemented by reading current values before making
the write operaion. It may lead to max recursion error if compute method updates
other records. Example: in `account_asset` Depreciation values are computed for
all Depreciation Lines at the same time [1].
Fix it by breaking recursion on computed not stored readonly fields: `write`
method for such fields might be called by compute method only and hence the old
value is always equal to new value.
STEPS:
- Create an Asset model of 240 Months, Straight Line, No pro rata
- Create Assets using this asset model and confirm it.
- Create an automated action for account.move and trigger on update (Action can
be anything)
- Now try to access the Assets
[1]: https://github.com/odoo/enterprise/blob/45dd0884c84d0e8a31c2c36a975f1b1f7cf6d01c/account_asset/models/account_move.py#L39-L46
opw-3147688
closesodoo/odoo#115216
X-original-commit: 0561ad2324905aed5afd5cc163e5e6aebee09d40
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
There is only one legitimate usage of `_patch_method` (base_automation)
and none of `_revert_method`. The other uses are in tests and they are
all wrong: if the test crashes between the `_patch_method` and the
`_revert_method`, the method will not be reverted.
For the only proper usage of `_patch_method`, move the code to this
place. Correct tests using `_patch_method`/`_revert_method` by calling
the `patch` method of `BaseCase`.
Also, remove the `api.returns` from the `create` method of `BaseModel`
as it is useless and confusing. In fact, we never use it because we
have a special treatment at the RPC level for the `create` method
(see `_call_kw_model_create`).
closesodoo/odoo#110370
Signed-off-by: Raphael Collet <rco@odoo.com>
Previously, we added some handling so that errors that were not
defaultPrevented would have their traceback logged by the error service
instead of the default behaviour of the browser, because not all
browsers correctly log error chains (errors with causes). This did not
actually work because the errorEvent was written on the object at the
top of the error chain and checked on the error at the bottom of it.
This commit fixes that by just looking at the event on the uncaught
error.
closesodoo/odoo#108463
X-original-commit: cefba026ad7fe453da840a948e25d29d4d1837e9
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
RPC call may fail because of error in `base.automation` handler. In this case
the response contains attribute `exception_class=base_automation` to handle
error via custom dialog `BaseAutomationErrorDialog`, which provides extra
buttons (disable/edit Automated Action).
1.
`BaseAutomationErrorDialog` was incorrectly inherited from ErrorDialog, which
cannot extract traceback from `data.debug` value of jsonrpc. Fix it by replacing
it RPCErrorDialog.
RPCErrorDialog: https://github.com/odoo/odoo/blob/a75fcbe03f31fd10a74e609672b64dad165e68d7/addons/web/static/src/core/errors/error_dialogs.js#L62-L70
2.
Button `Edit Action` didn't work, because it tries the same rpc call before
navigating to the action. For example, it would repeat rpc call to create a
record, which doesn't work because of broken automated action.
It happens because form changes are saved automatically since Odoo v15.
Fix it by adding `target: "new"`.
opw-2845893
closesodoo/odoo#106134
X-original-commit: f54eef302323f1f6406e9b2ac8e02cec5b627fac
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Currently only an email action based on template exists in server actions when
having mail app installed. It basically sends an email based on a mail template.
However being able to post a message on record is also useful. Instead of
sending emails it post on a document as a comment or as a note, like what
users can do using the chatter. Notification flow for those cases is the
classic from post: followers, specified partners, Inbox/Email, ...
Task-2613245 (Server actions mail update / cleaning)
Closes#45640
Part-of: odoo/odoo#75906
In this commit we cleanup base automation model in order to make it a bit
more inlined with current code state of the art.
* add no_create / no_open on technical fields (m2o towards fields notably)
as creating or updating fields on the fly is not the purpose of base
automation module;
* rewrite onchange into compute or constraint methods;
* add compute methods to cleanup data when changing configuration (model or
trigger). Some fields have no usage except in some configuration better
reset their value. Notably fields linked to the chosen model should be
reset;
* add constraints for invalid configuration, in addition to currently
returned "warning" in the interface;
Task-2885890 (Base Automation model cleaning)
Part-of: odoo/odoo#75906
Purpose is to ease finding server actions code and views. We just rename
some files and move some code, nothing should change functionally.
Task-2613245 (Server actions cleaning and mail update)
Part-of: odoo/odoo#75906
How to reproduce the bug ?
- install hr_payroll and web_studio
- in Settings > Technical > Automated Actions, create a new action
linked to the Payslip model
- Go to the Payslip app and generate a payslip by choosing an employee
that has work entries
What is the bug ?
When you create an automated action, you will overwrite the origin write
function of the model. However, the origin write function will still be
called by the new write function.
In the new write function, the records will be filtered according to
their ids. This means that if a record has a NewId, it will not be
handled. This is the bug here since the payslip is under creation.
opw-2781751
closesodoo/odoo#91217
X-original-commit: 84775d1b261d3faa33b2d1abf4e2e016c718b398
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
*: base_automation, iap, web_tour
Previously, when trying to create a custom dialog, one would need to
extend the base Dialog class and configure it directly on the class,
using separate templates for the body and footer as necessary. This is
very unidiomatic owl code, and it is much more natural to simply extend
Component, and use Dialog at the root of the template, giving it slots
and props to configure its properties and contents.
This commit changes the dialog API to work as described and adapts code
that uses it.
closesodoo/odoo#89113
Enterprise: https://github.com/odoo/enterprise/pull/26462
Related: odoo/enterprise#26462
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit replaces Component by LegacyComponent when the component
uses removed features from owl 1 like getting its `el` or `trigger` an event.
It also adds `useService("rpc")` when component needs it.
closesodoo/odoo#85389
Related: odoo/enterprise#24745
Signed-off-by: Géry Debongnie <ged@odoo.com>
On most of the cases, the fine-grained reactivity is bypassed by:
- Setting the optional `deep` argument as `true` on the renderer
function. This will force a render to update all child components.
- Changing some objects from reactive to non-reactive using `toRaw`
function.
Part-of: odoo/odoo#84314
Co-authored-by: Géry Debongnie <ged@odoo.com>
*: base_automation, hr, mail, web, web_tour, website_payment
Previously, some modules were imported twice, this increases duplication
and can make refactoring more difficult. This commit enables the
no-duplicate-imports eslint rule and fixes offending modules to remove
duplicates.
closesodoo/odoo#84530
Related: odoo/enterprise#24319
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the next version of Owl, all exported terms are directly available
from the top level `owl` object. This commit aims to adapt existing
imports to this new system. This is done by importing any Owl property
used in files at the top, right after the `import` or `require`
statements.
closesodoo/odoo#82736
Related: odoo/enterprise#23609
Signed-off-by: Géry Debongnie <ged@odoo.com>
- 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.*
Michael (mcm)