This commit changes the behavior of the "Search More..." option in
Many2XAutocomplete and analytic distribution by making it available
as long as there's at least one record in the search results and by
renaming it to "View all".
task-3258625
closesodoo/odoo#126041
Related: odoo/enterprise#43660
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@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>
To Reproduce
============
- create many analytic plans and link them to an analytic account
- create an invoice and add couple of lines, stop when the page
becomes scrollable
- on the last line click on Analytic, the popup is positioned under
the line and we can't reach last plans
Problem
=======
- according to [getBestPosition](https://github.com/odoo/odoo/blob/16.0/addons/web/static/src/core/position_hook.js#L83), we try different options to position the popup and we take the first one to mach.
- in this use-case, the different positions tried by `getBestPosition` are overflowing because of the height of the popup.
Solution
========
limit the height of the popup to half size of page
opw-3252165
closesodoo/odoo#123542
X-original-commit: 3a7aaa36a487d101a70cb24c3c720a61f50a33ef
Signed-off-by: abla001 <abla@odoo.com>
This commit changes the arrow icon tags of autocomplete dropdowns to be
spans instead of an anchors.
This is because these elements are inert icons without href or handlers
attached, and they tricked the list keyboard navigation into considering
them as valid focusable elements.
X-original-commit: d253e41c44accd43cbd6478717e3978772076974
Part-of: odoo/odoo#122564
Allow users to find analytic accounts in the analytic widget if there are more than 7 results for their search criteria, by providing a Search More option.
Additional Enhancements include:
- remove the 'Add a Line' button. replace with an empty tag (no analytic account, remainder of distribution)
- remove the custom AutoComplete. this was used to set the active group on autoComplete focus, and to prevent propogation of click events.
- no longer keep track of the active group (editing plan). Instead pass the group (plan id) to the relevant functions.
- rename variables, for example request > searchTerm
- keep the header of the popup in place (no scroll when there are many tags)
- test the widget in list view (with the search more feature)
- add a new analytic account list view, as users should not multi-edit in the search more dialog
Current behavior before PR:
Users were forced to type the entire analytic account name if they had many analytic accounts with similar names.
forward port of 36391b9aea82091bf7b689658e07149860b01a61
Desired behavior after PR is merged:
A "Search More" option is added to the Autocomplete options when there are more than 6 analytic accounts found. The Search More option provides a SelectCreate Dialog where users are able to find the required analytic account easily. Users are able to select multiple accounts by checking the items in the list.
Task-3180055
Forward port of bef8e00d78f439936534cef8b2fd8313f03f3b1c
X-original-commit: 9f12669bcc1f23198d12a97b31feb6cb82894e11
Part-of: odoo/odoo#122424
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@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>
Steps to reproduce:
- Activate Analytic Account
- Create a Service Product - create project on order
- Create a quotation with the product
- Confirm the quotation
- Go on the project -> analytic account is "order # - partner_name"
- On the quotation - Create Invoice
Issue 1:
- The invoice has "order #" has the analytic account and not the "order # - partner_name"
Issue 2:
- if you create an invoice and wants to select the analytic account
you cannot search it by the partner name, only by the "order #"
Cause:
When confirming the quotation, we create an analytic account. The
default name of the analytic account is the order name:
https://github.com/odoo/odoo/blob/bba5b6a440544151cc610bbc6848adfbadb38bfb/addons/sale/models/sale_order.py#L1416
Why is the analytic account displayed correctly on the project?
Because we use the `get_name` is triggered:
https://github.com/odoo/odoo/blob/bff34e0e8a8b2d211ef90ffea4f43c514e8cad28/addons/analytic/models/analytic_account.py#L115-L123
In the analytic distribution view, we only render the name of the
analytic account as it is defined primarly.
opw-3165655
closesodoo/odoo#117770
X-original-commit: b709a4491074169f6203ba98dec8847036262d6d
Signed-off-by: William André (wan) <wan@odoo.com>
Since this component is imported and used in many places, it is more
convenient to move this component a core component instead of a
component made exclusively for the Many2ManyTagsField component.
This change makes the usage of TagsList possible by SelectMenu, which
would create issues as the fields folder should not be imported in
other modules.
Part-of: odoo/odoo#115799
This update contains the following commits:
[IMP] implement .alike suffix on props
[IMP] release: add version number on App
[IMP] app: add name as a config option
[FIX] runtime, compiler: fix refs getting set or unset incorrectly
[FIX] compiler: call translate function with correct string
[FIX] compiler: properly handle readonly attribute/readOnly property
[REF] blockdom,compiler: implement properties
[REF] tests: move properties tests in own file
[FIX] compiler: dynamic value on inputs doesn't turn 0 into empty string
[FIX] components: do not crash when binding anonymous function
More details at: https://github.com/odoo/owl/releases/tag/v2.0.9
Note that this owl update required a few adaptations in Odoo code. The
main problem was that some code would access references after the
component was unmounted. However, Owl is now stricter and properly
remove the reference.
closesodoo/odoo#115991
X-original-commit: a2952026f23858a8d34dcdab4ec8b467f7fc9bcf
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie <ged@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>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@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>
In the profit and loss report, if you go to "Analytic Group By" and select
'Search More' (need more than 7 plans), there is a traceback because
"True" is not a valid JSON.
This PR fixes this by changing "True" by "1" like other occurrences
of multi_edit parameter.
opw-3222611
closesodoo/odoo#115422
X-original-commit: 687a166e8c089a650c99eefe9d604c8c2762e1b7
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Beckers Thomas (tbs) <tbs@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>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@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 value prop from concrete fields. Now each
field will directly use this.props.record.data[this.props.name] to
access their value, As a consequence of this, the name props need to be
mandatory.
task-id 3179751
closesodoo/odoo#113495
Related: odoo/enterprise#37464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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>
Julien Carion (juca)