When converting a lead to an opportunity, there is a difference in
context than when going to an opportunity via the interface.
This leads to a difference when displaying a kanban view.
This commit adds what is needed in the context.
opw-632640
This wasn't anymore possible to open the Lead/opp
form of a planned call if it was of type opp.
Regression introduced during rev. 81f56c9eda
opw-631807
When setting a partner on the lead,
the on_change_partner method retrieves
the various partner field values.
title & function fields were omitted, without obvious reasons
opw-629374
Closes#5388
on_change_user was used to assign the first team in which the user is a member to the lead
When the user does not use the multi sales team, it therefore set a default sales team, but invisible to the user.
Stages displayed in the kanban view are the lead sales team stages. In a non sales team env, only stages with no stages are displayed for new leads
If you added a new stage, in the kanban view, the stage is not assigned to a team
The old-api model._all_columns contains information about model._columns and
inherited columns. This dictionary is missing new-api computed non-stored
fields, and the new field objects provide a more readable api...
This commit contains the following changes:
- adapt several methods of BaseModel to use fields instead of columns and
_all_columns
- copy all semantic-free attributes of related fields from their source
- add attribute 'group_operator' on integer and float fields
- base, base_action_rule, crm, edi, hr, mail, mass_mailing, pad,
payment_acquirer, share, website, website_crm, website_mail: simply use
_fields instead of _all_columns
- base, decimal_precision, website: adapt qweb rendering methods to use fields
instead of columns
When opening a lead/opportunity from the phonecalls view, we did not open the correct view (always the lead).
This will use the type of the crm.lead to determine which view should be used, opw 608493.
Sometimes, when you send an email in the chatter, a pop-up is displayed to fill the partner details
This case happens when the email address you send the email is not associated to an existing partner
In such cases, in lead, we use the company name and contact name to fill the partner name
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
When computing the duration to close or to open a lead, do not use some kind of complex computation with working days. It does not make sense to use the number of intervals with the number of days. The computation was incorrect and very slow.
Replaced by simple calendar delta.
- removed unnecessary changes
- rewrote on_change_user and get_default_sectoin_id to have a correct default section
- removed duplicated code in sales_team module due to code moving not correctly cleaned
improves the method to count opportunities/meetings/phonecalls in res_partner.py. It was bugged in two different way: the phonecall_count field was counting the number of meetings and not of phone calls, and it was in the try statement, so it might give an incorrect value if an exception occurs in the computation of opportunity/meeting
Also, remove useless meeting_ids one2many field in crm_lead.py and improves the method meeting_count
bzr revid: ged@openerp.com-20140507100954-1aqnd93iu5wsixob
- improved behavior of schedule a meeting, for both opportunities and partner, with correct
attendees and options;
- removed wizard to schedule a cal, jumping to the list view with correct default values
is sufficient;
- scheduled calls is now accessible using a group, accessible through sales configuration;
bzr revid: tde@openerp.com-20140417145645-cpohfrfpqnskpok6
Methods to override to specify the view/action to launch for many2one links
get_formview_action use get_formview_id to find the view to open. Therefore, it is simplier to override get_formview_id to tell which view should be opened
bzr revid: dle@openerp.com-20140416143755-07slguqn6zadqsg5
it is now possible to compute models allowing mass mailing using mass_mailing_campaign
module. This allows to completely remove the bridges modules, using a more generic
controller for unsubscription.
bzr revid: tde@openerp.com-20140416082851-8duo6yrwr5hwd8c2