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>
This commit adapts account's model to the new report engine introduced for v16, and updates the data files accordingly.
account.report model is now declared in community, together with the other models used by the reporting. This is done so that the tax tags can properly be created by the tax report and used on tax templates. All the actual computation logic stays in enterprise.
See enterprise commit for full details.
Task 2524389
Part-of: odoo/odoo#94125
Currently, the 'similar lead detection' mechanism only considers email,
contact name, and partner name while finding duplicate leads in CRM.
After this commit, it will also consider the mobile/phone number for
the same. Note that the mobile numbers and phone numbers both will be
matched with each other while finding duplicate leads.
Task-2817884
closesodoo/odoo#88372
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = blog, forum, slides
For performance reasons, allow to increment multiple fields of the same record
within the same query.
With python tests.
Task-2663320
Part of odoo/odoo#79615
Since #96791 the currency is reset to USD when starting a test to be
less dependant of demo data when starting tests.
Unfortunatelly, some l10n_modules will add account.move.line demo data
leading to an error:
You cannot change the currency of the company since some journal
items already exist
An initial solution would be to delete the existing account.move.line
cls.env['account.move.line'].search([('company_id', '=', company.id)]).unlink()
This is only possible passing some context flags in order to disable some checks
existing = cls.env['account.move.line'].search([('company_id', '=', company.id)])
existing = existing.with_context(dynamic_unlink=True, force_delete=True)
existing.unlink()
Actually, unlinking account.move.line also creates other ones.
existing = cls.env['account.move.line'].search([('company_id', '=', company.id)])
existing = existing.with_context(dynamic_unlink=True, force_delete=True)
existing.unlink()
existing = cls.env['account.move.line'].search([('company_id', '=', company.id)])
existing = existing.with_context(dynamic_unlink=True, force_delete=True)
existing.unlink()
Finally, it looks easier to bypass all business logic leading to the proposed solution.
closesodoo/odoo#98736
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Trigger methods are defined as api.model but actually use self. Those are
therefore not model. Smart.
Spotted during Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#98661
Add the possibility to flag a HTML field as `sanitize_overridable`.
The sanitizer will then be bypassed if the user doing the operation is
part of the new group `base.group_sanitize_override`.
The "Settings" users are part of that new group.
If such a user wrote some HTML that would have normally been removed by
the sanitizer, then users without the right to bypass the sanitizer
won't be able to write on that field anymore.
Otherwise, it would sanitize the previously written data.
Such cases are detected, and the modification prevented by the system,
which will warn the user about it.
For instance, with a `field.html(sanitize_overridable=True)`: one being
part of `group_sanitize_override` could write `<script></script>`.
Then, someone not part of the group trying to add an element inside that
field like appending a `<p/>` -> `<script></script><p>New Content</p>`
would not be able to because it would go through the sanitizer and
ultimately, removing part of the original value:
`<p>New Content</p>` (`<script></script>` would be removed).
== Real use case ==
In the website builder, there is 2 editor rights:
- group_website_publisher: restricted editor
- group_website_designer: editor & designer
The designer editor can edit pages and views, while the restricted
editor can't do anything unless he is part of other groups.
In edit mode, the restricted editor will only be able to edit fields of
record he has access to.
For instance, being a sales manager allows you to edit a product
description on the website.
Being an event manager -> edit event. Slide manager -> Slides etc.
As those restricted editor are able to edit those fields, they are
(almost) always sanitized to prevent them to introduce malicious code.
Since those fields are sanitized, even admins / designer editor are not
able to fully use the website builder in such fields.
Some clients don't really care about that sanitation, they'd prefer to
avoid it as they trust their manager and would prefer to have the full
builder capability instead.
This is typically the case in small project (butcher, hairdresser,
reseller etc) and in SMEs.
With the new `sanitize_overridable` feature, they will be able to do
that, as the "Designer & Editor" group now also receive the group
`base.group_sanitize_override` (done in next commit).
Part-of: odoo/odoo#97398
Commit c06cee44fe corrected a nasty concurrency error in crons but the
serialization error was still logged.
closesodoo/odoo#98741
X-original-commit: 81c70a594a785fc0e32c9ff47c28c92b0f837923
Signed-off-by: Julien Castiaux <juc@odoo.com>
Since odoo/odoo#97347 we support default values for `t-field`
directives.
However this causes some issues in the case where we have: no value, no
default value AND force_display is true.
This is because the indentation for one of the lines in the compiled
code was not correct. (full explanation here: https://github.com/odoo/odoo/pull/97347#issuecomment-1222430659)
closesodoo/odoo#98714
X-original-commit: 2b605d3ccd55dc4f5b1ad44439411542e5b04b31
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Xavier-Do