The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.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
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
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>
Slovenian language, as many others languages, is not present in the
beta/master projects in Transifex.
For some reason, Transiflex removed all current translations, this was
already fixed in 12, but as there are not automatic forward-port for
translations, this is a manual forward-port.
opw-2060055
closesodoo/odoo#36374
Signed-off-by: Nicolas Martinelli (nim) <nim@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>
Josse Colpaert