- removed fields of 'res.partner.job' and 'res.partner.contact' models
- removed non-stored compute field 'base' of model 'account.invoice.tax' from anonymization list
- removed fields 'tax_amount' and 'amount_taxed' which no more exists in 'account.move.line' model
- removed field 'check_total' which no more exists in 'account.invoice' model
- removed field 'partner_phone' which no more exists in 'crm.phonecall' model
The 2 calendar notification routes were in auth
`none`. This causes no problem, but since they are
reimplementing the auth user mecanism, it is better
to set them directly in auth `user`. Moreover, they
are only called from webclient, when the user is
logged.
This commit also migrate them to new API (we forgot
them ....)
The _constaints definition is done at server load, not when a user is triggering
the check. The constrains are already translated, no need to try translating it
again.
When positioning an element in an editable list view, that element is
temporarily forced to display: block thanks to the class o_temp_visible
The rule is written in LESS thanks to:
.o_list_editable .o_temp_visible { display: block!important; }
which is ok for normal invisible form fields because it is written as
.o_form_view .o_form_invisible { display: none!important; }
which has the same priority but is defined before the o_temp_visible
rule, so the display is properly forced to block.
However, for some reason, there also is the rule:
.modal .modal-dialog .o_form_invisible { display: none!important; }
which has a higher priority than the o_temp_visible rule.
This is why appearing invisible fields in editable list view in modals
are at a wrong position.
The solution introduced by this commit is the safest: adding a new
rule to force display block!important on the selector:
.o_list_editable .o_temp_visible.o_form_invisible
In the dashboard view, it's possible to use the "Group By" feature.
However, when clicking on a link on any dashboard, a traceback might
show up.
This is because the context key `group_by` is kept when clicking on an
action. If the destination view is a list/kanban, and the destination
model doesn't have the field, the system will try to make a grouping by
a field which doesn't exist.
The solution is to remove the `group_by` key from the context, since it
doesn't make sense to send it the the destination model.
opw-684568
Ravi Gohil