When you do a group by on field that is not present in the view,
this.fields contains all the model's fields, not only the ones present
in the view.
As we use the method 'has_active_field' to check if the field active is
available in the view, the value is not always correct.
To fix this we take the fields_view fields instead of fields.
This bug has been introduced in rev: https://github.com/odoo/odoo/commit/5b4f7c13f32f36d86805eb7865d8a077746181d8
When grouping by a field datetime in kanban view, the name of the
column is an abreviated datetime. Afterwards, when making a quick
create, the abreviated datime was set in the context and
used as default value. So it raised a tracebacks because the value
of the datetime was not in the correct format.
Now it's only possible to make a quick create if the type of the field grouped
is a char, a boolean or a many2one.
opw:727266
When the groups are loaded in the kanban view, a `read` is done on the
relation model to load extra fields.
This `read` was done regardless if there really were extra fields to
read.
This is a priori not a big issue, except if the user has no read
access to the relation model and can only perform a `name_get`.
This commit partially reverts 5b4f7c1 where `fields_view.fields`
had been replaced by `fields`, which could have been set to all
fields in the model.
This modification can sometimes lead to a problem, during the
fields value transformation. The ID, which wasn't given previously
is now parsed. When creating a new record, the field ID is not an
integer but a string (representing the virtual ID). If the field
is in the arch, it will be postprocessed
(see https://github.com/odoo/odoo/blob/saas-11/addons/web/static/src/js/framework/data_manager.js#L201)
and its type will become `id`. As this postprocessing is not done
if the field in the view, the parsing was on the original type
(integer) and not the special id type.
In the kanban view, if we try to group by a selection field that is
not defined in the arch, the key will be used as column name (instead
of the string).
A fix has already been pushed to load all the fields in this case
(see 0e6eb96) but these fields were not correctly used in this
particular case.
In the kanban view, if we try to group by a field that is not
defined in the arch, some features (like 'Add a new Column')
are not available because the case is not correctly handled.
To fix it, a RPC is done to load all fields in this case.
When a quality.alert was added from the kanban view, a traceback was raised
due to a coding error. In the fail function, the event is the second parameter.
opw:703281
Previous commit was cleaning the orphan and fuzzy translations of all main translations.
This commit does the same for all regional languages (that are not on Transifex).
To keep these files small, keep only the translated strings.
Fixes#14937
Some languages were published on Transifex in v9 but no longer in v10.
These languages were still using the outdated .po files
In some of these po, there were some fuzzy translations that were incorrect
(e.g. 'POS Order %s' - 'Kassa ostud', missing '%s')
These were not erased as still using the old translations.
Regenerate a correct .po file based on the new .pot and remove fuzzy
translations.
Fixes similar issue than raised at #14937
Some buttons in kanban records or event records allowed to open a form
view in edit mode. The feature was lost with commit
https://github.com/odoo/odoo/commit/46857d26#diff-fc48ba68abe25af0106d66b6ea2ec73eL116
Indeed the "do_switch_view" method signature changed but some calls
still used three arguments instead of two, losing the options param.
With this commit, it's now possible to set an arbitrary limit on any
kanban view by adding a limit attribut to the root kanban tag in a
kanban definition.
Do not forward-port.
Backport of rev 8a87c382ba
With this commit, it's now possible to set an arbitrary limit on any
kanban view by adding a limit attribut to the root kanban tag in a
kanban definition.
Goffin Simon