- Create Journal Entries with analytic distribution
- Go in Journal Items list view
- Filter with 'Analyic is set'
=> The wrong entries are filtered
The problem is that the replacement of the domain for the search
has changed with a factoring of the function, which causes the
search replacement to occur with booleans, which is not needed.
closesodoo/odoo#130760
X-original-commit: 5d2accdf56ccd86c8797743f151ad80b614f0f77
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
create a recursion
Problem
---------
When you have an analytics plans which is the parent of another one, you
should not be able to choose the child plan as parent of this one.
A user has the possibility to do it; when he saves, we he gets the
error: Recursion Detected.
Objective
---------
Don't show the child plans of an analytics plan to avoid the user to
choose something that raises the error.
Solution
---------
Update the domain of the field `parent_id` to exclude the analytic plans
that are the children of the current plan.
task-3414188
closesodoo/odoo#128302
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
To reproduce
============
on journal items add filter (Analytic contains something) and group by Account, no lines will be shown.
Problem
=======
`analytic_distribution` is a Json field stored as string in database as follows: `{"id" : "percentage"}`, which explains why no result is returned as there is no trace for Analytics name.
Solution
========
following same [fix](https://github.com/odoo/odoo/commit/bc5b72937a1c79688f7f6dc1c8aeaa7eb4cb6744), we replace `analytic_distribution` by `analytic_distribution_search` in the domain of `read_group`.
opw-3391182
closesodoo/odoo#129263
X-original-commit: 05209fd295727cbbb5bf6a316f3c8873de6b2bed
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This commit's purpose is to allow the user to set the company_id of a project to False, meaning the project is no longer restricted for the user who does not have access to the company of the project. This change induces a lot of other small behavior changes/approximation. Since some fields (currency_id, resource_calendar_id, etc) were company dependent, we had to updates some use cases.
task-3084819
closesodoo/odoo#122144
Related: odoo/enterprise#41363
Related: odoo/upgrade#4947
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
To reproduce:
- Activate analytic accounting
- Create an analytic plan
- Click on Subplans
- Create a Subplan
- Come back to the list view of subplans (with the breadcrumb)
=> The new plan does not appear
The children_ids are not recomputed, so we inverse the logic.
task-3359643
closesodoo/odoo#125062
X-original-commit: c0bc5aedce0aa601e402c368fdf139c722a0fca7
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Currently, the field `analytic_distribution` does not appear in
the filters, while it should (to be able to filter `account_move_line`
for example).
We added Json to the filterable fields. If not overriden, it will
search on it like a String.
We also have to add a non-stored field to be able to define a search
function for `analytic_distribution`, to be able to search based
on the keys of the json.
closesodoo/odoo#121223
X-original-commit: 3d3e6847230d5cc9cd61a9bf83bef403a5b4b3ec
Signed-off-by: William André (wan) <wan@odoo.com>
The new backend version of read_group can simplify the
current overrides of read_group. Do it for each of them and
avoid making extra search (done with __domain) when it is possible.
Part-of: odoo/odoo#110737
The analytic distribution json field may contain a deleted analytic account.
This causes 2 issues:
- When retrieving plans - the analytic account ids are used to force additional plans (maybe applied by a model) - causing a record does not exist error
- Opening and closing the popup is required to 'clean' the distribution. this is not ideal as a draft invoice will not display the deleted account, but it is still in the json.
With this fix, the analytic accounts existence is checked, and the distribution json is saved without the deleted account.
closesodoo/odoo#117835
X-original-commit: ce5045d4ba5633790dfce1ef44c10b5770432829
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We created an index in the mixin, but the `init` was never called
as there was a missing `super` in `account_move_line`.
We also remove the index in `sales_project`, as it now is done in
the mixin (and we don't want different names for it).
closesodoo/odoo#115948
X-original-commit: 98a556031180cf72680b4f082a5c5d7b491742b7
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, if a single analytic line in the database
has an inconsistent company with it's anlytic account, all creation
of an analytic account was impossible because the constraint
_check_company_consistency is checked on the entire table.
This commit restrict the _check_company_consistency only
on the current record set.
closesodoo/odoo#115768
X-original-commit: 49bf7d149095e0c202cc53171a99eea8ec5b59b7
Signed-off-by: William André (wan) <wan@odoo.com>
When duplicating an analytic account, we want to make more explicit
which account is the duplicate and which one existed before.
task-3202027
closesodoo/odoo#114931
X-original-commit: d499b9da8ba1b46db0671f14658a55095c68921d
Signed-off-by: William André (wan) <wan@odoo.com>
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
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>
* = {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>
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
- 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>
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>
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
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>
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 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>
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>
Purpose of this commit to improve ux for timesheet app.
So, In this commit done following changes:
- make name field of account.analytic.line model translatable
by user.
- changes in report of timesheet:
- make generic table templete for timesheet.
- changes label for employee_id field column 'responsible'
into 'employee' and unit_amount field column
'time spent (hours)' into 'hours spent' and
'time spent (days)' into 'days spent'.
- move name(description) field column right of the task
column.
- add timesheet entry report for project.
- change internal project name when user has access to
multiple companies.
TaskId-2604773
closesodoo/odoo#75141
Related: odoo/enterprise#20242
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit moves the Track cost setting from account to analytic in
order to use it in modules depending on analytic.
This setting is based on a group defined in analytic
(analytic.group_analytic_accounting), this group is not moved.
PR : #72736
See odoo/upgrade#2706
task-2545084
The attributes field.depends and field.depends_context are problematic
for sharing fields across registries, because they depend on the model's
registry class, which may vary from one registry to another. In order
to make computed fields shareable, we have to move those values away
from fields.
For the same reason, field.recursive should not be inferred, because its
value may depend on the registry, although it is generally not the case.
Moreover, the flag recursive=True is set on a field when field triggers
are determined (on the registry). A compute method may be called before
the flag is set (if no update has been done yet), and that can lead to
incorrect computations.
This happened in test TestUsers2.test_reified_groups in module 'base'.
The user groups view was apparently determined without the flag being
set, and the view depends on the recursive field 'trans_implied_ids',
which was not correctly computed.
We thus force developers to be explicit about recursive computed fields.
The code now logs a warning when the flag is not set up properly.
The balance/debit/credit compute fields need the user to be part of 'account.group_account_readonly' in order to be calculated. This will avoid having an access error when a user who is not in 'account.group_account_readonly' accesses a view of 'account.analytic.account'.
We need it for the task-2195019. This task adds the possibility to display a m2o('account.analytic.account') field that can access the tree view with the 'Search More...' button.
Task-2195019
closesodoo/odoo#56554
Related: odoo/upgrade#1810
Related: odoo/enterprise#12680
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
From now on, it is possible to use the analytic account's code field in the "doesn't contain" filter.
Until now, only the name of the analytic account was processed when using this filter.
When using the "Contains" filter, both the name and the code of the analytic account were taken into account,
which was inconsistent with how the "Doesn't contain" filter worked.
Ticket #2368695closesodoo/odoo#61830
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Mainly transifex issues but also some errors found through 'grep' checks.
Fix typos and obscure english strings in xml contents, fields strings/helps, some docstrings, ...
ensuring correct translations base (and fallback when translations isn't available).
closesodoo/odoo#57276
X-original-commit: 4214f05d454bca2b60fda3a288d529c098e84f77
Related: odoo/enterprise#13053
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This provides a better API to search for records by name without the
formatting part (`display_name`).
This also simplifies all the overridings of `_name_search` that no
longer need to call `name_get()`. The call to `name_get()` is done in
method `name_search` in a generic way.
Do not crash if the commercial partner doesn't have a name.
opw-2158809
closesodoo/odoo#43533
X-original-commit: 90b55325894a248b0386d2f8c4b8568d278963f9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Gauthier Wala (gawa)