We explicitly discourage a compute method used for both stored and
non-stored fields, because it may be unexpectedly update the database.
Indeed, we don't expect the computation of a non-stored field to update
the database. Allowing this kind of compute method makes reasoning
about readonly code much more difficult, and would prevent readonly
transactions with such fields.
For instance, consider a compute method for both fields F (non-stored)
and G (stored), and assume that none of those fields are in cache.
Whenever F is accessed, the compute method is invoked, and both fields
are assigned, which potentially generates an SQL update for field G.
This is problematic if we require the current transaction to be
readonly.
Part-of: odoo/odoo#98565
The 'sale_ebay' module adds the `product_variant_ids` one2many field on
the `product.template` form view. The `product_variant_ids` view
contains `virtual_available` (depending on `uom_id`). When the user
changes the `uom_id` of the `product.template`, onchange is triggered,
it takes a snapshot of the previous data, and it will computes the
previous value of `virtual_available`. But the associated compute
method will fail with a traceback:
File "/data/build/odoo/addons/stock/models/product.py", line 199, in _compute_quantities_dict
res[product_id]['qty_available'] = float_round(qty_available, precision_rounding=rounding)
File "/data/build/odoo/odoo/tools/float_utils.py", line 54, in float_round
rounding_factor = _float_check_precision(precision_digits=precision_digits,
File "/data/build/odoo/odoo/tools/float_utils.py", line 29, in _float_check_precision
assert precision_rounding is None or precision_rounding > 0,\
AssertionError: precision_rounding must be positive, got 0.0
The `precision_rounding` is `0.0` because the `uom_id` of the product is
empty. It is is empty because we force the `uom_id` of the
`product.template` to be `False` in `initial_values` (before the
snapshot), and then the `uom_id` takes the value of its
`product.template` (`False`). But actually, the cache of the product
should be full with its previous values before doing the snapshot.
This was not the case because we only copy data from store fields
(see `fnames`). Then compute fields was computed after setting field
change to `False`.
opw-3334822
opw-3419392
X-original-commit: 5021e77ba52fac465a5d842ac04c0a3a22aea2dd
Part-of: odoo/odoo#135635
Co-authored-by: William Henrotin (whe) <whe@odoo.com>
And load only two languages, not three.
Faster to load and avoids ambiguity when a Mexican sees es_ES content
closesodoo/odoo#134785
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before es_MX was informally considered as the "reference spanish" as
we have an office in Mexico.
Create a new language that will be used by all the local variations of
Spanish and that we can push without overlapping with es_ES content.
Part-of: odoo/odoo#134785
The fr_CH date format has been broken for years, with unnecessary spaces
after the period. This has been removed.
The de_CH thousands separator prematurely ends after the millions
because it does not loop indefinitely. This has been fixed as well.
closesodoo/odoo#135355
X-original-commit: 287a03224c9144bb547d2cf7cdc046b83b830a16
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
psycopg2.extras.execute_values was introduced in PR #101237
however it pypasses the override logic for cr.execute. As a result
1. --log-sql cannot log these queries
2. assertQueryCount cannot notice these queries
...
This commit create a new api cr.execute_values to support the same SQL feature
without losing the override logic for cr.execute
closesodoo/odoo#131190
Related: odoo/enterprise#47374
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Create a vendor bill with a specific attachment (on ticket)
Go to vendor bill list view
Select the created bill and another one
Print > Original Bills
Traceback due to unhandled ValueError on pdf read
opw-3498898
closesodoo/odoo#135320
X-original-commit: adf4c91f3f696ee849577e345d40e24d59d452f4
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
This commit adds `target=download`, as `target=self` adds some unwanted
visual effect. In other words, the "block UI" is never unblocked when
some actions are triggered. This is specific for "Download" actions as
the download is correctly executed, but the page is never `unload`.
e.g.:
```python
action = {
'type': 'ir.actions.act_url',
'url': '/web_enterprise/partner/%d/vcard' % record.id,
'target': 'self',
}
```
Note:
We can't use "'target': 'new'" as it creates a bug in Mobile Apps.
When The Mobile Apps create a new "Tab/Page", they do it in a new
sandboxed browsing environment, so the user isn't logged in and the
resource isn't accessible anymore.
Task ID: 3435131
closesodoo/odoo#134436
X-original-commit: 08db3deb3336f0c1ff9fe2703ebeb8ea5b5aeb3d
Related: odoo/documentation#5822
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Only available in Python 3.9, and for now at least Odoo remains
committed to supporting Python 3.8.
And it's not actually necessary: `literal_eval` supports ast node
input, because internally it just `ast.parse`s the input then
evaluates it, giving it an AST node just skips the parse step.
closesodoo/odoo#135302
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
fix typo to log correct error message when the imported file is badly formatted
X-original-commit: 75606b0f92a26b64ee281792dfa32d47f135f46d
Part-of: odoo/odoo#135277
before this commit:
translations updated by `update_field_translation` api cannot be detected by
t-cache and some cached data whose model overrides `write` with an extra
'clear_caches()'
Step to reproduce:
- Create a mega menu, select any template, `Odoo Menu` for the example
- Install another language on the website
- Go to the translated version of your website and enter translate mode
- Change "Camera" in the mega menu to something else
- Save
The change won't be replicated, looking like it did nothing.
From there, removing or adding `edit_translations=1` in the URL will
use different cache version of the page's views and you will see the
outdated value on one and the correct on the other one.
after this commit:
`update_field_translation` will call `write`
it does the following 4 important things
1. mark field as modified
2. execute logics in the override `write` method
3. update write_date if needed to support t-cache
opw-3305117
X-original-commit: 2beb466668e4eb80d7c3ca3947445fb1cb141cff
Part-of: odoo/odoo#135277
When creating a new company, SUPERUSER_ID is not added in `user_ids`.
Therefore, when installing a new module, the newly created company
is not in `self.env.companies`, which leads to an issue when
computing `company_id`.
Steps:
- Install Accounting module
- Create a new company with any localisation
- Delete the tax closing entry
- Try to install `stock_account` module
-> Error: `_check_company` failed
With this commit we add the company newly created to
the superuser's `company_ids`
opw-3488788
closesodoo/odoo#135276
X-original-commit: 771fdaf25eefdc30443e96b03b029346bebb50be
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
This commit reworks a little bit the backend assets to remove a
bundle and thus save a call at webclient startup. The bundle
"assets_backend_prod_only" existed only to allow to add files in
production, but not in the tests (typically, the file that spawns
the webclient).
This commit introduces a new bundle "web.assets_web" that contains
"assets_backend" and the few files that we only want in production.
In the /web page, we now load "assets_web" instead of
"assets_backend" and "assets_backend_prod_only". In the /web/tests
page, we keep loading "assets_backend", which is now directly
included into "web.tests_assets".
For the sake of consistency, this commit also renames the dark
mode bundle "dark_mode_assets_backend" into "assets_web_dark".
closesodoo/odoo#135204
Related: odoo/enterprise#47316
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
According to standard flow when a record is created by user we do not make
a model data entry and if he does any changes in standard record we change the
noupdate to true on conditional bases to keep the data same while upgrading
but in the case of user created record where there is no model data entry the
engine should consider it as noupdate true but without the model data entry
select query gets null resulting into engine considering it false and the update
case are designed to consider true or else so for null case it falls under else
part hence creating issue in product_template name and cowed website menu
So,we have updated the case accordingly.
closesodoo/odoo#135218
X-original-commit: 880538db4ac4833322e57adb3b4d8239eb382547
Signed-off-by: Raphael Collet <rco@odoo.com>
- If default language of website is not en_US then it's
translation will be lose after upgrade as till now we are
considering en_US as a default language for all the records.
- In this commit, we have added translation for website which
is having different default language.
Opw: 3186741, 3418725
X-original-commit: 2575dff9362ba6dd2a97db8911ac8b867b126e08
Part-of: odoo/odoo#135218
This way, we avoid spamming the log each time new constraints are added in the constraint's table.
closesodoo/odoo#132681
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
before this commit, the uninstall and upgrade option is not
shown in the kanban.
introduced in: https://github.com/odoo/odoo/commit/5b68871097df5e7a13966dee4c650d1f34f9e7c1
* open apps kanban
* click on kanban menu(3 dots) of installed app
* upgrade and uninstall button is not shown
after this commit, the upgrade and uninstall button will be
shown in the apps kanban menu depending on the state of
the app
closesodoo/odoo#135132
X-original-commit: 90184ff280b4225522797528af51a32591eb5347
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
For model_terms translated fields if a translation for a lang(fr_FR) has never
been defined
before this commit
when update translations for both en_US and fr_FR, the new translation for fr_FR
cannot be saved.
after this commit
new translations can be correctly saved when en_US and fr_FR are updated at the
same time.
closesodoo/odoo#135103
X-original-commit: ef4b195eeac178a14eb47f4e6cc61ddc97f78866
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
before this commit, in the import translation
wizard, if user try to import a file
currently it will show any file types to
upload even though supported formats are
csv and po
after this commit, if user try to import a
file only csv and po files will be shown
closesodoo/odoo#128807
Signed-off-by: Raphael Collet <rco@odoo.com>
Description of the issue/feature this PR addresses:
Prior to this, when multiple currencies with the same symbol where to appear
in a same document or be sent from a country to another with the same currency
symbol, the only information the recipient had was
the currency symbol leading to lack of clarity.
Desired behavior after PR is merged:
This set of two PR has for objective to give the user the possibility to edit
the symbol curency that is displayed everywhere so that if he feels like the
documents and views are lacking clarity, he can improve it.
This was already an option before but only when the debug mode was active.
This commit has the purpose of moving the currency symbol option out of the debug mode section and put it in the right column of the currency form view.
Adding this, the "Symbol" option is moved out of the debug mode.
task-3484335
closesodoo/odoo#133554
Related: odoo/enterprise#46527
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
With input 'name email@domain.com' (missing chevrons allowing to clearly spot
the email part) 'getaddresses' returns ('', 'name email@domain.com) i.e. the
whole input is considered as being the email.
To improve the heuristic we can add a fallback by recalling 'getadresses'
on the input with spaces replaced by commas when it found only an email and
no name. The new email will be split into sub pairs allowing to find the real
email and various name parts, allowing to make a new name / email pair.
Emails should not contain spaces thus this is coherent with email formation.
This fallback actually comes from a specific code done in '_parse_partner_name'
of Partner model. Supporting it directly at tools level make the behavior
coherent for all models.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@18c71edf59
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
As of rfc5322 section 3.4.1 local-part is case-sensitive. However most main
providers do consider the local-part as case insensitive. With the introduction
of smtp-utf8 within odoo, this assumption is certain to fall short for
international emails. We now consider that
* if local part is ascii: normalize still 'lower' ;
* else: use as it, SMTP-UF8 is made for non-ascii local parts;
Concerning domain part of the address, as of v14 international domain (IDNA)
are handled fine. The domain is always lowercase, lowering it is fine as it
is probably an error. With the introduction of IDNA, there is an encoding
that allow non-ascii characters to be encoded to ascii ones, using 'idna.encode'.
Also remove usage of 'email_re' in mailing email check. It is too restrictive
compared to real formatting we support (or try to). Valid outgoing emails
were directly canceled, notably when containing unicode.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@3ce5fb3072
Part-of: odoo/odoo#134934
As it already normalizes returned emails some manual calls to 'email_normalize'
are not necessary. Some variable names are updated to be clearer about the
email being normalized.
Parsing contact name and email is also moved into a tool function to avoid
using a partner environment just for a tool parsing method.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@f7add44c28
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
When having multi-emails input in an email field, 'email_normalized' field is
currently 'False', as they expect the field to contain a single email. This
has several drawbacks
* searching partners or fetching information based on emails does not work as
most tool methods use 'email_normalized' which is False (see e.g.
'_message_partner_info_from_emails', '_mail_find_partner_from_emails'
or 'find_or_create');
* blacklist is not available as it is based on 'email_normalized';
* mass_mailing wrongly considers those emails as invalid and cancel their
mail and related trace, as it tries to skip sending emails to invalid
emails;
Be more defensive and use first found email in case of multi-emails field.
Other emails are ignored. It is already an improvement that does not break
flows in stable and allow more emails to be sent.
before
-> email: '"Raoul" <raoul1@raoul.fr>, raoul2@raoul.fr'
-> email_normalized: False
after
-> email: '"Raoul" <raoul1@raoul.fr>, raoul2@raoul.fr'
-> email_normalized: raoul1@raoul.fr
A side effect is that it helps finding back some partners, as indicated in
tests where less phantom partners are created. It also helps suggested
partners / emails flow in discuss.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@90218186c5
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
Main fix in this commit: fix multiple nested formatting in 'email_formatted'
computation for <res.partner>. Other use cases are mainly left untouched as
we let users deal with their input. In summary :
* double format: if email already holds a formatted email, we should not use
it to compute email_formatted, like
name: Name / email: 'Format' <email@domain.com>
-> before '"Name" <"Name" <email@domain.com>>"
-> after '"Name" <email@domain.com>''
* multi emails: sometimes this field is used to hold several addresses
like email1@domain.com, email2@domain.com. We currently let this value
globally untouched by extracting emails and joining them, as we do not
expect email_formatted to be a list of emails. Extractin emails allows
to filter out extra text stored in email field, like
name: Name / email: text, email1@domain.com, email2@domain.com
-> before: "Name" <text, email1@domain.com, email2@domain.com>
-> after: "Name" <email1@domain.com,email2@domain.com>
* invalid email: if something is wrong, better keep it in email_formatted
than harcoding "False". Indeed this eases management and understanding
of failures at mail.mail, mail.notification and mailing.trace level. This
behavior does not change as it was already implemented like that even if
not sure it was intended;
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@9175bbd8e2
Part-of: odoo/odoo#134934
Move tests currently in mail about helpers defined in 'tools/mail.py' directly
into base. No need to test it in mail, there is no specific override or
behavior change compared to base.
Regroup partner related tests in base into 'test_res_partner'. This breaks
part of test history but it helps knowing which features are tested.
Task-2612945 (Mail: Defensive email formatting)
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
RATIONALE
Add tests related to not standard usage of email field. Two main use cases
are tested here
* formatted emails: `"Full Name" <email@domain.com>` stored into the 'email'
field;
* multi emails: `email1@domain.com, email2@domain.com` stored into a single
'email' field;
Additional tests: tests with unicode / ascii / case / wrong formatting are also
added to check the support in normalize and format methods.
IMPLICATION
Email field is generally managed as "containing a valid email". This means
it is sometimes used as it in 'formataddr' as well as to perform searches or
identification checks. Example of issue: partner 'Raoul' has a formatted email
like "Raoul" <raoul@raoul.fr>. Using 'formataddr' in email_from leads to
from: "Raoul" <"Raoul" <raoul@raoul.fr>>
-> which is incorrect (but often dynamically corrected by email servers);
Email field holding multi-emails are not normalized, as current normalize
is done only if the field holds a single email. It means
* no easy finding based on 'email_normalized', e.g. various tools like
'_mail_find_partner_from_emails' or 'find_or_create' do not find partners
based on this email;
* no exclusion list management;
* issue with formatting, like
to: "Raoul" <raoul@raoul.fr,raoul.other@raoul.fr>
-> which is incorrect (but often dynamically corrected by email servers);
USAGE: OUTGOING EMAILS
Those use cases currently generate faulty outgoing emails. This is valid for
recipients ('email_cc', 'email_to') as well as author ('email_from').
For formatted emails: `email_to` is formatted again based on name and email
which leads to sending emails to `"Full Name" <"Other"<email@domain.com>>`.
Note that multi emails without formatting may work as it leads to email_to
`"Full name" <email1@domain.com,email2@domain.com>`. Some outgoing email
servers correctly send multiple emails. It depends on their fault
tolerance.
USAGE: FIND BASED ON EMAIL (NORMALIZED)
When searching for partners (e.g. using '_mail_find_partner_from_emails' or
'find_or_create') normalized version of input is used.
In case of multi emails sanitize is 'False', as normalization expects a single
email in the field. Therefore no partner is found. In processes that do a
"search or create" (e.g. using a template on a record) this leads to creating
a new partner (or several partners in case of multi emails) each time.
USAGE: OTHER FLOWS
Other flows are build on top of '_mail_find_partner_from_emails' / 'create'
of outgoing emails and are impacted by formatted email / multi email usage.
Those include notably
* mass_mailing: '_message_get_default_recipients' should be defensive to
give correct values when creating mailing emails;
* mass_mailing: faulty emails is based on normalize and multi-emails are
considered as faulty and ignored;
* after post hook: '_message_post_after_hook' tries to link messages without
author (but email_from) with newly-created partners, when partners are
created from chatter. It is therefore impacted by those corner cases;
* marketing_automation: built on top of mass_mailing and suffers from the
same issues;
USAGE: UNICODE
Unicode in emails should be supported. 'formataddr' and IrMailServer notably
received fixes to support unicode. Some check performed on email addresses
fail when unicode is involved, which leads to some emails not being sent
while they could.
SPECIFICATIONS
Add tests related to those corner cases. Also add tests for computation of
`email_formatted` field of Partner model. It currently generates wrong email
values for the same corner cases (multi emails, formatted emails).
Tests are also added for the computation of `email_normalized` field used
notably for blacklists. It is not computed currently when being in multi
email mode which prevents from any blacklist mechanism as well as make
email finding harder. `_mail_find_partner_from_emails` tool method is also
tested with multi email as it uses the same heuristic as normalized email
field.
Tests are also added for mass mailing, when having to mail documents that
have a partner with formatted emails / multi-emails, or that have an email
field with formatted emails / multi-emails.
Also restore a test removed at odoo/odoo@afcb734908 while it should have been
updated to state that email addresses containing non-ascii characters are
supported.
Add some tests for tools methods used in various email processing flows.
Unicode tests are also added.
In future commits we will try to make email usage a bit more defensive to
try to lessen issues with that kind of use cases.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@fc8442f133
Part-of: odoo/odoo#134934
Add 'id' in partner ordering, to be sure searching on duplicated partners is
deterministic.
In mail, use standard ordering when searching on users to be deterministic.
As ordering on users is based on name then login which is unique, this is a
safe ordering and can be used as it.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@1e6d50a141
Part-of: odoo/odoo#134934
The breakpoint() builtin was added in [Python 3.7] ([PEP 553]). It is
conveniently everything-agnostic, can be configured (including
disabled) via an envvar (`PYTHONBREAKPOINT`) and
code (`sys.breakpointhook`), and defaults to pdb (`pdb.set_trace`).
This is more flexible as it allows using arbitrary callables without
special casing, which mostly allows using less common
debuggers (e.g. IDE debug servers / hooks).
As using an empty string for the debugger name was not allowed
previously, co-opt that to invoke `breakpoint`. And deprecate the old
style.
[Python 3.7]: https://docs.python.org/3/whatsnew/3.7.html#pep-553-built-in-breakpoint
[PEP 553]: https://peps.python.org/pep-0553/closesodoo/odoo#134842
Related: odoo/documentation#5800
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Rationale:
- allow mass changing languages (in case you want to remove one lang)
- allow quick company re-assign
Other fields are marked as readonly to avoid messes.
Task-3494874
closesodoo/odoo#134786
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Purpose
=======
Allow to group records by their property values,
like we can do with normal fields.
Technical
=========
Because there's no foreign key, when we group by a relational property
we need to check the existence of the ids in the query (and same for
selection and tags, because we might have value of a deleted
option / tag in database).
Task-3032464
Part-of: odoo/odoo#103510
Purpose
=======
Currently, it is possible to use some bad characters in a property name
by writing directly on the parent (not via the child).
It's possible only with RPC call and it wasn't an issue because we
recheck the name anyway before using it in SQL query (but it should be
cleaned).
We also restrict the maximum length (there's nor reason to use
huge property names).
Task-3032464
Part-of: odoo/odoo#103510
Purpose
=======
Allow to use `default_properties.xxxxx` as a context key, to set the
default value on a property. We need that because when we group by
a property in a Kanban view, we can create new record in a given
column, and this process will set this context key.
Task-3032464
Part-of: odoo/odoo#103510
Server actions that 'update the record' have a mechanism to allow users
to easily select a selection value if the field they want to update is a
selection field (instead of having to type the technical value
directly).
Before this commit, this mechanism incorrectly stored the selection's
name instead of the value (e.g. 'Done' instead of '01_done'), making the
write crash when the action was run.
closesodoo/odoo#134625
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
In this commit, the loadXML function has been removed. We use registry with
xml_templates to load XML templates for OWL Apps.
The goal of task is to remove loadXML and getBundle from assets to simplify
the understanding of assets api.
task-3266441
closesodoo/odoo#134520
Related: odoo/enterprise#47001
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Before this commit, formatters like `formatMonetary` and `formatFloat`
weren't loaded in the assets front-end.
This commit introduces `formatAmount` ( `formatMonetary` calls
`formatAmount` but makes some prior processing to deduce the currency
from the field) and makes `formatAmount` and `formatFloat` accessible
from any front-end application.
Note: The currencies were added in the front-end session info because
they are needed in `formatAmount`.
closesodoo/odoo#133824
Related: odoo/enterprise#46658
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
*: base, crm, digest, mail, mass_mailing, sms, test_base_automation,
website_forum, website_sale
This commit makes "Automated Actions" more discoverable and usable by:
- Adding a menu in the kanban header config dropdown to add/edit them.
- Creating a new custom kanban view for a clear understanding of each
automated action record and its associated actions.
- Introducing new "smart" triggers that appear in the form view based on the
chosen model:
- Updated Values category:
- "Stage is set to" when a `stage_id` field exists in the model,
allowing users to select a specific stage value.
- "State is set to" when a `state` field exists in the model,
allowing users to select a specific state value.
- "Priority is set to" (`priority`) where users can select a specific priority.
- "User is set" (`user_id`, `user_ids` fields)
- "Tag is added" (`tag_ids` field) where users can select a specific tag.
- "On Archive"
- "On Unarchive"
- Timing Conditions:
- "After creation"
- "After last update"
- Deprecating previously known triggers "On Creation" (`on_create`) and "On
Update" (`on_write`) to simplify the user experience. "On Creation & Update"
(`on_create_or_write`) is retained and renamed to "On save".
- Changing the `ir.actions.server` Many2one relationship to a One2many
relationship. Automated actions can now directly contain multiple actions,
eliminating the need for an "Execute several actions" action in automation
rules.
- Introducing a widget for the new `ir.actions.server` One2many field for a
clearer understanding of multiple actions.
This commit also enhances the usability of "Server Actions" (`ir.actions`) by:
- Removing the `ir.server.object.lines` model and the associated `fields_lines`
One2Many field. The attributes of the removed model are now merged into
`ir.actions`. An action can now write to only one field, and the create action
is now a name_create action.
- Adapting the form view when creating an "Update the record" action. The value
field shown adapts itself based on the field to update; this field can be a
`reference` field for a `one2many` `update_field_id`, a `one2many` field for a
selection `update_field_id`, or a `text` field otherwise.
- Refactoring the form view to display only relevant details and other
miscellaneous improvements.
Taskid: 3085360
Part-of: odoo/odoo#114352
Co-authored-by: Florent Dardenne <dafl@odoo.com>
Co-authored-by: Julien Carion <juca@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
When we haven't provided a custom action, the tour step runs the default
action. In the final step of the tour, when there is no `run` or
`isCheck` provided, It shows warnings of 'ignoring action (auto) of last
step' as it can lead to a race condition.
This commit resolves the warnings: `ignoring action (auto) of last step`
task-3429500
closesodoo/odoo#129239
Related: odoo/enterprise#46683
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit, adds a new python method (`web_save`) to save a record, and
optionally read-it again in one rpc call. This optimizes the current
behavior that is to save a record in one rpc, and read-it in a second
rpc.
web_save, will receive the list of IDs of the records to save (if this
list is empty it will create the records, if not, it will write on the
existing records), the list of changed fields, and the unity
specification as optional argument to read the created/modified records
(if the specification is not set, the function will return a list of IDs
of the created/modified records).
closesodoo/odoo#133021
Task-id: 3453184
Related: odoo/enterprise#46559
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When _create() is invoked, it inserts rows into the database, and sets
the cache of the corresponding records to the values that are inserted.
If a field is not passed to _create(), we assume that its database value
will be NULL (or falsy, at least) and put None in cache, in order to
avoid fetching that value. However, this only makes sense for stored
fields.
Part-of: odoo/odoo#133021
There are cases where the result of `check_company_domain_parent_of`
is used in in a loop, leading to the parent_of relation being
recomputed once or even multiple times per iteration during SQL
evaluation.
Computing the parent relationship turns out to be fairly expensive in
worst case scenarios (e.g. lots of companies), so while precomputing
doesn't save much for a 1:1 situation (though it does make the job of
the expressions compiler a bit simpler), the ability to compute it
just once instead of say 140 times does make a huge difference in
e.g. some report renderings.
Nota: apparently `_check_company_domain` can be called with a string
because lol, so there's a special case for that.
closesodoo/odoo#133530
X-original-commit: 2f9ae135c9dd7cb09fa83fda7a9b304993cb3edc
Related: odoo/enterprise#46518
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Changes in default can be bothersome, embed a full baseline
configuration for reliability.
closesodoo/odoo#27926
Signed-off-by: Pierre Masereel <pim@odoo.com>
Raphael Collet