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
- remove backward compatibility method `case_mark_won` and `case_mark_lost`
- change signature of `find_stage` method, by setting team_id optional, since
we can get if from `self.team_id`
- remove unused methods in crm_lead.py
- remove unsed code in base_merge_partner.py
- remove unused method in res_partner.py
- regroup view definitions per models (almost 1 file per big model)
- remove isolated crm_report.xml
- moved content of crm/crm_lead_menu.xml to crm/views/crm_lead_views.xml
- moved content of crm/sales_team_dashboard.xml to crm/views/crm_team_views.xml
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', ...
Author: User who logged the activity in the chatter ----> Created By
Responsible: User assigned on the lead ----> Salesperson
Salesperson filer = Author. --> Same label : Created By
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
Purpose:
Goto 'Contacts' menu, select any Partner and click on 'Activities' state
button. The activities are read-only.
'Activities' is not created manually, so why 'Create' and 'Import' button
in Activities tree view?
'Create' and 'Import' buttons are not useful in 'Activities' view.
Jeremy Kersten