When trying to merge partners, an sql error may be violated (e.g. unique constraints).
In this case, catch the error and delete the problematic record as it will no longer be relevant with the old partner and left unconsistant data in the database.
Bug was that when you click on meeting button from a res_partner form (Customers in menu), the button overwrites the context to use the active partner as a default in the calendar meeting. By consequence, the context overwritte the default partner who are the creator. Now the context could be removed from action and that is in get_default for partner_ids (from model calendar_event) that we add the creator AND the active_id if from a model res_partner.
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
* remove old 'day', 'month', 'field' and replace them by the actual
date/datetime field
* remove weird cast to char when creating the view to prevent crash
when grouping on them
* remove duplicates (such as 'creation_date' and 'create_date')
* fix typing errors (field type date defined as a datetime in the
postgres view)
* fix search view definition
opening_date and date_closed were cast to char but are supposed to be
dates. When you try to group crm_lead_report by one of them, postgres
was not happy. Now, it properly tells postgres that they are of type
date.
This was added in master-apiculture at f1f16a8 to
permit special function fields that return
structured JSON-like data.
This is unnecessary and caused typing problems, for
example for the type field of ir.model.fields, or
when you decide to store them.
It is simpler to explicitly declare these fields
as fields.Char and have them serialize their results
to JSON strings, or to declate them as fields.Binary
and return any opaque data they want.
crm claims and helpdesk reports should be in Sales Report menu, not in project
The sales report menu is now defined in sales_team, which is a common dependance between crm and sales, instead of redefining this menu in each modules
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
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
[MERGP] Inline Searchview
This task split the searchview in two parts: SearchView and SearchViewDrawer. The drawer is displayed inside the main view and the searchview stays in place. It also changes the scrolling behavior of the web client: the main view area can scroll without affecting the UI (so the various menus stays in place)
Because of this, other large changes have been made:
the drawer has been redesigned,
the Custom Filter widget has been split in two (Custom Report and SaveCurrentFilter),
the main view is now scrollable, so the UI stays in place and only the view can change
The text 'Group By...' has been changed into 'Group By' (most addons had to be modified)
bootstrap classes are used when it makes sense (for example, badge)
the left menu is also scrollable (separately from the main view)
It is likely that some stupid bugs have been introduced. Please don't hurt me.
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.
- now having a website sales sales team in website_sale;
- temporarily crm accepted as a dependency of website_sale (will be improved when sales team are
taken out of crm);
- removed website_sale_crm unnecessary module + dead code
- removed shopping cart state + its management
- added acquirer and transaction fields on sale order
- azdded use_opportunities and use_quotations fields on sales team like use_leads
- 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