This commit is part of the preliminary work to rewrite the form,
list and kanban model. We want this new Model to only be aware of
field related information it needs (whereas in its current
implementation, the model stores all the information extracted
from the field node in the arch). This would allow to properly
manage multiple occurrences of the same field in views, that is,
each occurrence would be represented by a field component (if
visible of course), and that field component would use the field
information of the arch node it represents. To this end, we want
fields from not using anymore information stored in activeFields
in the record datapoint. Instead, we now call extractProps with
the whole fieldInfo (the information extracted from the arch), s.t.
each field can generate the props it needs from those information
(e.g. sub views for x2manys).
This commit doesn't remove the use of record.activeFields in
concrete fields (this will come later), but reworks the fieldInfo
object generated by parseFieldNode, and provide it to the calls of
extractProps. In fieldInfo, the `options` key is no longer inside
`attrs`, as it is now top-level, alongside several other generic
keys that have been processed (like on_change, modifiers...). For
that reason, a lot of extractProps definitions had to be adapted.
Part of task 3179751
closesodoo/odoo#113092
Related: odoo/enterprise#37266
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
As with fieldsToFetch in commit 25bf5a3fabfa9da5367e82d1c5713425c77bc373,
we will convert fieldDependencies into an array of fields.
We did it because it's easier to use and more natural to has an array.
Part of task 3179751
closesodoo/odoo#113482
Related: odoo/enterprise#37449
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit, is part of a series of commits that aim to simplifie
the concrete fields API.
In this commit we will remove update prop from concrete fields. Now each
field will directly use this.props.record.update to make changes, and
handle the save in fields that need to (e.g. priority). As a consequence
of this, the record props need to be mandatory.
task-id 3179751
Part-of: odoo/odoo#112792
Rewrite the whole chart template mechanism, removing the templates
stored in the database. The new format will mainly use CSV.
Speed up install time
---------------------
* About half of the time of installing a localization for the first time is
taken by creating the template records. This new in code format gets
completely rid of this.
* Creating the template records could often not be done in batch because
of parent/children relations.
* The instanciation of the accounts on the company has been entirely
reworked too, by
- optimizing the order of creation of records to avoid UPDATE queries
- using precomputed fields to avoid UPDATE queries
- updating the translation in batch
- deactivating logging in the chatter
- avoiding access rights checks by checking the rights at the start
Overall, when installing a chart template for the first time, it is 4
times faster because half of the time spent on saving the template in
the database is not done at all anymore, and the instanciation on the
company is more than twice as fast.
Reduce technical debt
---------------------
There is no need to synchronize the templates with the real records
anymore. No need to use hooks to copy the data from one to the other.
It is easier to change a template in a stable version, which can often
be necessary due to legal reasons (i.e. a change of tax rates, reporting
tags,...)
Two modules have been removed:
* `l10n_generic_coa`: since there is nothing left datawise in this
module, it can be integrated in `account` for free. It is just code
and CSV.
* `l10n_multilang`: the fields that this module modified to be
translatable are now always translatable:
- there was an issue when updating modules that deleted all the
translations because the fields were not translatable at some point
during the loading of the registry, then they because translatable
again but lost all translations because of the column type change.
- most devs are not able to understand all the languages needed for
all the localization available. Therefore, english has been added in
the sources in most localization to understand better issues while
debugging.
- no need to call post init hooks anymore, doing the sync with the
templates.
- more: see "Translations" section
Because most of the data is now in CSV, it is also easier for product
owners to edit, audit, modify files themselves, removing one layer
during trivial development processes when only data should be changed.
More flexibility for declaration
--------------------------------
The data declaration can now be done easily in python or CSV.
A nice feature is that you can declare everything at once, even for some
more complex chart of accounts:
* if you have to set default taxes on accounts, would need to
- declare the accounts because accounts are required on the taxes
- declare the taxes
- declare the taxes to put on the accounts
This would lead to scatter information in multiple files. Now,
everything can be declared in the same place and the loading of the
chart of accounts will do the 3 steps automatically.
* if you have a relation of child/parent, you would first need to
declare the parents then the children, and the loading would not be
efficient because done one by one. Now, everything is done in batch
automatically without having to think about it.
It is also easier to update fields on records where there was no field
for that on the templates, like
* setting a restriction for journals on accounts
* setting specific values on the company
* modifying journals and linking them easily by using the xml_id instead
of having to compute it manually
Translations
------------
Some countries have multiple languages (i.e. Belgium uses officially
French, Dutch and German, and the CoA also has an official English
version) and we must support the languages in all these countries.
All these translations are known, and hard coded without using out
translation platform (Transifex). We also like to have the English
version (even if an official one doesn't exist) so that support can be
done more easily in databases using chart templates in other languages
(especially using a non roman alphabet).
Because the translations were not on Transifex for these records, it was
really hard to maintain: the translation templates (`.pot` files) were
not easy to extract as the automatic export would give values mixing
both the CoA and the menuitmes, the fields' strings,... But we don't
want to translate the CoA as we already know the value.
Managing the translations in the `.po` files was also annoying:
- it is easy to forget that the translations need an update too
- it requires a special editor, special terminal commands that everyone
is not familiar with
- it is easy to make mistakes in the source string
The new format is the following: `field@en_US` where `field` is the
translatable field (usually `name`) and `en_US` is the locale code.
This allows to have the whole declaration on one line, everything in one
file. It also makes the process easier when debugging: instead of
searching for the translation in the `.po` files, it directly appears
next to the configuration of the account/tax/... .
Update of the code
------------------
The code can be updated using this script
https://github.com/william-andre/transform_coa
Forward ports can be managed too by stashing/resetting/checkout the new
modules or the changes in the modules updated in the same PR.
task-2687567
Part-of: odoo/odoo#110016
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- Create a parent analytic plan with no analytic account
- Create a subplan for this analytic plan with no analytic account.
- Create a subplan for the above subplan and create an analytic account for this subplan.
- create an invoice and try to put the created analytic account
Issue:
The analytic account is not availble (nor the subplan, nor the root
plan are displayed)
Cause:
We only fetch root plans (plans without parent_id) that have an
analytic account set. In this cas, the root plan is not retrieved
since the account_id is defined on the sub-sub-sub plan and not on the subplan nor the direct child of the root plan.
Solution:
Fetch all plans that have account_ids set and append the root plan to the relevant plans
opw-3107652
closesodoo/odoo#112419
X-original-commit: d725c74336feb27bd02e0f05491b24cb51627374
Signed-off-by: William André (wan) <wan@odoo.com>
We should allow distribution models to be to be editable top.
Then we need a new button to be able to see the form view.
t-3029083
closesodoo/odoo#111413
X-original-commit: e6b0315dc4886c40014a9d46128e841ea171b20c
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
An analytic account was searchable in an invoice with the Ref field.
Before this commit, it is not possible, while it should.
So we add it to the search domain.
opw-3119740
closesodoo/odoo#110135
X-original-commit: f5e24b8f7ba4291b0e5ea970da948215b83e6184
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
On first focus in an autocomplete field, the text content of the input element
is automatically highlighted.
closesodoo/odoo#109025
Task-id: 3117420
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
* = {account, sale, purchase, hr_expense}
When a plan is mandatory for SOL, POL or expenses, the flow should still be blocked when pressing the button, and not only when creating analytic lines.
We add the info in the context of the button, so automatic flows are still not blocked.
When the applicability rule requires a mandatory analytic distribution, raise an error upon :
- confirming PO,
- sending or confirming SO
- approving Expense Report by manager.
t-3040929
closesodoo/odoo#107166
X-original-commit: 8623a7850288828759db125b1054b0fed6b6b135
Signed-off-by: William André (wan) <wan@odoo.com>
If an aml has no product, it should not trigger a model that has a product.
So, we now define the fields that have to be checked on the model, instead of just being the ones given as parameters.
The way the field `company_id` impacts the model has also been changed.
The idea is that a model with a company specified should be better than a model without one.
But we also want that a model with 1 valid rule and no company is better than one with only a good selected company.
closesodoo/odoo#107165
X-original-commit: feff1a8a056f1fbbc852f7cf164e73abf83c4cc9
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, In account.analytic.account model due to the extra
space in name field string formatting. which generates the issue while
searching on accounts.
This commit fixes this issue by removing extra space and seperator.
closesodoo/odoo#105391
X-original-commit: bff34e0e8a8b2d211ef90ffea4f43c514e8cad28
Related: odoo/enterprise#33781
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce the issue:
- Have the modules `hr_expense` and `account` installed (not `account_accountant`)
- Create a new expense
- Change the category
- Click on analytic distribution field
=> Traceback
The issue comes from the fact that the account field is present but empty (we don't have accounting).
For the old and new account field, we have 2 undefined values.
We then do a shallowEqual of these, where it will compare length attributes, so traceback.
To solve it, we just give it a value false to the field instead of being undefined for the comparison.
closesodoo/odoo#105593
X-original-commit: face5b8f9134fc052ea09742667a610b508a4886
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Unused catch block arguments are now forbidden even when prefixed with an
underscore: if the argument on the catch block is not needed, the use of the
optional catch binding is enforced.
Part-of: odoo/odoo#105433
Before this fix, the constraint did not prevent changing the company to a bad one on an existing field.
We also remove the GROUP BY clause as it is useless.
X-original-commit: 2d5879cd8d84edcc16c55622b86c724f70055b03
Part-of: odoo/odoo#105259
The accounts shown in the widget could be shown while being in the wrong company.
Previously, only the plans were limited by the company.
closesodoo/odoo#105241
X-original-commit: 97d1afb9ff0ca88dfb0b6a8ed152e39d3db77279
Signed-off-by: William André (wan) <wan@odoo.com>
- Changes the tooltip of the account_prefix field
- Changes the name of the analytic_distribution field
- Changes the name of the group for the conditions
- Changes the size in the analytic_distribution_model_views of the analytic_distribution field
- Changes the name of the group for the analytic distribution field
closesodoo/odoo#103636
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Before this fix, user could include accounts in the widget from another company than the object's one when in multi-company mode.
It could cause problems with validation too.
Now we take the company of the object when getting the plans (or the current company if no object's company).
t-3040926
closesodoo/odoo#104150
X-original-commit: 21d754ddafee653d9958443accda2de747caed53
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Due to the deprecation of t-esc to the unique use
of t-out in the rendering template, this replace
every usage of it and ensures everything continues to
work as inteded. Removing deprecation warnings
polluting terminal
deprecation commit: odoo/odoo:9ce5bc8881ae06b613ef61eb07453b224f62bae6
closesodoo/odoo#103731
Related: odoo/enterprise#33037
Signed-off-by: William André (wan) <wan@odoo.com>
We had an index with the same name as would be generated by the ORM.
Instead of putting index=True as it is a bit of an hack, we just change the name of the index.
closesodoo/odoo#103945
Issue: https://github.com/odoo/odoo/issues/103473
X-original-commit: 819fa66546fbb53b808711b38c3296406c45c717
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
When a lot of components are trying to do the same `search_read`, they
are spamming calls to the server when they could be batched instead.
Instead of using `search_read`, we can also call `precision_get` which
is `orm_cache`d
To reproduce:
* Main settings: activate/check "Analytic Accounting"
* Menuitem: Accounting > Accounting > Journal Items
You should see a lot of calls of `search_read` to `decimal.precision`
closesodoo/odoo#103928
X-original-commit: 332a673b6b289761ae3c42d1bfa8effca475abf1
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Since odoo/odoo#95729
nodes with a `groups=` are completely removed from the views when
the user is not part of the group, instead of being made invisible.
In that PR, views have been adapted to add back fields, with invisible="1",
when they were required, for instance when they were used in a domain
of another field which was still there despite the user is not part
of the given group.
As `tree` views having `multi_edit="1"` where not considered
as editable views, the domain of fields in these views were not
validated:
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1460
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1321-L1322
while they are well required for the web client,
in `multi_edit="1"` this is possible to edit relational/many2one field,
and therefore it will do `name_search` calls using the domain of the
field, and therefore the fields used in these domains must always
be present in the views. Without it, a crash in the web client occurs
when attempting to edit the relational/many2one field.
This revision targets to consider the `multi_edit="1"` tree views
as editable, to make the field domains validated as they should be.
Hence, views are adapted to add back fields with `invisible="1"`
when they are required in domains of other fields.
Part-of: odoo/odoo#103790
The analytic distribution widget in the Analytic Distribution Model form displayed its selection field on a new line, making it too large and odd. This PR fixes the styling and simplifies the widget.
closesodoo/odoo#103282
X-original-commit: 73b11378b18a709537dff5b60373b40009a04a14
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
The `analytic_distribution` field is a Json.
It was stored temporarily as a char.
Search is not available yet, so we do queries by hand when we need to search on keys.
Also added a constraint on account_analytic_distribution_model,
so we don't have models with accounts specific to a company when the model has no company or another company.
It would cause an issue when looking at the models from another company.
X-original-commit: 7064c95aa04e5138bb12ae97acfee04ebb67cc0e
Part-of: odoo/odoo#103097
Analytic distributions that contain mandatory plans should be blocked from posting.
However, automatic flows (for example subscription invoices) should not be blocked.
For this reason, the context is used to determine whether the distribution should be validated.
closesodoo/odoo#102720
X-original-commit: 7b11af76598c0782ac2097d3cbeb718962be2537
Signed-off-by: William André (wan) <wan@odoo.com>
Add choices for the business domain on applicability rules, so rules are more precise
Also put 'general' as domain from the view when it's what should have been.
Make analytic field visible since owl migration (for sale and purchase)
closesodoo/odoo#102461
X-original-commit: c5867d5009a7fb448fff1be487b9e9c3e7945d4b
Related: odoo/enterprise#32421
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
`activeActions` is a set of boolean values determining what actions
(i.e. 'create', 'delete', etc.) can be performed on the current view or
subview (x2many).
Before this commit, the x2many fields used a different naming convention
than the one set on the views (e.g. 'canCreate' instead of 'create').
This caused mismatches when subviews would try to rely on the parent
view `activeActions` to define their own. This also introduced a bad
design where the "type" of `activeActions` would be determined by that
same mismatch.
Another issue was that the list renderer did not always check for the
existence of activeFields in its props, despite defining them as
optional.
This commit unifies the names of the active actions accross views and
x2many fields, while adding a "type" property to it s.t. its owner
can determine what context it finds itself in.
closesodoo/odoo#102115
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
On the smart button where you can see the accounts of the plan,
we want to be able to see all accounts of subplans too.
We also change the order of the analytic accounts, by plan's complete name then name.
closesodoo/odoo#102717
X-original-commit: a1f886e7babd6283e01eed686e043aabe72d7dd9
Signed-off-by: William André (wan) <wan@odoo.com>
The status indicator for optional plans switches between grey and green and creates a perception that action is required, when in fact, all values are valid.
For this reason, the status indicator only applies to mandatory plans (green: ok, orange: editing, red: invalid)
The grey status is removed entirely.
closesodoo/odoo#102503
X-original-commit: e2cd7f93d49cbdd60d6f84b465b042fae9389bb1
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
There are a few issues solved in this commit
1. Fetch plans is called too many times (Journal items List view). This is not necessary as plans are only required if editing
2. Plans are not fetched again if the product/account changes. This is because the record referenced by props and nextProps is the same, hence a change is not detected.
3. In list views - analytic account data is retrieved for each instance of the widget. To reduce the calls, a batched read is used instead
Improve test
closesodoo/odoo#101803
X-original-commit: 01d7579cfc8bf441f03d4467ef34a2d3bae015a4
Signed-off-by: William André (wan) <wan@odoo.com>
This commit does multiple things:
- The readonly mode of form view is removed but not for the fields.
it means that the fields in the view are always in edit mode except
if we force them to be readonly.
- The control panel is revamped to take less vertical space and shows now
the record editing (dirtiness)/validity status after editing the record.
- The record is saved only when leaving the view or by clicking the save
button when hovering the record status in the control panel.
- The record can still be discarded by clicking the discard button when
hovering the status text in control panel.
task id: 2822553
X-original-commit: 77824ad44b6945a9811120380747f87ef6362ae2
Part-of: odoo/odoo#101118
Co-authored-by: luvi <luvi@odoo.com>
Improve both tree and form views for the account.analytic.distribution.model
closesodoo/odoo#101001
X-original-commit: bb2820ad585ceed0f0562de3cd5f9ef8f1fac7d1
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according 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.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Only for terms containing Credit Note and expenses
closesodoo/odoo#97840
X-original-commit: 1754b094a66476a0bdb29fe60dc5583c03336c3f
Related: odoo/enterprise#30262
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Most of the extensions of `_name_get` are very similar and only want to
search for the given string in multiple fields.
A lot of extensions also don't take into account the negative operators.
Some implementations were also really outdated and needlessly
complicated.
closesodoo/odoo#86588
Related: odoo/enterprise#25608
Signed-off-by: Raphael Collet <rco@odoo.com>
`account.analytic.line` has been set as translatable in saas-15.1. In hindsight,
we can say it was clearly a bad idea as it introduced complexity and confusion.
This is why we are reverting it.
closesodoo/odoo#86203
X-original-commit: 0e0d9e76c6735a688707d51b54f8e978c168a1d9
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
2022-01-19 16:52:23 +00:00
Laurent Stukkens (LTU)andXavier BOL (xbo) <xbo@odoo.com>, Nicolas Seinlet <nse@odoo.com>
This commit adds an index on the user_id field of account.analytic.account
task-2700429
closesodoo/odoo#81907
X-original-commit: 9b7ad00143145030ca67d8a7bfbe44b700cd1573
Related: odoo/enterprise#23100
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>, Nicolas Seinlet <nse@odoo.com>
Aaron Bohy