Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
steps to reproduce:
- enable analytic
- open journal items in list view
- select one item, set an analytic account
- select the same item, click on the analytic account, click on the save button (floppy disk)
- pop up opens
- close it
Issue:
Traceback
Cause:
In multiEdit mode, the main element cannot be focused in
opw-3463911
closesodoo/odoo#136576
X-original-commit: 93e553c211e1b74c0e712e387290db6455cf0e3d
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
*: analytic, base_automation, loyalty, mass_mailing, project, web, web_editor, website
This commit adds many new documentation of options and their usage for
fields. This makes them more usable and customizable in Studio, and adds
documentation for developers to know the type of expected option.
Some options that might lead to issues or that are too technical have
been removed, as they are not relevant and not required in most use cases.
task-3469741
closesodoo/odoo#134858
Related: odoo/enterprise#47148
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This partially reverts commit da50ce31ae825ef9f4b527553a2e2caec970d290.
Whilst the behavioral changes done in the task are correct, the wording
is not optimal and was better understood by users before this change.
Task-3483936
closesodoo/odoo#133511
Related: odoo/enterprise#46503
Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>
In this commit, all usages of env._t() are replaced by _t().
In templates files, env._t() didn't work because terms used
in attributes where not extracted into the translation files.
Only string are exported from .xml files to translation files.
So, to make it works, we set a variable that is then used
in attributes.
For example :
<t t-set="string_to_translate">String to translate</t>
<Dialog title="string_to_translate>...</Dialog>
task-3292454
closesodoo/odoo#131390
Related: odoo/enterprise#45631
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
Improve gettext to directly handle value injection within translations,
removing the need for sprintf.
closesodoo/odoo#123932
Related: odoo/enterprise#45370
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Steps to reproduce:
- Activate "Analytic Accounting" in Accounting settings
- Go to Accounting / Configuration / Analytic Accounting / Analytic Accounts
- Create an Analytic Account with a very long name (i.e. +100 chars)
- Go to Expenses
- Create an Expense with the created Analytic Account in the Analytic field
The display of the labels in the form view should break because the badge is too
long and is taking all the available width.
Solution:
Limit the width of tag badges in "analytic_distribution" widget as it is done in "many2many_tags" widget.
https://github.com/odoo/odoo/blob/2f47df6663b65c4f6b6ec61f956c453e97563462/addons/web/static/src/views/fields/many2many_tags/many2many_tags_field.scss#L47-L49
opw-3322688
closesodoo/odoo#131136
X-original-commit: 32fc4d44446a15b215c3f61cb2b35fa6f4ecb95b
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Miscellaneous improvements:
1. In analytic tags, the percentage is now a prefix.
2. In the widget, 0% accounts are now hidden.
3. In the analytic items list/pivot views, it is now possible to search by:
- Financial Account.
- Cross by.
4. By default, the pivot view is now grouped by plans and then analytic accounts.
5. An "Analytic Reporting" menuitem that opens the pivot view is added in Reporting > Management.
task-3446504
closesodoo/odoo#130971
X-original-commit: adb8ec875c9b4e299147c46dc60a87fd26fff91f
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
- 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>
In a previous commit 8bfa76a, _lt() returns _t().
So, in this commit, all usages of _lt() are replaced by _t().
task-3292454
closesodoo/odoo#130179
Related: odoo/enterprise#44906
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
This commit fixes a really old grammar error in the help message of the
message_needaction_counter field.
Before this commit: “Number of messages which requires an action”
After: “Number of messages requiring action”
The subject of “require” is “messages”, which is third-person plural, so
it can't take the -s suffix.
closesodoo/odoo#129468
X-original-commit: 0d10cfeaa56d5df23df05f436d353978043f4a71
Related: odoo/enterprise#44509
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
This commit adapts the code in addons w.r.t. the introduction of
the RelationalModel.
Main changes that were requested are:
- record datapoints no longer always have an "id" key in their
data (they still do if the id field is in the view), so we use
record.resId instead
- the new model is based on fined-grained reactivity, so several
components that previously relied on onWillUpdateProps to update
their internal state no longer worked. Typically, using the hook
"observeRecord" is the way to go now.
- specialdata are no longer handled in the model, so the components
needing specialData can use the hook "useSpecialData"
- more generally, all overrides of models (RelationalModel or
KanbanModel) needed to be reworked.
Part of task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@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>
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
Jorge Pinna Puissant