To reproduce the bug:
1. Create two Belgian companies
2. Load the Belgian CoA for both of them
3. Go to the translation settings and add the French language
4. Access error
This is because we translate all the CoAs of all the companies, and not just the current company's COA. Therefore an access error is thrown because we modify the CoA of another company.
We can bypass this error by using sudo such that we translate every CoA and not just the one of the current company.
closesodoo/odoo#107643
X-original-commit: aac37b0de831e9d3b1ec8d4cead58c975bf06c5c
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
Currently there is a bug where the Chart of Accounts is not translated if the language is installed after the CoA.
Steps to reproduce:
1. Create a CA company (where both French and English are used)
2. Set the CA Chart of Accounts
3. Go to the general settings
4. Add the French language and switch to it
5. Go back to the CoA
6. The CoA is not translated
This is because the variable `installed` is wrongfully placed in the code. In the current flow, we install the new language, then we check the installed language, therefore the new language is marked as an already installed language. Therfore the `to_install` variable will always be empty.
This commit fixes this by first storing the already installed languages, then installing the new one, and then compute the ones to install making sure that the newly installed one will be used afterwards to translate the Chart of Accounts.
task-id 3091315
closesodoo/odoo#107500
X-original-commit: a3c3c3ccfc8e769ce39dbf38263f92e449b44abb
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
People asked to translate the States, because they had a use case, but
it's a minority. But other people also had issues on addresses because
states were translated. Translated fields can introduce mistakes.
Example: if I send a letter to: "Virginie-Occidentale", will United
States postal services understand that they actually have to send to
"West-Virginia"? That's an easy one, but there are more tricky ones.
Translations induce a lot of mismatch when people duplicate or edit.
Suppose a user edit "New-York" state and rename into "Californie"
because they do a mistake while changing the address of a partner the
same customer might receive it's letter in New-York or California,
depending on the language. Having states being translated might lead to
more issues, than not translated.
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
NULL
{"en_US": "Foo"}
{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}
{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
NULL
{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
task-id: 2081307
Co-authored-by: Fabien Pinckaers <fp@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
This commit adapts account's model to the new report engine introduced for v16, and updates the data files accordingly.
account.report model is now declared in community, together with the other models used by the reporting. This is done so that the tax tags can properly be created by the tax report and used on tax templates. All the actual computation logic stays in enterprise.
See enterprise commit for full details.
Task 2524389
Part-of: odoo/odoo#94125
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Purpose
=======
Add "Activate" button when selecting multiple languages, select multiple
languages when clicking on "Add languages" in settings.
Specifications
=============
`lang` variable in `base.language.install` changed from Selection to
Many2many to allow multiple languages being activated at once.
Hide globe icon for language fields from view mode (only visible when
editing). Remove state in base.language.install since it's no longer
need to keep track of the installation step.
Task-2662548
closesodoo/odoo#78287
Related: odoo/upgrade#2921
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> Fields
1) account.move -> narration
2) account.payment.term -> note
3) account.fiscal.position -> note
4) res.company -> invoice_terms
5) res.config.settings -> invoice_terms
Task Id: 2499504
X-original-commit: 0f3c7f153e8bd20f83b7d1df031634996d36935b
Steps:
- Install "Belgium - Accounting" and "Accounting"
- Add the Dutch language in settings
- Select a Belgian company
- Go to Accounting > Configuration > Chart of Account
- Select an account like "755000 Financial income - Foreign currency translation differences"
- Change the translation of the account name in English and Dutch
- Create a new company in Settings > Companies
- Select this new company
- Go to Accounting > Configuration > Settings, set the Fiscal Localization to Belgian PCMN and save
- Return in the first company
- Go to Accounting > Configuration > Chart of Account and check the translations you previously set
Bug:
The Dutch translation has been reset and the English one remains the same.
Explanation:
`process_coa_translations()` uses `spoken_languages` as seen here:
https://github.com/odoo/odoo/blob/bb31ce3bc6c0c7e1e101d93924eccea995206733/addons/l10n_multilang/models/l10n_multilang.py#L67
The spoken languages are defined here: https://github.com/odoo/odoo/blob/f4e7e06a1ff9756471d55138575c758f456b5905/addons/l10n_be/data/account_chart_template_data.xml#L10
This is why English is not affected.
The bug appeared with https://github.com/odoo/odoo/commit/c346e7af3314ce504fe3add9e9f6a4839bcad64a
It was meant to apply Chart of Account translations on the current company but applied it on all the companies. This reset edited translations on the other companies.
This commit refactors `process_coa_translations()` so that we can use the same logic on a single company while keeping the definition of the original function intact.
opw:2376334
closesodoo/odoo#63866
X-original-commit: 45e6309aa1d79d06c7110c86205781874ab44e30
Signed-off-by: backspac <backspac@users.noreply.github.com>
A method was written to copy translations from the template objects
(chart template) to the instantiated chart of accounts when installing
a multilang coa. (e.g. to have the translations on the accounts, taxes, ...)
The problem was that to call this functionality, this module inherited
a method, that was renamed in the meantime. The consequence being that
this method was never called.
We renamed the method correctly here.
closesodoo/odoo#52769
X-original-commit: bb31ce3bc6c0c7e1e101d93924eccea995206733
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before, only accounts, fiscal position, tags and taxes were
translatable, now account groups are too.
X-original-commit: da571b354293e852c1c4828f758eace8e6ededa4
If you:
- have a multilang COA
- create an account.account manually
- add a XML ID with structure {company_id}_{anything} manually
- reload COA translations (install COA language, install COA, set
installed COA since c346e7af3)
=> there is an error since the code try to copy translations of
account.account.template associated to custom XML ID.
fix: ignore this torcivous use case
fixes#36310
opw-2063207
closes#36544closesodoo/odoo#36659
X-original-commit: 0fc0b7484c48fbdcf549e199b5c8cabff3ab726c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When a COA is installed being loaded for current company, the
translations of taxes, account name, ... (in l10n_be, l10n_ca, l10n_ch,
l10n_sa) are copied from the templates to the accounting records.
This is done in `post_init_hook` which is correct since then
translations are available to be copied.
But when an accounting localization is already installed and we set it
to a company, the translations are not copied.
eg. install l10n_be for company1: accounts name are translated in
french and dutch, set company2 to belgian accounting: only original
language is available.
With this changeset, the translation copy is also performed when an
accounting localization is loaded for a company after it has been
installed.
note: if we install language for first times after setting accounting
localizations, chart of account are translated in that language.
opw-2047013
closes#35985
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Both the name and the tag_name need to be set as translatable.
As the tag_name is seen by the user for the configuration.
Unlike the financial reports that are linked to multiple countries,
the tax report is linked to just one country. This way it makes sense
to only make it translatable in multilang.
Task: 2042430
closesodoo/odoo#35436
Signed-off-by: Josse Colpaert <jco@openerp.com>
get_installed and _lang_get_id are both ormcached and correctly check
the context
Retrieving a res.lang from a code is a frequent action that can be
achieved with _lang_get (cf previous commit).
Using _lang_get ensure the active_test in the context is correct and
is not poluted with another context propagation issue.
odoo/odoo#35490 discussion is an example of bad context propagation
closesodoo/odoo#35504
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
In case two modules are using the same local name for their external identifier,
a conflict may occure.
e.g. the templates
- l10n_generic_coa.a_salary_expense
- l10n_be.a_salary_expense
will generate
- l10n_generic_coa.1_a_salary_expense
- l10n_be.2_a_salary_expense
As the previous search for in_xml_ids was using a domain
('name', '=', 'a_salary_expense')
both records were returned, making in_ids to have one more record than out_ids
Followup of review made at odoo/odoo#31510closesodoo/odoo#31604
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
On some chart of accounts, some records (e.g. account.tax on l10n_be) have
children and some are deactivated when the chart of account is created.
The children on the account.tax and templates were not created in the same order
The deactivated records were not found in the search.
Before this commit the translations did not match the right record on the
account.tax (e.g. 21% tax translated with a 12% name in Dutch)
Bug noticed with avw
closesodoo/odoo#31510
Signed-off-by: "Martin Trigaux (mat)" <mat@odoo.com>
When a record is created in a different language than English, empty
translations are created using the _set_ids method for translatable fields.
l10n_multilang makes the account translatable, an empty translation is created
when the CoA data is processed.
After the CoA installation, l10n_multilang transfer the translations of the
account templates to the related accounts.
No need to create translation terms again, use _set_ids to update the existing
translations.
This will prevent a cause of translation duplication, forbidden in the future by
160d657704
opw-1832071
Closes#24158
Countries with several official languages often have multiple names for their
states. Allow to translate the state name for such countries.
Some monolingual countries but, yet, with a need of translation of the addresses
such as China or Germany can add the same flag in their respective l10n_* module
Closes#19481Closes#20259
Bug:
Before the the fix, when trying to get all the translations of templates from a
specific model:
-All the translations for the templates of this model were catched first -> TT
-All the records of this model for a specific company were catched afterwards -> RC
Then, the linked between the translations(TT) and the records(RC) were made in function
process_translations.
But in some cases, a few records were removed and then it raised an error because the number
of translations was different than the number of records.
Fix:
Thanks to the function create_record_with_xmlid in addons/account/models/chart_template.py, all the records
created from a template have an xml_id in ir.model.data with str(company.id)+'_'+template_xmlid.name
So with this way, it is possible to catch only the records created from a template.
opw:767095
Ricardo Gomes Rodrigues (rigr)