=======
PURPOSE
=======
In list view, when handling in mass the opportunities and mark it as lost, it
should be possible to set the lost reason.
The reason would be the same for all the selected opportunities.
=============
SPECIFICATION
=============
On clicking of 'Mark as Lost', ask user the lost reason through wizard. and then
set that lost reason to all the opportunities selected.
- Remove the the group by 'Stage' on the lead search view.
- Remove the kanban view for the leads.
- Remove Stage column from the lead list view.
They get to use stages as soon as they are opportunities.
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
The step consisting to go back to the app switcher doesn't work in community,
obviously, so this commit make it active in enterprise only.
Also make the Settings app selector more robust by accessing it through its
xmlid, as we do for other apps and menus.
Starting from 32fb2f0940 if a lead is
already assigned to a partner instead of returning the already assigned
partner we ignore that, possibly reassign the lead and return either the
new assignment or ``False`` (if not in action=create and no partner_id
was provided).
This seems like an error which passed through and was never noticed as
the method isn't called much and only from wizards.
Either way, revert that. And remove the comment which apparently was
never updated.
In the new API, ``name_get`` doesn't normally lose sort information
anymore: the result of ``search`` (or ``browse(_search)``) is correctly
ordered and ``name_get`` sequentially resolves record names.
Thus the post-facto re-ordering mess should be unnecessary,
``records.name_get()`` will be ordered as ``records`` is.
- try to make better use of recordsets (and recordset APIs)
- remove pointless decorators
- remove redundant ensure_one
- make 'stage_find' a private method returning a recordset
- etc ...
Rather adding a group on the view to avoid Access
Error, than adding a try/except catching the
exception for opportunities and mettings count on
partner form view
Martin Trigaux