get_formview_action and get_formview_id are methods used notably in a
redirection called from a mail controller used in notification emails.
Those methods however are defined as cr, uid, id and are interpreted
as api.one when called by a new-api style method.
With modules being converted into the new API, those methods are called
as api.one and the result is encapsulated into a list.
To avoid having to take the first element of the returned list we decided
to simplify the call chain and migrate the methods as multi methods, using
ids instead of id. Various addons have been updated accordingly. A temporary
support of ids being an int / long has been added to avoid conflict with calls
using id (for example if javascript is not updated).
When the lead step is activated (`group_use_lead` is true), 2 dinstinct
tree views can be selected to display the opportunities.
Indeed, when the action "Your Pipeline" is selected, the tree view
`crm_case_tree_view_oppor` is displayed thanks to the method
`action_your_pipeline`. However, when the page is reloaded or the tree
view is saved in the custom dashboard, the tree view
`crm_case_tree_view_leads` is selected instead.
The fix is to specify explicitly in the action which view should be
chosen, accordingly to what is done in method `action_your_pipeline`.
opw-681488
opw-681734
To be displayed correctly on odoo app (In a given category and not only in all or hidden)
the module category in the __openerp__.py file should be one of these:
"Accounting",
"Discuss",
"Document Management",
"eCommerce",
"Human Resources",
"Industries",
"Localization",
"Manufacturing",
"Marketing",
"Point of Sale",
"Productivity",
"Project",
"Purchases",
"Sales",
"Warehouse",
"Website",
"Extra Tools",
'Accounting & Finance' will not work, as 'Project Management', ...
When grouping result the BaseModel method _read_group_fill_results add
the possible groups which had no result.
But, if the order of the group is not consistent, we can get really
wrong results. The code logic is expecting that the grouped result
gotten and the list of groups (returned by _read_group_stage_ids of
crm.lead) is in the same order.
If the _order attribute of the model is not enough specific (as was the
case in crm.stage) the inconsistent order would kill aggregation values
(displaying 0 instead of what should have been present).
opw-680952
When clicking on "Your Pipeline" in Sale app and clicking afterwards
on an opportunity, the form view "crm.crm_case_form_view_oppor".
But if you refreshed, the form view of a lead was used.
opw:677962
The button "Convert to opportunity" in the mail notifications
sent when posting a message on an opportunity just coudln't
work as it attempted to call the `convert_opportunity`
method without one of its required method parameter.
opw-680017
If `probability` is not being written,
`vals.get('probability')` is `None`
`None` < 100 is `True`
While it should not remove the `date_closed` value
when the probability field is not being rewritten
on the lead, but something else is.
opw-677273
The field generation is most of the time following the pattern
`field_<table name>_<field name>`
but in case of name clash (e.g. res.partner.category - id and res.partner -
category_id), the id of ir.model.field is added at the end of the external id
during the field creation.
The more flexible way to link to an ir.model.field is to use the syntax
`search=[('model', '=', <model>), ('name', '=', <field name>)]`
to avoid errors as in #12192 when the "first" external id no longer exists.
Fixes#12192Closes#12198
Martin Trigaux