Method `get_default_fields`
===========================
Currently all the methods beginning by `get_default` are used to fetch their default values, usually by looking in the ir.config_parameter table.
As several methods `get_default_fields` have been defined in res_config classes, it better to define it in base and calling to super to avoid side effects like the following example
- 2 classes that override the same class and define the same method. In that case one method will never be called, as it is ovewritten by the other.
Method `set_fields`
===================
Currently all the methods beginning by `set_` are used to set their values, usually in the ir.config_parameter table.
As several methods `set_fields` have been defined in res_config classes, it better to define it in base and calling to super to avoid side effects like the following example
- 2 classes that override the same class and define the same method. In that case one method will never be called, as it is ovewritten by the other.
Methods `get_default_foo` and `set_foo`
=======================================
This commit deprecates the method starting with `get_default_` or `set_` in the res.config models. A warning is raised in that case.
* Set the blocking warning if the user enters a 'Client ID' without
any 'Tracking ID'.
* 'Google Analytics in Dashboard' field is visible only if
'Google Analytics' is checked in website settings.
* Get/Set the value of 'google_analytics_key' and
'google_management_client_id' from 'website' model instead of
'ir.config_parameter' on 'Google Analytics' wizard.
* If ID is set on 'Google Analytics' wizard then activated the related
features and populate fields in website settings.
It now update the website settings parameter use_google_analytics_dashboard
so that the settings are correctly updated with the user choice.
Implementation is changed so that the dashboard uses a jsonRpc call instead
of directly calling ir_config_parameter set_param.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Also, reset security_lead when use_security_lead is unchecked to avoid it to be used in further computations
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Various code using the sale_note field (default terms and conditions)
is updated to check the use_sale_note field that is the setting
enabling it.
This is a preferred solution compared to resetting sale_note each time
use_sale_note is set to False in order to avoid loosing the data
users may have entered in sale_note field.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Also, reset po_lead when use_po_lead is unchecked to avoid it to be used it further computations.
According to usability experts configuring a sales team alias should
be done directly on the sales team view and not through an hidden
and strangely configured settings.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Also, correctly reset manufacturing lead time
Settings now correctly use an ir.config_parameter telling whether to
use or not manufacturing lead time. An onchange is added in order to
ensure that lead time is not still used by code although the settings
is unchecked.
This commit fixes
* `default_alias_email` is now called use_mailgateway to better reflect its use. When
unchecked the alias_prefix value is set to False in order to
reset the alias.
* empty list message displays receipts alias only if the mailgateway
option is activated
* some code cleaning so that get_default_ and set_ methods are put
into a sole method in order to lessen code size
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Also, remove deprecated generation of alias on sales team.
According to usability experts configuring a sales team alias should
be done directly on the sales team view and not through an hidden
and strangely configured settings.
* portal, sale
Some primary buttons had both the 'btn-primary' and 'btn-default'
classes, which is wrong. In standard bootstrap, the 'btn-default'
class seems to be masked by the use of 'btn-primary' but it is not
the case in some of our themes.
It is still possible to have negative and positive quants in the same
location because of returns: if you send something to the customer that
is not there and you return it, you will still be able to reserve the
returned goods to send to another client.
Before, if you would do an inventory adjustment, it would not take into
account these returned quants and their negative counterpart, which made
them difficult to get out of the system.
This fix takes them into account by creating two movements for one
inventory line: move the positive counterpart to the inventory location
before getting back from this location the same quantity.
This way, even if you have 0 as quantity on hand but you have those 2
quants, it will eliminate them. (if you are increasing the stock, part
of the process might have done it automatically already).
Test cases contributed by @jir-odoo
Cherry-pick of be9dce625c
If some required fields are not present in the created values, they are computed
based on the onchange.
This was introduced at 5c4765130 to allow to import sale order lines without
specifying uom.
If sale_margin is installed, the same issue will occure as it assumes there is
a value for product_uom
Add test, courtesy of Mourad Elhadj Mimoune, Akretion
Closes#17613
Purpose
=======
The new kanban status history in the chatter is not clear for the end user.
Specification
=============
When the state of a task is change the chatter should display the kanban state custom label instead of the kanban state
This reverts commit 174d7e8e49.
The default language is the language if no lang corresponding to
the current language is found. Thus the browser language if available in
languages has priority over the default language.
opw-746776
closes#17637
With the new views, the class `o_field_widget` is added on every field widget
and is styled with `display: inline-block`.
The dashboards used to display graphs in full-width so this behaviour is
restored.
This option hadn't been implemented in the new views.
It allows to display informative explanations as tooltips on column over.
It can be set on a many2one field in the kanban view, e.g.:
```<field name="stage_id" options='{"group_by_tooltip":
{"<tooltipFieldOnStageModel>": "<ABeautifulTitle>"}
}'/>
```
An extra RPC needs to be done on the many2one relation to fetch these additional
fields and the data are stored in the datapoint under the key `tooltipData`.
Yannick Tivisse