The changes in `auth_password_policy` are largely the owlification of
the password meter widget:
- modernize the password policy module and convert it to an
odoo-module (note: now exports a pseudo-abstract class which is
really a policy, for the sake of somewhat sensibly typing
`recommendations`)
- replace the implementation of the Meter and PasswordField widgets by
owl versions
The changes to web and base stem from taking a look at converting the
ChangePassword wizard, and finding that it would be a pain in the ass
but also... unnecessary? It seems to have been done as a wizard
completely in javascript despite being backend-only for legacy
reasons: apparently one of the very old web clients (v5 or v6
probably) implemented it as a "native action" which was directly part
of the client's UI, and so it had to be implemented entirely in the
client.
Over time it was moved back into the regular UI (and moved around
quite a bit), hooked as a client action to maintain access to the
existing UI / dialog.
But since it's been an action opened via a button for years it can
just... be a normal wizard, with password fields, which
auth_password_policy can then set the widget of.
So did that:
- removed the old unnecessary JS, and its dedicated endpoint (which is
*not* used by portal, portal has its own endpoint)
- used check_identity for the "old password check"
- split out `change_password` with an internal bit so we can have a
safer (and logged) "set user password" without needing to provide
the old password, which is now used for the bulk password change
wizard as well
- added a small wizard which just takes a new password (and
confirmation), for safety a given change password wizard is only
accessible to their creator (also the wizard is restricted to
employees though technically it would probably be fine for portal
users as well)
Rather than extensive messy rewrite / monkeypatching (the original
wizard was 57 LOC, though also 22 LOC of template, the auth_policy
hooking / patching was 33, plus 8 lines of CSS),
`auth_password_policy` just sets the widget of the `new_password`
field in the new wizard, much as it did the bulk wizard.
Also improve the "hide meter if field is empty" feature by leveraging
`:placeholder-shown`. This requires setting a placeholder, and while
empty works fine in firefox, it doesn't work in chrome. So the
placeholder needs to be a single space. Still, seems better than
updating a fake attribute or manipulating a class for the sake of
trivial styling.
Notes on unlink + transient vacuum
Although the wizard object is only created when actually calling
`change_password`, and is deleted on success, it is possible for the
user to get an error and fail to continue (it should be unlikely
without overrides since the passwords are checked while creating /
saving but...).
While in that case the `new_password` in the database is not the
user's own, it could be their *future* password, or give evidence as
to their password-creation scheme, or some other signal useful to
attack that front of the user's life and behavior. As such, quickly
removing leftovers from the database (by setting a very low transient
lifetime) seems like a good idea.
This is compounded by the `check_identity` having a grace period of 10
minutes. 0.1 is 6 minutes, but because the cron runs every 10 the user
effectively has 6~10 minutes between the moment they create an
incorrect / incomplete version of the wizard and the moment where it
is destroyed if they just leave it.
closesodoo/odoo#99458
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Instead of fetching all field attributes sent with the field list
to the web client,
restrict the attributes to the ones actually required by the web client
This allows, for instance,
to gain 44,75KB on each call on `get_views` for `account.move`,
from 208.78KB to 164.03KB,
with only `account_accountant` installed.
closesodoo/odoo#99660
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Since #84736 the access right check queries were merged into one
Unfortunately the query plan for cases of a group with tons of users
can be suboptimal.
Using a subselect will force the query plan in order to avoid an index
only scan on res_groups_users_rel.
Performances where tested in production, this new query being
around 300 and 1000 times faster for two tests cases (res.partner
and account.payment.term)
closesodoo/odoo#99747
X-original-commit: c7f6a88466878698a78ba26ceeb18247df6dc955
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit (and its enterprise equivalent) purpose is to smooth the
user experience and remove unnecessary steps.
The commits:
- Remove all stat buttons except the status and collaborators one from
the project edit form.
- Add multiple small changes to string/name fo fields in views
- Change the custom O2M widget for a standard M2M for the management of
child tasks
- Add the milestone field to the portal page of shared project.
- Remove the wizard 'marked_as_reached_milestone'
- Add the automatic generation of milestone when a SO is confirmed if
some SOL need it
task-2941835
closesodoo/odoo#98546
Related: odoo/enterprise#30628
Related: odoo/upgrade#3798
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This technical module can be used to configure onboarding panels flows at
company or global level (required for new Appointment onboarding, see ENT PR).
This implementation, which should be able to support the migration of the
other onboardings, separates the closed state from the completion state
(allowing to know that steps are not completed even though the panel is
closed).
Basic tree and form view are included.
Adding an onboarding with this module requires to provide records data for the
models:
- `onboarding.onboarding` + action to close the panel
- `onboarding.onboarding.step` + actions for the 'opening' and 'saving' of each
step.
See related ENT PR for the `appointment` example, in particular
`onboarding_data.xml` and `onboarding_onboarding.py`
Several python tests are also included.
Misc. In base, we slightly refresh the wording/style of the modal closing the
onboarding panel.
Task-2852375
Part of Task-2900763
Part-of: odoo/odoo#97105
* = account, sale
- Fix typo
- Make private as very specific role
- Allows to grep similar functionality from new onboarding module and previous
common implementation of onboardings.
Task-2852375
Part of Task-2900763
Part-of: odoo/odoo#97105
Purpose:
Enable to add a banner to the calendar view. This is used to show the
appointment onboarding panel (see related ENT PR).
Task-2852375
Part of Task-2900763
See odoo/enterprise#29139
Part-of: odoo/odoo#97105
The domain used in `get_filters`, used in `get_views` is
```python
[('action_id', 'in', [action_id, False]), ('model_id', '=', model), ('user_id', 'in', [self._uid, False])]
```
Therefore filtering the filters on `action_id`, `model_id` and
`user_id`.
An index on `(action_id, model_id, user_id)` would therefore be welcome
in order to search quicker on filters.
The unique constraint `name_model_uid_unique` almost does it,
but it puts the name in first, and therefore the index is not used
when searching on the above domain.
By moving `name` to the end of the unique constraint,
the index created for this unique constraint becomes
usable for the above domain,
and it makes the SQL statement to search on filters way quicker.
Before:
```sql
EXPLAIN ANALYZE SELECT "ir_filters".id FROM "ir_filters" LEFT JOIN "ir_translation" AS "ir_filters__name" ON ("ir_filters"."id" = "ir_filters__name"."res_id" AND "ir_filters__name"."type" = 'model' AND "ir_filters__name"."name" = 'ir.filters,name' AND "ir_filters__name"."lang" = 'en_US' AND "ir_filters__name"."value" != '') WHERE (((("ir_filters"."active" = true) AND (("ir_filters"."action_id" in (225)) OR "ir_filters"."action_id" IS NULL)) AND ("ir_filters"."model_id" = 'account.move')) AND (("ir_filters"."user_id" in (2)) OR "ir_filters"."user_id" IS NULL)) AND TRUE ORDER BY "ir_filters"."model_id" ,COALESCE("ir_filters__name"."value", "ir_filters"."name") ,"ir_filters"."id" DESC;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=3500.58..3500.59 rows=1 width=56) (actual time=12.940..12.942 rows=0 loops=1)
Sort Key: (COALESCE(ir_filters__name.value, (ir_filters.name)::text)), ir_filters.id DESC
Sort Method: quicksort Memory: 25kB
-> Nested Loop Left Join (cost=0.00..3500.57 rows=1 width=56) (actual time=12.933..12.934 rows=0 loops=1)
Join Filter: (ir_filters.id = ir_filters__name.res_id)
-> Seq Scan on ir_filters (cost=0.00..3499.02 rows=1 width=36) (actual time=12.932..12.932 rows=0 loops=1)
Filter: (active AND ((action_id = 225) OR (action_id IS NULL)) AND ((user_id = 2) OR (user_id IS NULL)) AND ((model_id)::text = 'account.move'::text))
Rows Removed by Filter: 100001
-> Seq Scan on ir_translation ir_filters__name (cost=0.00..1.54 rows=1 width=36) (never executed)
Filter: ((value <> ''::text) AND ((type)::text = 'model'::text) AND ((name)::text = 'ir.filters,name'::text) AND ((lang)::text = 'en_US'::text))
Planning Time: 0.311 ms
Execution Time: 12.972 ms
```
After:
```sql
EXPLAIN ANALYZE SELECT "ir_filters".id FROM "ir_filters" LEFT JOIN "ir_translation" AS "ir_filters__name" ON ("ir_filters"."id" = "ir_filters__name"."res_id" AND "ir_filters__name"."type" = 'model' AND "ir_filters__name"."name" = 'ir.filters,name' AND "ir_filters__name"."lang" = 'en_US' AND "ir_filters__name"."value" != '') WHERE (((("ir_filters"."active" = true) AND (("ir_filters"."action_id" in (225)) OR "ir_filters"."action_id" IS NULL)) AND ("ir_filters"."model_id" = 'account.move')) AND (("ir_filters"."user_id" in (2)) OR "ir_filters"."user_id" IS NULL)) AND TRUE ORDER BY "ir_filters"."model_id" ,COALESCE("ir_filters__name"."value", "ir_filters"."name") ,"ir_filters"."id" DESC;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=14.44..14.44 rows=1 width=56) (actual time=0.086..0.087 rows=0 loops=1)
Sort Key: (COALESCE(ir_filters__name.value, (ir_filters.name)::text)), ir_filters.id DESC
Sort Method: quicksort Memory: 25kB
-> Nested Loop Left Join (cost=8.86..14.43 rows=1 width=56) (actual time=0.080..0.081 rows=0 loops=1)
Join Filter: (ir_filters.id = ir_filters__name.res_id)
-> Bitmap Heap Scan on ir_filters (cost=8.86..12.87 rows=1 width=36) (actual time=0.079..0.080 rows=0 loops=1)
Recheck Cond: ((((model_id)::text = 'account.move'::text) AND (user_id = 2)) OR (((model_id)::text = 'account.move'::text) AND (user_id IS NULL)))
Filter: (active AND ((action_id = 225) OR (action_id IS NULL)))
-> BitmapOr (cost=8.86..8.86 rows=1 width=0) (actual time=0.078..0.079 rows=0 loops=1)
-> Bitmap Index Scan on ir_filters_name_model_uid_unique (cost=0.00..4.43 rows=1 width=0) (actual time=0.075..0.075 rows=0 loops=1)
Index Cond: (((model_id)::text = 'account.move'::text) AND (user_id = 2))
-> Bitmap Index Scan on ir_filters_name_model_uid_unique (cost=0.00..4.43 rows=1 width=0) (actual time=0.002..0.002 rows=0 loops=1)
Index Cond: (((model_id)::text = 'account.move'::text) AND (user_id IS NULL))
-> Seq Scan on ir_translation ir_filters__name (cost=0.00..1.54 rows=1 width=36) (never executed)
Filter: ((value <> ''::text) AND ((type)::text = 'model'::text) AND ((name)::text = 'ir.filters,name'::text) AND ((lang)::text = 'en_US'::text))
Planning Time: 1.000 ms
Execution Time: 0.121 ms
```
I take the opportunity to add the populate for `ir.filters`,
which helped me for the above analysis.
closesodoo/odoo#99657
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
No need to check access rights if we have no intersection with private
fields.
This is a small performance improvement since this value should be in
cache most of the time, but still usefull for tests.
closesodoo/odoo#99644
X-original-commit: db59dbdd7be12c6ea266d5abaf076cd189a2e7d8
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The main purpose of the test is to provide statistics for the runbot, in
order to detect unexpected variations in the loading of translations.
closesodoo/odoo#99636
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
In back-end views, the attributes
- attrs
- states
- invisible
- readonly
- required
are transfered to the `modifiers` attribute.
The web client only uses this `modifiers` attribute.
Hence, the above attributes which gets transfered
to the `modifiers` attribute can be safely removed
from the architecture sent to the web client.
In addition, in case the modifiers were all falsy
e.g. `{'invisible': False, 'readonly': False, 'required': False}`
`simplify_modifiers` was simplifying these modifiers to
`{}` and `modifiers="{}"` was set on the node,
which is a bit useless and waste transferred bytes.
This allows to gain some KB for all `get_views` calls.
For instance, with only `account_accountant` installed,
`get_views` of `account.move` goes
from 228.01 KB to 208.78,
therefore sparing 10% of KB for each calls.
An example using the `res.partner` form:
Before:
```xml
<field name="is_company" invisible="1" on_change="1" modifiers="{"invisible": true}"/>
<field name="commercial_partner_id" invisible="1" on_change="1" modifiers="{"invisible": true, "readonly": true}" can_create="true" can_write="true"/>
<field name="active" invisible="1" on_change="1" modifiers="{"invisible": true}"/>
<field name="company_id" invisible="1" on_change="1" modifiers="{"invisible": true}" can_create="true" can_write="true"/>
<field name="country_code" invisible="1" modifiers="{"invisible": true, "readonly": true}"/>
<field name="company_type" widget="radio" options="{'horizontal': true}" on_change="1" modifiers="{}"/>
```
After:
```xml
<field name="is_company" on_change="1" modifiers="{"invisible": true}"/>
<field name="commercial_partner_id" on_change="1" modifiers="{"invisible": true, "readonly": true}" can_create="true" can_write="true"/>
<field name="active" on_change="1" modifiers="{"invisible": true}"/>
<field name="company_id" on_change="1" modifiers="{"invisible": true}" can_create="true" can_write="true"/>
<field name="country_code" modifiers="{"invisible": true, "readonly": true}"/>
<field name="company_type" widget="radio" options="{'horizontal': true}" on_change="1"/>
```
closesodoo/odoo#99619
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The name "Payment Acquirer Test" of the acquirer bundled with the module
`payment_test` is confusing. It is actually the only acquirer that
doesn't connect to a test API, and its purpose is not to make test
transactions but to showcase the integration of other apps (Accounting,
Sales, eCommerce, Subscriptions) with demo payments.
Hence, the module is renamed to `payment_demo` along with its data and
technical keys to better make the distinction between acquirers' test
environment and demo payments.
task-2853481
closesodoo/odoo#99397
Related: odoo/upgrade#3846
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In order for websocket upgrade to work with firefox, the http version
must be set to `HTTP/1.1`.
Until now, this was done in the `send_response` method. The issue is
that this method is also used when sending an error. This is problematic
because we use environ to know whether or not the version should be changed
which means any error during `BaseHTTPRequestHandler.parse_request` (such as
wrong http version) would have led to an AttributeError being raised.
In order to solve this issue, this modification is done when making environ.
Moreover, we previously used the request uri to know whether or not the version
should be changed, this was not really reliable, we now use the upgrade header
for this purpose.
closesodoo/odoo#99535
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
We added trigram index for char fields since https://github.com/odoo/odoo/pull/83015.
But if `unaccent` is installed in the database (and isn't force to
`False` on field), these new trigram indexes are pointless and cost a
lot for nothing (almost nothing, it still can be used for equality
operator but in this case a btree will be far more efficient).
The simple way to fix it is to add `unaccent(<column>)` in the index
trigram definition, but unfortunately `unaccent` is not immutable and
may therefore not be indexed. In order to make `unaccent` indexable, we
must declare it as immutable (see
https://stackoverflow.com/questions/11005036/does-postgresql-support-accent-insensitive-collations/11007216#11007216
for more information and how to do that).
With this patch, trigram indexes are created with `unaccent(<column>)`
if the function `unaccent` is available in the database, and for the
fields that are not declared with `unaccent=False`. Moreover, we issue
a warning when `unaccent` is available but is not immutable, in which
case most trigram indexes will be useless.
odoo/upgrade#3736
task-2551518
closesodoo/odoo#95943
Signed-off-by: Rémy Voet <ryv@odoo.com>
The master plan finally comes to an end.
Thanks to:
- odoo/odoo#87522 refactoring `load_views`,
- odoo/odoo#94337 refactoring `common.Form` to prevent changing
invisible fields in unit tests using `Form` instances,
- odoo/odoo#95729 refactoring the behavior of `groups=` in views,
- odoo/odoo#98551 removing the need of the `groups_id` many2many field
on back-end views.
The result returned by `get_view`/`get_views` can now finally be easily
and efficiently cached, in order to cache back-end views.
The goal of this revision is to cache the model views and fields
already post-processed for the web client
(with the modifiers, etc., already computed)
without group restriction.
Then, from this cached version, post-process group related features,
such as removing nodes restricted with a `groups=` attribute,
set the create/write button according to the user access rights to models, ...
Not including the groups in the cache key allows:
- to have less cached versions,
(otherwise it would be one cached version per different group combination)
- to not have to fetch the user groups to compute the key
(with the current cache key,
there is nothing to fetch from the database to compute the key)
Besides, post-processing the groups features
after taking the view from the cache of the view doesn't take a tremendous time:
- parsing arch from/to string with etree is fast,
- removing the `groups=` nodes using etree is fast,
- adding the `create="False"`, `write="False"`, `delete="False"` on the view
root node according to the access right of the user on the model is fast.
This allows way faster calls to `get_views` by the web client,
as the server no longer need, for each call, to fetch the views in database,
combine the inherited views, post-process the modifiers attributes, etc.
Timing tests are available on the pull request of this revision.
Part-of: odoo/odoo#99417
The cache key of _get_bindings was not super efficient.
The result of _get_bindings is cached,
but its performance was altered by the cache
key which requires to fetch the user groups for each call to
_get_bindings.
Besides, as there is a lot of possible group
combination, this resulted in a lot of possible cache keys,
and therefore a lot of cached values.
This revision aims to make _get_bindings more efficient
by:
- do not use the groups in the cache keys (less cached values)
- filter out actions not available to the user groups after
retrieving them from the cache
- use has_group to do the above, which is itself cached as well,
and therefore do not need to fetch the user groups
at each call to get_bindings.
In addition, move get_bindings from `get_view`
to `get_views`. If there was 3 views asked by `get_views`
(let's say kanban, list, form)
`get_bindings` was being called 3 times, through `get_view`
with each time the same arguments and therefore the same result :-).
Moving it to `get_views` allows to call it only once for all view types
requested, and for the web client it doesn't change much,
as it always request the toolbar/get_bindings through `get_views` only.
In addition, add the lang to the cache of _get_bindings.
it was actually a bug not to put it: if you had 2 users
with the same group set, using 2 different languages,
the user accessing first the get_bindings would cache
the action names within his language, and then the second
user would see the action name within the language of the first user
:-).
Before
```py
In [1]: %time for i in range(1000): self.env['ir.actions.actions'].get_bindings('res.partner'); self.env.invalidate_all();
CPU times: user 790 ms, sys: 104 ms, total: 893 ms
Wall time: 1.7 s
```
After
```py
In [1]: %time for i in range(1000): self.env['ir.actions.actions'].get_bindings('res.partner'); self.env.invalidate_all();
CPU times: user 23.5 ms, sys: 9.12 ms, total: 32.7 ms
Wall time: 36.9 ms
```
Part-of: odoo/odoo#99417
Part of the overall v16 SCSS optimization/restyle, task-2704984
- Converts dropdown into "nav ul li" structure.
- Removing of '.o_burger_menu_user'
- Removing of '.o_burger_menu_app'
- Removing of '.o_menu_sections'
- Removing of '.o_burger_menu_section'
- Some 't-key' not necessary anymore (thx to OWL2)
task-2812594
Part-of: odoo/odoo#88073
Co-authored-by: Adrien Dieudonné <adr@odoo.com>
Not entirely sure about TestAllocationRights. For TestEsEdiCommon
issue is quite obviously that it's inherited by tests which are
external, so when the `post_install_l10n` tag gets applied those tests
get run during "normal" l10n and they break.
closesodoo/odoo#98814
Related: odoo/enterprise#30825
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The linter would require flagging "Common" classes with
`post_install_l10n`, which is incorrect but innocuous before tag
inheritance, however it's incorrect and broken with tag inheritance.
Fix to only apply the lint to actual test containers.
Although eventually the analysis should probably run on the actual
classes, so that the "common" classes can be tagged and the children
don't need to be (since they inherit tagging from their parents).
Part-of: odoo/odoo#98814
The unconditional setting made a lot of sense before the new test
tags (95b4f2ab4b) when the test module
was a test tag: filtering the module out of the existing tags would be
difficult.
However since then the tags should only contain "actual" tags,
therefore inheriting tags (and tagging mixins or Common cases) should
not be an issue anymore.
Part-of: odoo/odoo#98814
*: base, mrp_account, product, mail, website_blog, website_event,
website_forum
This commit improves the button that allows to go to the backend view of
an object when you are on its corresponding page on the website. The
button is more visible and the user can see which object he is going to
edit. Note that this commit also:
- Changes the access key to translate a website page to ALT + T.
- Adds a new access key to edit an object in backend with ALT + E.
- Removes the possibility to duplicate a blog post (but this feature
will be reintroduced later for all models, generically) **.
**: Note that the duplication of blog posts actually had a mistake:
The controller to create a new blog post has been added with [1] where
it has been decided to not be a follower of the blog posts at their
creation. A new controller has been added by [2] to be able to duplicate
a blog post, to be consistent with [1], here also the user does not
become a follower of the new blog post (the copy). So far, so good.
Finally, [3] has changed the blog post creation controller so that the
user who creates the blog post is a follower of the new blog post.
Unfortunately the same change was not made for the duplicate controller,
which is a mistake. There is no reason to be a follower of the newly
created blog posts when you go through the add blog post controller but
not when you go through the duplication controller. The behaviors should
be consistent and there is no reason for there to be a difference.
[1]: https://github.com/odoo/odoo/commit/4c3b516a7b988d758a67ff19242e8ed0837d756c
[2]: https://github.com/odoo/odoo/commit/fe40538aff2b65f7719840c8e2d6e51e858f560f
[3]: https://github.com/odoo/odoo/commit/4bf9dc4078a5ca413539a6fd16400fd5aad46907
task-2889929
closesodoo/odoo#97353
Related: odoo/enterprise#30075
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
For reading one2many fields, we make 2 queries (in batch):
- One to search "id" the comodel
- One to read <inverse_field> in the comodel to group lines by record
(sometimes, this one is bypass because the cache already contains the information).
In many cases (> 80% of cases in our tests) we read a one2many field on
a single record. In that case, we can avoid the second query completely
(grouping all lines on a single record is trivial).
This reduces SQL queries by about 0.8% on all-install runbot builds.
closesodoo/odoo#99415
Signed-off-by: Rémy Voet <ryv@odoo.com>
For non-stored computed fields, `_modified_triggers` will traverse the
tree (at the cost of extra queries) only to know which record to
invalidate in cache. But in most cases, these fields have no data in
cache, so they can be ignored from the start, which allows us to prune
entire subtrees from the merged tree.
By example:
With simple write on `show_operations` of one `stock.picking.type`, the
`_modified_triggers` will fetch every ids (from database) of `stock.picking`
and `stock.move` related to this `stock.picking.type`
(For `stock.move`, it is because of the
`show_operations = fields.Boolean(related='picking_id.picking_type_id.show_operations'`))
In that case, there isn't any data of `show_operations` (`stock.move`)
in cache, then there are nothing to invalidate and
the `_modified_triggers` cost
is high (extra queries/processing) for nothing.
Then we cut parts of the tree when we know that
they won't invalidate anything (=> if the cache is empty for the field).
Also refactor the way to merge trees to be more efficient.
Performance improvements:
- For all tests at-install done by the runbot, we gain -+ 3.5% of
queries.
- In the example above, we reduce the number of queries (potentially
bottleneck queries in large DB) from 7 to 4.
- In term of CPU (without counting time in SQL), the new version is -+
20 % faster (on install of stock,purchase,mrp and with
--test-tags=/stock,/purchase).
closesodoo/odoo#76322
task-2780812
closesodoo/odoo#99274
Related: odoo/enterprise#30951
Signed-off-by: Raphael Collet <rco@odoo.com>
Prevent archiving in-use mail servers by displaying an error message that
lists where it is still used, allowing to easily identify what need to be
updated before being able to archive the mail server.
Additionally,
- prevent the use of archived server as a fall-safe
- when duplicating a mailing with an archived mail server, replace mail
server by the default one
Detailed explanation:
1. A check has been added that raise an exception when trying to connect to the
smtp server or send an email when the server is archived.
With that solution,
- testing the connection of an archived server displays an error telling that
an archived server cannot be used.
- if a mail is still sent with an archived server, mail are in error :
"Connection failed (outgoing mail server problem)"
This fail-safe ensures that no mail will be sent through an archived mail server
and that the user will get some feedback about it.
The same fail-safe for the incoming mail server has been added.
Notes:
- the connection will outlive the archiving of a mail server still allowing
to send email through the archived server until the connection is closed. But
connection are not kept for long so this shouldn't be a problem.
- it cannot be tested because the connect method return immediately in test
mode.
2. When a mail server is archived, an user error is raised if it is in-use.
The implementation relies on each module to override the method
"_active_usages_compute" in "ir_mail_server" to complete the list with
user-friendly message describing the active elements that could send mail
through the mail server. This has been implemented for:
- l10n_it_edi: server used to send e-invoice
- mail: optional server configured for template
- mass_mailing:
-- default mail server
-- active server configured for mailing
Mail server are referenced in other elements but are not active anymore, it is
just for temporary or history purpose. Those references doesn’t prevent the
archiving of the mail server:
- mail_message
- wizard survey_invite and compose_message
- res_config_settings
Task-2821516
closesodoo/odoo#91240
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
`_check_concurrency` was used to check if 2 people were modifying the
same record at the same time. It was doing so by setting a special
`__last_update` value inside the context that was later evaluted to
prevent some concurrency issues.
It was mostly unused, wasted a lot of cpu cycles and was not covering
all cases (e.g. pending write).
closesodoo/odoo#87756
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
In form views, when wrapping <field/> nodes
within a <t/> node to set a group,
the web client no longer set the field labels before the field.
Therefore, remove these <t/> node before sending them to the
web client.
e.g.
```xml
<group>
<field name="origin"/>
<field name="date_deadline"/>
<t groups="stock.group_stock_manager">
<field name="analytic_account_id" groups="analytic.group_analytic_accounting"/>
</t>
</group>
```
closesodoo/odoo#99266
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When profiling an HTTPCase the only result will be the starting of the
browser and the ready/ok code. All requests are in other thread
and are not profiled.
HTTPCase profiler will now patch the _get_profiler_context_manager
in order to enable profiler on all requests during this time
closesodoo/odoo#99119
X-original-commit: 77d110de242c8b8e9b0f09dcecad25c203f32535
Signed-off-by: Julien Castiaux <juc@odoo.com>
Before this commit, all the custom code for the widgets, form, list and
kanban views are always in OWL and have to be migrate to the new JS
framework.
This commit converts all the widgets, list, kanban and form views used
in the project app in OWL. Some JS tours has been adapted according to
the OWL views, the project right side panel has been reviewed since it
was LegacyComponent (in old component in OWL)
task-2944742
Part-of: odoo/odoo#98380
Some tests are randomly failling because /web takes more than 10 seconds
to load. A future pr will speedup /web but waiting for that a small
bump of the timeout should help.
closesodoo/odoo#99198
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The qunit loading is now arroud 15 seconds, breaking sometimes because
of the 15 seconds timeout.
A quick and dirty fix increases the timeout to 20 (freeze time)
An deeper investigation is needed to speed up this page.
Pregeneration of assets bundle may help
closesodoo/odoo#99163
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit converts the purchase dashboard to owl component
and removes its legacy code.
closesodoo/odoo#97590
Taskid: 2920812
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit adds a generic `action="action_some_method"` attribute to
the list view to allow for a custom action when clicking on a (record)
row. This feature mirrors the existing Kanban "action" attribute.
Note that in cases where the action method does not return a valid
action then the default action `act_window_close` will be called
instead (same behavior as the kanban view and buttons in general).
Supports "magic link" part of Task: 2882539
Part-of: odoo/odoo#97109
- reorder/rename/remove menu contents for "Inventory" and "Reporting",
including:
- removed "Forecasted Inventory" menuitem since this view is no longer
considered useful (code for view to be removed in separate commit)
- removed "Stock Moves" (moves report) menuitem
- renamed "Product Move" (move lines report) menuitem => "Moves
History", this will also be reflected in any "History" buttons that
open this view from other views.
- made "Inventory Report" menuitem visible only when applicable (i.e.
multi-location or consignment is active/debug mpde)
- made "Run Scheduler" menuitem only available in debug mode (
main_flow_tour updated to skip scheduler click since general flow is
expected to still the same/work)
Goal of renaming/ordering of menuitems is to clean them up and make them
more intuitive for users.
- "Run Scheduler" in mrp menus has also been made debug only viewable as
well to mirror the inventory change.
"menu" part of b2b task: 2882539
ENT PR: odoo/enterprise#29974
Part-of: odoo/odoo#97109
Purpose
=======
Make the onchange work for the properties fields. When changing the
container field, we need to update the properties definition.
Task-2852259
Part-of: odoo/odoo#95184
Purpose
=======
Add a new field "Properties" to be able to light customization of workflows
based on a parent model. Those properties acts in some ways like Odoo fields
without requiring specific columns e.g. add new properties on tasks of a
specific project.
Usage
=====
Define properties on a parent model (e.g. project) with
```
attributes_definition = fields.PropertiesDefinition('Message Properties')
```
It defines properties available on children: types, default, value, model for
relational properties,...
Use it on children records (e.g. task) with
```
attributes = fields.Properties(
string='Properties',
definition='parent_id.attributes_definition',
)
```
Technical
=========
Parent | Properties definition
------------------------------
The properties definition is stored on the parent, on a JSON field.
This definition contains the type of the properties, the default value,
the model of the many2one,...
```
[
{
'name': 'name',
'string': 'Name',
'type': 'char',
'default': 'Default Name',
}, {
'name': 'partner_id',
'string': 'Partner',
'type': 'many2one',
'comodel': 'res.partner',
},
]
```
Child | Properties values
-------------------------
The value is stored on the child, using a Properties field.
```
{
'name': 'Mitchel',
'partner_id': 1337,
}
```
When we read this field, we will automatically read the definition on
the parent, and merge both JSON into one, so the web client has the
value of each property, and their definition.
```
[
{
'name': 'name',
'string': 'Name',
'type': 'char',
'default': 'Default Name',
'value': 'Mitchel',
}, {
'name': 'partner_id',
'string': 'Partner',
'type': 'many2one',
'comodel': 'res.partner',
'value': 1337,
},
]
```
Integrity
---------
If we remove a property on the parent, we won't update the child value.
Instead, when we read the child properties, we will filter them based
on the parent. So the removed properties will be removed the next time
we write on the field.
In the same logic, the many2one existence is checked when we read the
field. There's no foreign key between the integer stored in the JSON
in the SQL row corresponding to the record in database.
Write
-----
We can write on the Properties field with a list of field definition
+ value.
Some types are not JSONifiable (like the date, datetime), they are
stored as string in database and parsed when we read the value.
In order to update the parent definition by writing on the child,
you need to add the dict key `definition_changed` or
`definition_deleted`. This is because we need to be able to know
if the definition has been changed without doing extra SQL queries.
Access rights
-------------
A user can add a many2one / many2many property to a model only if he
has the access rights to it.
Many2one / Many2many
--------------------
The model choice of a many2one / many2many properties was subject to
changes.
First implementation stored models in both parent and children to easily
spot changes and avoid complex queries when fetching records, trying to
synchronize them, ...
As this leads to storing a lot of duplicated content we choose to instead
reset the value on the child if the model has been change. We generate a
new name for the property. So it behaves like if we removed the property
and created a new one.
To be able to restore the old value (e.g. if by mistake we changed the
model, and go back to the old model), we store the initial states.
Task-2852259
Part-of: odoo/odoo#95184
In the `res.partner` form:
- the field `user_id` is set in base,
and is directly within the base res.partner.form form view,
within the `Sales & Purchase` notebook page
(which is in the base module despite what the tab name could make think)
https://github.com/odoo/odoo/blob/f294079a8946e88f0564dc96bf8a9531958697fe/odoo/addons/base/views/res_partner_views.xml#L343
- the field `team_id` is set in the module `sales_team`, and added
in the res.partner.form form view from this `sales_team` module
https://github.com/odoo/odoo/blob/f294079a8946e88f0564dc96bf8a9531958697fe/addons/sales_team/views/res_partner_views.xml#L9
Therefore, there isn't any obvious reason why the context `default_`
keys for `user_id` and `team_id` are set
only once the `crm` module installed,
neither why it only applies if you are a salesperson
(to the group `sales_team.group_sale_salesman`, sets in the view
`groups_id`).
If we have a look to the commit
f0b7600314
The goal described in the commit description is still achieved
by moving these default context keys in their respective module.
Besides, having a closer look in this commit,
`default_user_id` is directly added in the simplified partner form
within the base module, but is added through the crm module
for the regular form. Which doesn't make really sense.
Part-of: odoo/odoo#98551
The goal of this revision is to get rid of the `groups_id` field of the model `ir.ui.view`.
- This feature wasn't really known or used by most developers,
and not straight-forward to understand.
Removing it allows one less complicated thing to learn for developers.
Besides, thanks to odoo/odoo#95729,
changing the behavior of the `groups=` attribute,
we can easily get rid of this `groups_id` feature
by simply adding `groups=` in the elements of the views
using the `groups_id` field, it will have the same effect:
adding the elements in the view only for the users part of the specified group.
- By getting rid of the groups_id many2many field on ir.ui.view,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the groups_id groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
Part-of: odoo/odoo#98551
Currently dbs can only be managed via the UI in order to take
filestores in account: while it's possible to load/copy/rename/drop
databases via `psql`, that will not manage the related filestores so
the result of the operation is incomplete DBs and leftover filestores
littering the disk.
Seems like a good idea to add a CLI to perform the same
tasks. Currently the CLI calls into the corresponding service, rather
than both calling into (possibly better designed) unified APIs, but
that seems fine for an initial version.
The top-level `db` command acts as a db manager, with git-style
sub-sub-commands for the various operations:
- `load` to load a dump file into a database (with a specified name or
not)
- `dump` to dump a local db to a zip dump (pg_dump can be created via
the corresponding command so not a concern)
- `duplicate` and `rename`
- `drop` in order to drop both the database itself and the
corresponding filestore
Notably, `create` is currently left out because a database can
trivially be created by invoking odoo using a dbname which doesn't
exist, so doesn't seem useful.
`list` is also left out, because `psql -l` generally does the job.
closesodoo/odoo#97365
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- Remove FEC from res.config.settings - everything is now linked in the import guide (in enterprise)
- Compute debit and credit from opening_balance
- Update import templates for account.account, account.move, res.partner
- Small UI changes in base_import: add an action title and improve the template button design
task-2888243
closesodoo/odoo#96291
Related: odoo/enterprise#29627
Related: odoo/upgrade#3794
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
This patch discard the fields to delete from data structures like field
triggers, field inverses, and fields to compute.
This is quite useful when uninstalling modules. This commit fixes the
uninstallation of modules base_setup, bus, mail, web_tour.
closesodoo/odoo#98668
X-original-commit: 49398a769b2ec4965bf148f10b5e13d0a6c1acff
Signed-off-by: Raphael Collet <rco@odoo.com>
Xavier Morel