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
Josse Colpaert