This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
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'`
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Task 1843603
* src_model is redundant with binding_model_id
* multi -> binding_view_types (if empty => all views) (maybe should be
empty by default yo?)
* in convert, type => rec.get(type) but no @type possible on <act_window>...
* removed deprecated auto_refresh & auto_search (not used anywhere (?))
closesodoo/odoo#24738
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The purpose of this commit is to clean the user interface of local incoming
mail server and also update the script field default value
and configuration as per new script (from openerp_mailgate to odoo-mailgate).
task-1891157
closesodoo/odoo#33072
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Purpose: small cleaning of code linked to mail.mail model in order to
avoid unnecessary overrides
* create mail: default_fetchmail_server_id in context should be sufficient
as it is the base mechanism of default_get;
* write: unused in codebase. Anyway we should not write on mail and if it
is the case giving fetchmail_server_id directly should be the correct
way of doing it;
In case of a clean_context use we might loose default_fetchmail_server_id
key. It is used notably for tracking message generation. In that case
this information could be lost. However the whole concept of propagating
a fetrchmail_server-id from incoming mail server to outgoing emails (as
mail.mail is used only for sending email) is strange and does not require
so much specific code.
Sub-part of task 1853147 (pre-cleaning before implementing mail gateway
improvements)
Linked to PR #32974
Odoo Translation Bot