Extract some cleaning wanted in #30759 but not related to language packs
- `amount_to_text` should work only on activated languages
- deprecate `load_lang` and rely on `_create_lang` or `_activate_lang`
- `trans_load_data` and `_load_module_terms` no longer silently activate languages
- pass explicitly parameters instead of relying on context content
- replace some `IrTranslation._load_module_terms(['base'], ['fr_FR'])` by `BaseModule._update_translations(['fr_FR'])` for higher level methods
- create `TranslationExporter` class to clarify the `trans_export` method (and clean dead code)
closesodoo/odoo#38859
Task-id: 2088290
Pad: https://pad.odoo.com/p/r.f6f789f8711d21314bd902972153ea9d
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This Commit is related to task ID 37726
closesodoo/odoo#40490
X-original-commit: 43000c7f2ed10e960f9611b004e3b48adb568c5a
Signed-off-by: Josse Colpaert <jco@openerp.com>
Instead of previous long methods, use a class to clarify what the
export actually does.
The TranslationModuleReader is written to copy the API of the
TranslationFileWriter.
This way, exporting translations is reduced to:
1. create a reader that will fetch all module translations (either
from db or from static files)
2. create a writer in a specific format (po or csv)
3. export the content from the reader to the writer
Simplify the writer by deducing modules from exported translations
instead of fetching it again in a oneliner (this way can benefit from
yield operations)
Remove the 'all_installed' possibility in modules as it was not
working (creating query with 2 WHERE clause).
The new methode _get_translatable_records works on a per model basis.
This will allow a big performance gain as the previous code was
making a .exists() for each record individually.
In the future, this method could be removed as the main goal is to
test the presence of the rare attribute _translate=False.
It was misleading as only forced for translations of type 'code' but
for the other translations, it was retrieved from the imported file
(the comment in a .po file or column in a .csv)
This will allow another optimisation in the next commit, moving to a
TranslationModuleReader instance
Instead, updating the translations of a module can be done directly
on the ir.module.module record
Remove one call to _update_translation by the actual creation of the
language
Instead of relying on the context content, pass explicit values for
overwrite and create_empty_translations
applu this to trans_load and trans_load_data
Adapt the test that was trying to create empty translations.
load_lang was a kind of hybrid method trying to active or creating a
language if not found. This was error prone.
Instead rely on two methods with clear purpose:
ResLang._create_lang(lang, lang_name=None)
- create a new res.lang entry using the locale of the server
return the res.lang record to match the API of _activate_lang
ResLang._active_lang(code)
- activate the given code lang
Most of the time, _active_lang is what is expected
tools.trans_load_data and IrTranslation._load_module_terms no longer
activate the language if not active.
Loading the translations should be explicit on an activated language,
it is too error prone to silently activate/create a language if not
found.
Remove lang_name from trans_load_data as no longer needed.
Only activated languages should be used in "amount to text" features.
If a language code of a not-used language is used, it should be
ignored for consistency with the rest of the interface.
Purpose
=======
Merge the form views of project tasks and fsm tasks so that it is
consistent and coherent wherever the user is in odoo.
closesodoo/odoo#40273
Taskid: 2070964
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Issue was blocking the system to confirm a SO/Invoice after redirection
from paypal.
In V13 is getting the value of the paypal_urls using
paypal_get_form_action_url() returning the correct string, not a dict
anymore.
Closing
opw-2119027
opw-2122833
closesodoo/odoo#40471
X-original-commit: b7f32e6451da75a9583d28686641fc328ab661da
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In e29c08969 source mode was reintroduced. Since complex template seemed
broken when it was edited, the feature of forcing source mode when there
is a `% if ` or `% set` template directive of 12.3 was reintroduced.
Since the direct breaking of the template was mostly solved with the
added line:
`options.prettifyHtml = false;`
the force source mode is not so much necessary and there was report that
it was not very clear.
In this commit it is removed, and if necessary could be reintroduced
later with clearer implementation.
opw-2123730
fix#40410closes#40421closesodoo/odoo#40458
X-original-commit: be30a3ba431cf24a5fcfdfedd0f9d9f73163c717
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
We do not want to block developers from using dynamic domains like:
domain="country_id and [('country_id', 'in', [False, country_id])] or []"
closesodoo/odoo#40445
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Open Mass Mailing in debug mode, create a new mass mailing,
choose a template for the body, check with the inspector the iframe.
The head of the iframe does not have the debug assets. This is because
the global variable relative to the debug mode gets temporary
overwritten before solving the promise.
For Gorash this has been done for:
* Performance as all the editor assets must be inserted into the iframe
assets
* As an indication to bugfixers that the fix must not be done in this
bundle as it is the exact same content as outside of the iframe and the
exact same content as previous Odoo versions.
Removing the override given that:
* If someone enable debug=assets he/she is aware of the performance hit
* A ticket has been opened because the iframe is hard to debug
without debug assets.
opw-2117649
closesodoo/odoo#40417
X-original-commit: 17c6952af3242c22bae2596f64b0addd04b9f9e0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Without the product_uom_category_id set you cannot edit this tree view. There is a domain [('category_id', '=', product_uom_category_id)] triggered from this view whcich is not fulfilled if we do not have the field set in the tree.
closesodoo/odoo#40186
X-original-commit: 4873e5ef3192480fdd3889331f13ff0e10ba5d6a
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The tracked field is now a relation to the corresponding ir.model.field.
This prevents potential privacy issues should the field be deleted or renamed.
closesodoo/odoo#39232
Taskid: 2088634
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If a Bill of Material is created without code (eg. when created as a new
group from a kanban view grouped by BoM) we would get a traceback
instead of an error.
With this changeset, we get a "You cannot create a new Bill of Material
from here." error if it is being tried.
opw-2124162
fix#38904closes#40289closesodoo/odoo#40457
X-original-commit: 32c13cd7d1387c0ea81a9bb5968d18c2b8f32051
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The mail_notification_paynow template expects a model_description
parameter or defaults to the model _description, "Journal Entries".
We add, similar to 4a3fd02af4 on sale.order, a type_name field to
get the correct type name in an extensible way.
Similar to 8c91b193fca3b, 65b6375cf3f9b.
opw 2120545
closesodoo/odoo#40245
X-original-commit: d1b66ca8ea46af1034e344dfd3eb99e00f5a2a34
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
This field was deemed redundant and thus removed from the view but we
forgot the use case where multiple valuation adjustment lines are
generated (eg applying a lc on multiple pickings) and the added value
by picking must be adapted manually (eg decrease one to increase the
other).
task-2125127
closesodoo/odoo#40454
X-original-commit: 3e6d6315adf1c33ec3fd5eb106defb0c80d7290b
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Reproduce the issue
- Install Projects and Studio
- Edit the projects app's kanban view
- Enable group by stage
- Close studio
- Add several stages
The stages are wrapped to the next line
Cause
I think the problem comes from c5f6802, we apply a wrapping to
all the kanban_dashboard items and in this cases the items are
the stages.
This commits apply the wrap only on non-grouped kanban dashboard.
OPW-2123031
closesodoo/odoo#40449
X-original-commit: f40478d5bacfdc44c76b0aac2f749549bbc58681
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Add and modify multiple fields in tree view for next next model:
- hr.expense
- hr.expense.sheet
- project.project
- planning.slot
- Field Service project.task
closesodoo/odoo#39441
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit introduces a nicer 404 page, which is basically the same layout as
the one used on Odoo.com.
Also, the 404 is now fully customizable, blocks can be drag'd & drop'd.
task-1966460
closesodoo/odoo#38901
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
It was not possible to search a fiscal position by name without a custom
filter.
opw:2124184
closesodoo/odoo#40404
X-original-commit: 72534d7ae21677b02d7cb26dd06d84d532be9514
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
It's the unique group needed for a kiosk attendance. Avoid to give
to much rigths.
id=2088561
closesodoo/odoo#38954
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Use correct company to get fiscal positions and properties
Ensure company used to fetch fiscal positions is always the correct one
when coming from a company restricted model (company_id required, or
related.required).
NB: if the company_id isn't defined, with_company doesn't change the
environment.
purchase: get_fiscal_position doesn't consider company_id ctxt key
others: properties were accessed with potentially the wrong company.
From now on, if one wants to force following operations to happen in a given company,
use with_company(company) or with_company(cid) to update the environment.
If a warehouse is created without code (eg. when created as a new group
from a kanban view grouped by warehouse) we would get a traceback
instead of an error:
```
The operation cannot be completed:
- Create/update: a mandatory field is not set.
- Delete: another model requires the record being deleted. If possible, archive it instead.
Model: Warehouse (stock.warehouse), Field: Short Name (code)
```
opw-2124162
fix#40233closes#40267closesodoo/odoo#40382
X-original-commit: b6caa179e17199b29a9ca4009c53acb378423926
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Lead/Opportunity type
=====================
In the settings, if ``group_use_leads`` is checked, we add the group ``use_leads`` to all users in the group ``base.group_user``
To know if the setting is checked, in the model ``crm.lead``, we compute this code,
```
self.env['res.users'].has_group('crm.group_use_lead')
```
In 12.0
=======
When we compute ``sudo``, we are as the admin user.
The admin user is in the group ``base.group_user`` and so, he can be in the group ``use_leads``,
so everything work fine.
In 13.0
=======
When we perform a ``sudo``, we keep the same user.
But the visitor is not in the group ``base.group_user`` (he is in the group ``base.group_public``)
So, the visitor can never be in the group ``use_leads``
Fix
===
To fix it, we just need to compute the method ``has_group`` as the super user (which is in the group ``base.group_user``).
```
self.with_user(SUPERUSER_ID).env['res.users'].has_group('crm.group_use_lead')
```
Task #2124421closesodoo/odoo#40418
X-original-commit: 8758bdc24297032ba8fd65f637a6990c6351dd27
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Reproduce the issue
- Install Events
- Set the english default format date to %d/%m/%Y
- Create an event & edit the date
The date is set correctly in the backend
- Edit the date of an event on the website directly
The date format is still the old one
Cause
The `from_html` method of DateTime was using `parser.parse` and
ignore the user's date format.
This commit changes `parser.parse` into `datetime.strptime` taking
into consideration the user's date format.
closesodoo/odoo#40415
X-original-commit: d00c0e317f8affbe8bea231972c2b6da70b9f240
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
-In CRM, click the CREATE button.
-Only enter a title for the new lead and directly click ADD.
-Click on the newly created lead to view its details.
Before this commit:
although a probability could be computed based on the stage of the lead, this
field has a default value and, at creation time, this value doesn't end up in
the list of values from which the `_write_probability` function decide whether
to recompute the probability.
After this commit:
The `_write_probability` function, renamed `_update_probability`, doesn't check
whether it should or not update the probability. It just does it. This function
is directly called in the `create`. `_should_update_probability` is called
before `_update_probability` in the `write`.
Task ID : 2081480
closesodoo/odoo#40411
X-original-commit: 483a94116629e418ebb224bad375747cf9ab3c1d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When changing fields in Manager -> Allocation Form, the name (display_name) was recalculated only after the form was saved or only after the description was changed.
closesodoo/odoo#39553
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Now, we should either use:
- A we-select (in the end, same as collapse except it does not push the
elements in the UI)
- A simple div to always display the elements
Part of https://github.com/odoo/odoo/pull/38959
task-2066614
closesodoo/odoo#38959
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Odoo's Mergebot