2009-10-20 10:52:23 +00:00
# -*- coding: utf-8 -*-
2006-12-07 13:41:40 +00:00
##############################################################################
2010-05-14 09:57:41 +00:00
#
2008-11-18 14:39:15 +00:00
# OpenERP, Open Source Management Solution
2009-10-14 12:32:15 +00:00
# Copyright (C) 2004-2009 Tiny SPRL (<http://tiny.be>).
2006-12-07 13:41:40 +00:00
#
2008-11-03 18:27:16 +00:00
# This program is free software: you can redistribute it and/or modify
2009-10-14 12:32:15 +00:00
# it under the terms of the GNU Affero General Public License as
# published by the Free Software Foundation, either version 3 of the
# License, or (at your option) any later version.
2006-12-07 13:41:40 +00:00
#
2008-11-03 18:27:16 +00:00
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
2009-10-14 12:32:15 +00:00
# GNU Affero General Public License for more details.
2006-12-07 13:41:40 +00:00
#
2009-10-14 12:32:15 +00:00
# You should have received a copy of the GNU Affero General Public License
2010-05-14 09:57:41 +00:00
# along with this program. If not, see <http://www.gnu.org/licenses/>.
2006-12-07 13:41:40 +00:00
#
2012-03-05 07:26:18 +00:00
##############################################################################
2006-12-07 13:41:40 +00:00
2012-11-22 15:14:58 +00:00
import datetime
2012-12-10 15:27:23 +00:00
from lxml import etree
2006-12-07 13:41:40 +00:00
import math
2012-12-10 15:27:23 +00:00
import pytz
2014-05-16 14:09:27 +00:00
import urlparse
2012-12-10 15:27:23 +00:00
2012-08-10 08:17:30 +00:00
import openerp
2014-07-06 14:44:26 +00:00
from openerp import tools , api
2012-12-10 15:27:23 +00:00
from openerp . osv import osv , fields
2014-04-04 14:16:11 +00:00
from openerp . osv . expression import get_unaccent_wrapper
2012-12-10 15:27:23 +00:00
from openerp . tools . translate import _
2012-08-10 08:17:30 +00:00
2014-07-06 14:44:26 +00:00
ADDRESS_FORMAT_LAYOUTS = {
' %(city)s %(state_code)s \n %(zip)s ' : """
< div class = " address_format " >
< field name = " city " placeholder = " City " style = " width: 50 %% " / >
< field name = " state_id " class = " oe_no_button " placeholder = " State " style = " width: 47 %% " options = ' { " no_open " : true} ' / >
< br / >
< field name = " zip " placeholder = " ZIP " / >
< / div >
""" ,
' %(zip)s %(city)s ' : """
< div class = " address_format " >
< field name = " zip " placeholder = " ZIP " style = " width: 40 %% " / >
< field name = " city " placeholder = " City " style = " width: 57 %% " / >
< br / >
< field name = " state_id " class = " oe_no_button " placeholder = " State " options = ' { " no_open " : true} ' / >
< / div >
""" ,
' %(city)s \n %(state_name)s \n %(zip)s ' : """
< div class = " address_format " >
< field name = " city " placeholder = " City " / >
< field name = " state_id " class = " oe_no_button " placeholder = " State " options = ' { " no_open " : true} ' / >
< field name = " zip " placeholder = " ZIP " / >
< / div >
"""
}
2012-09-13 18:16:38 +00:00
class format_address ( object ) :
2014-07-06 14:44:26 +00:00
@api.model
def fields_view_get_address ( self , arch ) :
fmt = self . env . user . company_id . country_id . address_format or ' '
for k , v in ADDRESS_FORMAT_LAYOUTS . items ( ) :
if k in fmt :
2012-09-13 18:16:38 +00:00
doc = etree . fromstring ( arch )
for node in doc . xpath ( " //div[@class= ' address_format ' ] " ) :
tree = etree . fromstring ( v )
node . getparent ( ) . replace ( node , tree )
arch = etree . tostring ( doc )
break
return arch
2014-07-06 14:44:26 +00:00
@api.model
def _tz_get ( self ) :
2013-05-15 10:10:27 +00:00
# put POSIX 'Etc/*' entries at the end to avoid confusing users - see bug 1086728
return [ ( tz , tz ) for tz in sorted ( pytz . all_timezones , key = lambda tz : tz if not tz . startswith ( ' Etc/ ' ) else ' _ ' ) ]
2012-03-06 06:49:43 +00:00
2014-07-06 14:44:26 +00:00
class res_partner_category ( osv . Model ) :
2011-12-21 14:54:43 +00:00
2009-01-23 14:17:31 +00:00
def name_get ( self , cr , uid , ids , context = None ) :
2014-07-06 14:44:26 +00:00
""" Return the categories ' display name, including their direct
parent by default .
If ` ` context [ ' partner_category_display ' ] ` ` is ` ` ' short ' ` ` , the short
version of the category name ( without the direct parent ) is used .
The default is the long version .
"""
if not isinstance ( ids , list ) :
ids = [ ids ]
2011-12-15 14:56:04 +00:00
if context is None :
context = { }
2014-07-06 14:44:26 +00:00
2011-12-21 14:54:43 +00:00
if context . get ( ' partner_category_display ' ) == ' short ' :
return super ( res_partner_category , self ) . name_get ( cr , uid , ids , context = context )
2014-07-06 14:44:26 +00:00
2008-07-22 14:24:36 +00:00
res = [ ]
2014-07-06 14:44:26 +00:00
for category in self . browse ( cr , uid , ids , context = context ) :
names = [ ]
current = category
while current :
names . append ( current . name )
current = current . parent_id
res . append ( ( category . id , ' / ' . join ( reversed ( names ) ) ) )
2008-07-22 14:24:36 +00:00
return res
2014-07-06 14:44:26 +00:00
@api.model
def name_search ( self , name , args = None , operator = ' ilike ' , limit = 100 ) :
args = args or [ ]
2010-12-22 18:39:26 +00:00
if name :
# Be sure name_search is symetric to name_get
name = name . split ( ' / ' ) [ - 1 ]
2014-07-06 14:44:26 +00:00
args = [ ( ' name ' , operator , name ) ] + args
categories = self . search ( args , limit = limit )
return categories . name_get ( )
2010-12-22 18:39:26 +00:00
2014-07-06 14:44:26 +00:00
@api.multi
def _name_get_fnc ( self , field_name , arg ) :
return dict ( self . name_get ( ) )
2009-01-23 14:17:31 +00:00
2013-06-04 12:40:03 +00:00
_description = ' Partner Tags '
2008-07-22 14:24:36 +00:00
_name = ' res.partner.category '
_columns = {
2014-05-21 09:52:05 +00:00
' name ' : fields . char ( ' Category Name ' , required = True , translate = True ) ,
2010-12-11 00:04:50 +00:00
' parent_id ' : fields . many2one ( ' res.partner.category ' , ' Parent Category ' , select = True , ondelete = ' cascade ' ) ,
2012-01-04 13:30:27 +00:00
' complete_name ' : fields . function ( _name_get_fnc , type = " char " , string = ' Full Name ' ) ,
2009-01-26 17:40:29 +00:00
' child_ids ' : fields . one2many ( ' res.partner.category ' , ' parent_id ' , ' Child Categories ' ) ,
2012-09-07 09:22:06 +00:00
' active ' : fields . boolean ( ' Active ' , help = " The active field allows you to hide the category without removing it. " ) ,
' parent_left ' : fields . integer ( ' Left parent ' , select = True ) ,
' parent_right ' : fields . integer ( ' Right parent ' , select = True ) ,
2012-06-19 15:16:26 +00:00
' partner_ids ' : fields . many2many ( ' res.partner ' , id1 = ' category_id ' , id2 = ' partner_id ' , string = ' Partners ' ) ,
2008-07-22 14:24:36 +00:00
}
_constraints = [
2010-12-09 10:57:33 +00:00
( osv . osv . _check_recursion , ' Error ! You can not create recursive categories. ' , [ ' parent_id ' ] )
2008-07-22 14:24:36 +00:00
]
_defaults = {
2012-11-02 09:47:05 +00:00
' active ' : 1 ,
2008-07-22 14:24:36 +00:00
}
2010-12-11 00:04:50 +00:00
_parent_store = True
_parent_order = ' name '
_order = ' parent_left '
2012-03-06 06:49:43 +00:00
2014-07-06 14:44:26 +00:00
2006-12-07 13:41:40 +00:00
class res_partner_title ( osv . osv ) :
2008-07-22 14:24:36 +00:00
_name = ' res.partner.title '
2012-07-19 09:03:00 +00:00
_order = ' name '
2008-07-22 14:24:36 +00:00
_columns = {
2014-05-21 09:52:05 +00:00
' name ' : fields . char ( ' Title ' , required = True , translate = True ) ,
' shortcut ' : fields . char ( ' Abbreviation ' , translate = True ) ,
' domain ' : fields . selection ( [ ( ' partner ' , ' Partner ' ) , ( ' contact ' , ' Contact ' ) ] , ' Domain ' , required = True )
2008-07-22 14:24:36 +00:00
}
2012-07-19 09:03:00 +00:00
_defaults = {
' domain ' : ' contact ' ,
}
2012-03-06 06:49:43 +00:00
2014-07-06 14:44:26 +00:00
@api.model
def _lang_get ( self ) :
languages = self . env [ ' res.lang ' ] . search ( [ ] )
return [ ( language . code , language . name ) for language in languages ]
2009-05-12 14:01:27 +00:00
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
# fields copy if 'use_parent_address' is checked
2013-04-10 12:32:29 +00:00
ADDRESS_FIELDS = ( ' street ' , ' street2 ' , ' zip ' , ' city ' , ' state_id ' , ' country_id ' )
2012-03-07 15:36:46 +00:00
2014-07-06 14:44:26 +00:00
class res_partner ( osv . Model , format_address ) :
2012-09-07 09:22:06 +00:00
_description = ' Partner '
2008-07-22 14:24:36 +00:00
_name = " res.partner "
2012-03-29 06:29:24 +00:00
def _address_display ( self , cr , uid , ids , name , args , context = None ) :
2012-09-07 09:22:06 +00:00
res = { }
2012-03-29 11:43:31 +00:00
for partner in self . browse ( cr , uid , ids , context = context ) :
2012-09-07 09:22:06 +00:00
res [ partner . id ] = self . _display_address ( cr , uid , partner , context = context )
2012-03-29 06:29:24 +00:00
return res
2014-07-06 14:44:26 +00:00
@api.multi
def _get_tz_offset ( self , name , args ) :
return dict (
( p . id , datetime . datetime . now ( pytz . timezone ( p . tz or ' GMT ' ) ) . strftime ( ' % z ' ) )
for p in self )
2012-09-07 09:22:06 +00:00
2014-07-06 14:44:26 +00:00
@api.multi
def _get_image ( self , name , args ) :
return dict ( ( p . id , tools . image_get_resized_images ( p . image ) ) for p in self )
2012-11-22 15:14:58 +00:00
2014-07-06 14:44:26 +00:00
@api.one
def _set_image ( self , name , value , args ) :
return self . write ( { ' image ' : tools . image_resize_image_big ( value ) } )
2012-06-27 15:57:49 +00:00
2014-07-06 14:44:26 +00:00
@api.multi
def _has_image ( self , name , args ) :
return dict ( ( p . id , bool ( p . image ) ) for p in self )
2012-12-21 12:06:31 +00:00
2013-04-18 14:45:33 +00:00
def _commercial_partner_compute ( self , cr , uid , ids , name , args , context = None ) :
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
""" Returns the partner that is considered the commercial
entity of this partner . The commercial entity holds the master data
for all commercial fields ( see : py : meth : ` ~ _commercial_fields ` ) """
result = dict . fromkeys ( ids , False )
for partner in self . browse ( cr , uid , ids , context = context ) :
current_partner = partner
while not current_partner . is_company and current_partner . parent_id :
current_partner = current_partner . parent_id
result [ partner . id ] = current_partner . id
return result
2013-04-25 17:14:44 +00:00
def _display_name_compute ( self , cr , uid , ids , name , args , context = None ) :
2013-08-20 15:20:25 +00:00
context = dict ( context or { } )
context . pop ( ' show_address ' , None )
2013-09-28 16:43:36 +00:00
context . pop ( ' show_address_only ' , None )
2014-02-12 08:03:31 +00:00
context . pop ( ' show_email ' , None )
2013-04-25 17:14:44 +00:00
return dict ( self . name_get ( cr , uid , ids , context = context ) )
# indirections to avoid passing a copy of the overridable method when declaring the function field
2013-04-18 14:45:33 +00:00
_commercial_partner_id = lambda self , * args , * * kwargs : self . _commercial_partner_compute ( * args , * * kwargs )
2013-04-25 17:14:44 +00:00
_display_name = lambda self , * args , * * kwargs : self . _display_name_compute ( * args , * * kwargs )
_commercial_partner_store_triggers = {
2014-01-30 19:28:48 +00:00
' res.partner ' : ( lambda self , cr , uid , ids , context = None : self . search ( cr , uid , [ ( ' id ' , ' child_of ' , ids ) ] , context = dict ( active_test = False ) ) ,
[ ' parent_id ' , ' is_company ' ] , 10 )
2013-04-25 17:14:44 +00:00
}
_display_name_store_triggers = {
2014-01-30 19:28:48 +00:00
' res.partner ' : ( lambda self , cr , uid , ids , context = None : self . search ( cr , uid , [ ( ' id ' , ' child_of ' , ids ) ] , context = dict ( active_test = False ) ) ,
[ ' parent_id ' , ' is_company ' , ' name ' ] , 10 )
2013-04-25 17:14:44 +00:00
}
2013-04-18 14:45:33 +00:00
2013-04-25 17:14:44 +00:00
_order = " display_name "
2008-07-22 14:24:36 +00:00
_columns = {
2014-05-21 09:52:05 +00:00
' name ' : fields . char ( ' Name ' , required = True , select = True ) ,
2014-04-02 09:18:04 +00:00
' display_name ' : fields . function ( _display_name , type = ' char ' , string = ' Name ' , store = _display_name_store_triggers , select = True ) ,
2008-07-22 14:24:36 +00:00
' date ' : fields . date ( ' Date ' , select = 1 ) ,
2012-09-07 09:22:06 +00:00
' title ' : fields . many2one ( ' res.partner.title ' , ' Title ' ) ,
2014-04-03 14:37:17 +00:00
' parent_id ' : fields . many2one ( ' res.partner ' , ' Related Company ' , select = True ) ,
2014-10-20 13:41:52 +00:00
' parent_name ' : fields . related ( ' parent_id ' , ' name ' , type = ' char ' , readonly = True , string = ' Parent name ' ) ,
2013-09-29 08:50:00 +00:00
' child_ids ' : fields . one2many ( ' res.partner ' , ' parent_id ' , ' Contacts ' , domain = [ ( ' active ' , ' = ' , True ) ] ) , # force "active_test" domain to bypass _search() override
2014-05-21 09:52:05 +00:00
' ref ' : fields . char ( ' Contact Reference ' , select = 1 ) ,
2012-08-10 08:17:30 +00:00
' lang ' : fields . selection ( _lang_get , ' Language ' ,
2012-09-25 09:43:30 +00:00
help = " If the selected language is loaded in the system, all documents related to this contact will be printed in this language. If not, it will be English. " ) ,
2012-08-10 08:17:30 +00:00
' tz ' : fields . selection ( _tz_get , ' Timezone ' , size = 64 ,
help = " The partner ' s timezone, used to output proper date and time values inside printed reports. "
" It is important to set a value for this field. You should use the same timezone "
" that is otherwise used to pick and render date and time values: your computer ' s timezone. " ) ,
2012-11-29 21:00:33 +00:00
' tz_offset ' : fields . function ( _get_tz_offset , type = ' char ' , size = 5 , string = ' Timezone offset ' , invisible = True ) ,
2012-09-25 09:43:30 +00:00
' user_id ' : fields . many2one ( ' res.users ' , ' Salesperson ' , help = ' The internal user that is in charge of communicating with this contact if any. ' ) ,
2014-05-21 09:52:05 +00:00
' vat ' : fields . char ( ' TIN ' , help = " Tax Identification Number. Check the box if this contact is subjected to taxes. Used by the some of the legal statements. " ) ,
2008-07-22 14:24:36 +00:00
' bank_ids ' : fields . one2many ( ' res.partner.bank ' , ' partner_id ' , ' Banks ' ) ,
2014-05-21 09:52:05 +00:00
' website ' : fields . char ( ' Website ' , help = " Website of Partner or Company " ) ,
2008-07-22 14:24:36 +00:00
' comment ' : fields . text ( ' Notes ' ) ,
2012-06-19 15:16:26 +00:00
' category_id ' : fields . many2many ( ' res.partner.category ' , id1 = ' partner_id ' , id2 = ' category_id ' , string = ' Tags ' ) ,
2008-07-22 14:24:36 +00:00
' credit_limit ' : fields . float ( string = ' Credit Limit ' ) ,
' ean13 ' : fields . char ( ' EAN13 ' , size = 13 ) ,
2012-02-23 11:41:12 +00:00
' active ' : fields . boolean ( ' Active ' ) ,
2012-09-25 09:43:30 +00:00
' customer ' : fields . boolean ( ' Customer ' , help = " Check this box if this contact is a customer. " ) ,
' supplier ' : fields . boolean ( ' Supplier ' , help = " Check this box if this contact is a supplier. If it ' s not checked, purchase people will not see it when encoding a purchase order. " ) ,
' employee ' : fields . boolean ( ' Employee ' , help = " Check this box if this contact is an Employee. " ) ,
2014-05-21 09:52:05 +00:00
' function ' : fields . char ( ' Job Position ' ) ,
2012-09-07 09:22:06 +00:00
' type ' : fields . selection ( [ ( ' default ' , ' Default ' ) , ( ' invoice ' , ' Invoice ' ) ,
2012-10-12 07:05:25 +00:00
( ' delivery ' , ' Shipping ' ) , ( ' contact ' , ' Contact ' ) ,
2012-08-10 08:17:30 +00:00
( ' other ' , ' Other ' ) ] , ' Address Type ' ,
help = " Used to select automatically the right address according to the context in sales and purchases documents. " ) ,
2014-05-21 09:52:05 +00:00
' street ' : fields . char ( ' Street ' ) ,
' street2 ' : fields . char ( ' Street2 ' ) ,
' zip ' : fields . char ( ' Zip ' , size = 24 , change_default = True ) ,
' city ' : fields . char ( ' City ' ) ,
2013-05-09 11:36:15 +00:00
' state_id ' : fields . many2one ( " res.country.state " , ' State ' , ondelete = ' restrict ' ) ,
' country_id ' : fields . many2one ( ' res.country ' , ' Country ' , ondelete = ' restrict ' ) ,
2014-05-21 09:52:05 +00:00
' email ' : fields . char ( ' Email ' ) ,
' phone ' : fields . char ( ' Phone ' ) ,
' fax ' : fields . char ( ' Fax ' ) ,
' mobile ' : fields . char ( ' Mobile ' ) ,
' birthdate ' : fields . char ( ' Birthdate ' ) ,
2012-10-24 08:44:09 +00:00
' is_company ' : fields . boolean ( ' Is a Company ' , help = " Check if the contact is a company, otherwise it is a person " ) ,
2012-03-28 05:30:40 +00:00
' use_parent_address ' : fields . boolean ( ' Use Company Address ' , help = " Select this if you want to set company ' s address information for this contact " ) ,
2012-09-07 09:22:06 +00:00
# image: all image fields are base64 encoded and PIL-supported
2012-07-30 09:51:33 +00:00
' image ' : fields . binary ( " Image " ,
2012-09-25 09:43:30 +00:00
help = " This field holds the image used as avatar for this contact, limited to 1024x1024px " ) ,
2012-06-27 15:57:49 +00:00
' image_medium ' : fields . function ( _get_image , fnct_inv = _set_image ,
2012-07-30 09:51:33 +00:00
string = " Medium-sized image " , type = " binary " , multi = " _get_image " ,
2012-09-07 09:22:06 +00:00
store = {
2012-06-27 15:57:49 +00:00
' res.partner ' : ( lambda self , cr , uid , ids , c = { } : ids , [ ' image ' ] , 10 ) ,
} ,
2012-09-25 09:43:30 +00:00
help = " Medium-sized image of this contact. It is automatically " \
2012-09-07 09:49:57 +00:00
" resized as a 128x128px image, with aspect ratio preserved. " \
2012-06-27 15:57:49 +00:00
" Use this field in form views or some kanban views. " ) ,
' image_small ' : fields . function ( _get_image , fnct_inv = _set_image ,
2012-07-30 09:51:33 +00:00
string = " Small-sized image " , type = " binary " , multi = " _get_image " ,
2012-09-07 09:22:06 +00:00
store = {
2012-06-27 15:57:49 +00:00
' res.partner ' : ( lambda self , cr , uid , ids , c = { } : ids , [ ' image ' ] , 10 ) ,
} ,
2012-09-25 09:43:30 +00:00
help = " Small-sized image of this contact. It is automatically " \
2012-09-07 09:49:57 +00:00
" resized as a 64x64px image, with aspect ratio preserved. " \
2012-06-27 15:57:49 +00:00
" Use this field anywhere a small image is required. " ) ,
2012-12-21 12:06:31 +00:00
' has_image ' : fields . function ( _has_image , type = " boolean " ) ,
2012-02-23 11:41:12 +00:00
' company_id ' : fields . many2one ( ' res.company ' , ' Company ' , select = 1 ) ,
' color ' : fields . integer ( ' Color Index ' ) ,
2012-08-20 11:32:27 +00:00
' user_ids ' : fields . one2many ( ' res.users ' , ' partner_id ' , ' Users ' ) ,
2012-03-29 11:43:31 +00:00
' contact_address ' : fields . function ( _address_display , type = ' char ' , string = ' Complete Address ' ) ,
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
# technical field used for managing commercial fields
2013-04-25 17:14:44 +00:00
' commercial_partner_id ' : fields . function ( _commercial_partner_id , type = ' many2one ' , relation = ' res.partner ' , string = ' Commercial Entity ' , store = _commercial_partner_store_triggers )
2008-07-22 14:24:36 +00:00
}
2012-03-07 15:28:27 +00:00
2014-07-06 14:44:26 +00:00
@api.model
def _default_category ( self ) :
category_id = self . env . context . get ( ' category_id ' , False )
return [ category_id ] if category_id else False
2008-11-18 12:54:32 +00:00
2014-07-06 14:44:26 +00:00
@api.model
def _get_default_image ( self , is_company , colorize = False ) :
img_path = openerp . modules . get_module_resource (
' base ' , ' static/src/img ' , ' company_image.png ' if is_company else ' avatar.png ' )
2012-11-06 18:15:02 +00:00
with open ( img_path , ' rb ' ) as f :
image = f . read ( )
# colorize user avatars
if not is_company :
image = tools . image_colorize ( image )
2012-09-07 09:22:06 +00:00
return tools . image_resize_image_big ( image . encode ( ' base64 ' ) )
2012-03-05 07:26:18 +00:00
2012-09-11 16:19:26 +00:00
def fields_view_get ( self , cr , user , view_id = None , view_type = ' form ' , context = None , toolbar = False , submenu = False ) :
if ( not view_id ) and ( view_type == ' form ' ) and context and context . get ( ' force_email ' , False ) :
2013-03-27 11:10:14 +00:00
view_id = self . pool [ ' ir.model.data ' ] . get_object_reference ( cr , user , ' base ' , ' view_partner_simple_form ' ) [ 1 ]
2012-09-13 18:22:56 +00:00
res = super ( res_partner , self ) . fields_view_get ( cr , user , view_id , view_type , context , toolbar = toolbar , submenu = submenu )
2012-09-13 18:16:38 +00:00
if view_type == ' form ' :
2012-09-13 18:22:56 +00:00
res [ ' arch ' ] = self . fields_view_get_address ( cr , user , res [ ' arch ' ] , context = context )
2012-09-13 18:16:38 +00:00
return res
2012-09-11 16:19:26 +00:00
2014-07-06 14:44:26 +00:00
@api.model
def _default_company ( self ) :
return self . env [ ' res.company ' ] . _company_default_get ( ' res.partner ' )
2008-07-22 14:24:36 +00:00
_defaults = {
2012-02-23 11:41:12 +00:00
' active ' : True ,
2014-07-06 14:44:26 +00:00
' lang ' : api . model ( lambda self : self . env . lang ) ,
' tz ' : api . model ( lambda self : self . env . context . get ( ' tz ' , False ) ) ,
2012-02-23 11:41:12 +00:00
' customer ' : True ,
2008-11-18 12:54:32 +00:00
' category_id ' : _default_category ,
2014-07-06 14:44:26 +00:00
' company_id ' : _default_company ,
2011-09-16 12:47:25 +00:00
' color ' : 0 ,
2012-03-07 15:19:42 +00:00
' is_company ' : False ,
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
' type ' : ' contact ' , # type 'default' is wildcard and thus inappropriate
' use_parent_address ' : False ,
2012-12-21 12:06:31 +00:00
' image ' : False ,
2008-07-22 14:24:36 +00:00
}
2012-03-05 07:26:18 +00:00
2013-04-15 17:17:32 +00:00
_constraints = [
( osv . osv . _check_recursion , ' You cannot create recursive Partner hierarchies. ' , [ ' parent_id ' ] ) ,
]
2014-07-06 14:44:26 +00:00
@api.one
def copy ( self , default = None ) :
default = dict ( default or { } )
default [ ' name ' ] = _ ( ' %s (copy) ' ) % self . name
return super ( res_partner , self ) . copy ( default )
2008-09-18 11:28:57 +00:00
2014-07-06 14:44:26 +00:00
@api.multi
def onchange_type ( self , is_company ) :
2014-08-22 15:51:20 +00:00
value = { ' title ' : False }
2012-03-07 15:19:42 +00:00
if is_company :
2013-09-24 10:52:03 +00:00
value [ ' use_parent_address ' ] = False
2012-03-07 15:19:42 +00:00
domain = { ' title ' : [ ( ' domain ' , ' = ' , ' partner ' ) ] }
else :
domain = { ' title ' : [ ( ' domain ' , ' = ' , ' contact ' ) ] }
return { ' value ' : value , ' domain ' : domain }
2012-03-06 06:49:43 +00:00
2012-02-23 14:54:26 +00:00
def onchange_address ( self , cr , uid , ids , use_parent_address , parent_id , context = None ) :
2012-03-19 10:35:11 +00:00
def value_or_id ( val ) :
""" return val or val.id if val is a browse record """
return val if isinstance ( val , ( bool , int , long , float , basestring ) ) else val . id
2013-04-18 15:38:29 +00:00
result = { }
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
if parent_id :
2013-04-18 15:38:29 +00:00
if ids :
partner = self . browse ( cr , uid , ids [ 0 ] , context = context )
if partner . parent_id and partner . parent_id . id != parent_id :
result [ ' warning ' ] = { ' title ' : _ ( ' Warning ' ) ,
' message ' : _ ( ' Changing the company of a contact should only be done if it '
' was never correctly set. If an existing contact starts working for a new '
' company then a new contact should be created under that new '
' company. You can use the " Discard " button to abandon this change. ' ) }
2013-08-29 11:09:55 +00:00
if use_parent_address :
2014-04-17 14:55:22 +00:00
parent = self . browse ( cr , uid , parent_id , context = context )
address_fields = self . _address_fields ( cr , uid , context = context )
result [ ' value ' ] = dict ( ( key , value_or_id ( parent [ key ] ) ) for key in address_fields )
2013-04-18 15:38:29 +00:00
else :
result [ ' value ' ] = { ' use_parent_address ' : False }
return result
2010-05-18 15:34:22 +00:00
2014-07-06 14:44:26 +00:00
@api.multi
def onchange_state ( self , state_id ) :
2012-10-25 10:23:01 +00:00
if state_id :
2014-07-06 14:44:26 +00:00
state = self . env [ ' res.country.state ' ] . browse ( state_id )
return { ' value ' : { ' country_id ' : state . country_id . id } }
2012-11-02 09:14:49 +00:00
return { }
2012-10-25 10:23:01 +00:00
2010-12-09 10:57:33 +00:00
def _check_ean_key ( self , cr , uid , ids , context = None ) :
2013-03-27 11:10:14 +00:00
for partner_o in self . pool [ ' res.partner ' ] . read ( cr , uid , ids , [ ' ean13 ' , ] ) :
2008-07-22 14:24:36 +00:00
thisean = partner_o [ ' ean13 ' ]
if thisean and thisean != ' ' :
if len ( thisean ) != 13 :
return False
sum = 0
for i in range ( 12 ) :
if not ( i % 2 ) :
sum + = int ( thisean [ i ] )
else :
sum + = 3 * int ( thisean [ i ] )
if math . ceil ( sum / 10.0 ) * 10 - sum != int ( thisean [ 12 ] ) :
return False
return True
2012-03-06 06:49:43 +00:00
2012-03-07 15:19:42 +00:00
# _constraints = [(_check_ean_key, 'Error: Invalid ean code', ['ean13'])]
2012-03-06 06:49:43 +00:00
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
def _update_fields_values ( self , cr , uid , partner , fields , context = None ) :
""" Returns dict of write() values for synchronizing ``fields`` """
values = { }
[IMP] use model._fields instead of model._all_columns to cover all fields
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
2014-11-03 15:00:50 +00:00
for fname in fields :
field = self . _fields [ fname ]
if field . type == ' one2many ' :
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
raise AssertionError ( ' One2Many fields cannot be synchronized as part of `commercial_fields` or `address fields` ' )
[IMP] use model._fields instead of model._all_columns to cover all fields
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
2014-11-03 15:00:50 +00:00
if field . type == ' many2one ' :
values [ fname ] = partner [ fname ] . id if partner [ fname ] else False
elif field . type == ' many2many ' :
values [ fname ] = [ ( 6 , 0 , [ r . id for r in partner [ fname ] or [ ] ] ) ]
2013-03-29 11:23:17 +00:00
else :
[IMP] use model._fields instead of model._all_columns to cover all fields
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
2014-11-03 15:00:50 +00:00
values [ fname ] = partner [ fname ]
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
return values
2013-03-29 11:23:17 +00:00
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
def _address_fields ( self , cr , uid , context = None ) :
""" Returns the list of address fields that are synced from the parent
when the ` use_parent_address ` flag is set . """
2013-04-11 19:00:50 +00:00
return list ( ADDRESS_FIELDS )
2012-03-06 06:49:43 +00:00
2012-03-08 14:03:42 +00:00
def update_address ( self , cr , uid , ids , vals , context = None ) :
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
address_fields = self . _address_fields ( cr , uid , context = context )
addr_vals = dict ( ( key , vals [ key ] ) for key in address_fields if key in vals )
2012-08-13 15:24:13 +00:00
if addr_vals :
return super ( res_partner , self ) . write ( cr , uid , ids , addr_vals , context )
2008-07-22 14:24:36 +00:00
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
def _commercial_fields ( self , cr , uid , context = None ) :
""" Returns the list of fields that are managed by the commercial entity
to which a partner belongs . These fields are meant to be hidden on
partners that aren ' t `commercial entities` themselves, and will be
delegated to the parent ` commercial entity ` . The list is meant to be
extended by inheriting classes . """
return [ ' vat ' ]
def _commercial_sync_from_company ( self , cr , uid , partner , context = None ) :
""" Handle sync of commercial fields when a new parent commercial entity is set,
as if they were related fields """
2014-08-04 12:34:08 +00:00
commercial_partner = partner . commercial_partner_id
if not commercial_partner :
# On child partner creation of a parent partner,
# the commercial_partner_id is not yet computed
commercial_partner_id = self . _commercial_partner_compute (
cr , uid , [ partner . id ] , ' commercial_partner_id ' , [ ] , context = context ) [ partner . id ]
commercial_partner = self . browse ( cr , uid , commercial_partner_id , context = context )
if commercial_partner != partner :
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
commercial_fields = self . _commercial_fields ( cr , uid , context = context )
2014-08-04 12:34:08 +00:00
sync_vals = self . _update_fields_values ( cr , uid , commercial_partner ,
commercial_fields , context = context )
2013-04-24 13:16:25 +00:00
partner . write ( sync_vals )
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
def _commercial_sync_to_children ( self , cr , uid , partner , context = None ) :
""" Handle sync of commercial fields to descendants """
commercial_fields = self . _commercial_fields ( cr , uid , context = context )
2014-08-04 12:34:08 +00:00
commercial_partner = partner . commercial_partner_id
if not commercial_partner :
# On child partner creation of a parent partner,
# the commercial_partner_id is not yet computed
commercial_partner_id = self . _commercial_partner_compute (
cr , uid , [ partner . id ] , ' commercial_partner_id ' , [ ] , context = context ) [ partner . id ]
commercial_partner = self . browse ( cr , uid , commercial_partner_id , context = context )
sync_vals = self . _update_fields_values ( cr , uid , commercial_partner ,
commercial_fields , context = context )
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
sync_children = [ c for c in partner . child_ids if not c . is_company ]
for child in sync_children :
self . _commercial_sync_to_children ( cr , uid , child , context = context )
return self . write ( cr , uid , [ c . id for c in sync_children ] , sync_vals , context = context )
def _fields_sync ( self , cr , uid , partner , update_values , context = None ) :
""" Sync commercial fields and address fields from company and to children after create/update,
just as if those were all modeled as fields . related to the parent """
# 1. From UPSTREAM: sync from parent
2013-04-25 17:12:38 +00:00
if update_values . get ( ' parent_id ' ) or update_values . get ( ' use_parent_address ' ) :
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
# 1a. Commercial fields: sync if parent changed
if update_values . get ( ' parent_id ' ) :
self . _commercial_sync_from_company ( cr , uid , partner , context = context )
# 1b. Address fields: sync if parent or use_parent changed *and* both are now set
if partner . parent_id and partner . use_parent_address :
onchange_vals = self . onchange_address ( cr , uid , [ partner . id ] ,
use_parent_address = partner . use_parent_address ,
parent_id = partner . parent_id . id ,
context = context ) . get ( ' value ' , { } )
2013-04-24 13:16:25 +00:00
partner . update_address ( onchange_vals )
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
# 2. To DOWNSTREAM: sync children
if partner . child_ids :
# 2a. Commercial Fields: sync if commercial entity
2013-04-18 14:45:33 +00:00
if partner . commercial_partner_id == partner :
2013-08-08 18:18:06 +00:00
commercial_fields = self . _commercial_fields ( cr , uid ,
context = context )
if any ( field in update_values for field in commercial_fields ) :
self . _commercial_sync_to_children ( cr , uid , partner ,
context = context )
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
# 2b. Address fields: sync if address changed
address_fields = self . _address_fields ( cr , uid , context = context )
if any ( field in update_values for field in address_fields ) :
domain_children = [ ( ' parent_id ' , ' = ' , partner . id ) , ( ' use_parent_address ' , ' = ' , True ) ]
update_ids = self . search ( cr , uid , domain_children , context = context )
self . update_address ( cr , uid , update_ids , update_values , context = context )
def _handle_first_contact_creation ( self , cr , uid , partner , context = None ) :
""" On creation of first contact for a company (or root) that has no address, assume contact address
was meant to be company address """
parent = partner . parent_id
2013-04-10 12:32:29 +00:00
address_fields = self . _address_fields ( cr , uid , context = context )
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
if parent and ( parent . is_company or not parent . parent_id ) and len ( parent . child_ids ) == 1 and \
2013-04-10 12:32:29 +00:00
any ( partner [ f ] for f in address_fields ) and not any ( parent [ f ] for f in address_fields ) :
addr_vals = self . _update_fields_values ( cr , uid , partner , address_fields , context = context )
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
parent . update_address ( addr_vals )
if not parent . is_company :
parent . write ( { ' is_company ' : True } )
2014-11-28 10:39:36 +00:00
def unlink ( self , cr , uid , ids , context = None ) :
orphan_contact_ids = self . search ( cr , uid ,
[ ( ' parent_id ' , ' in ' , ids ) , ( ' id ' , ' not in ' , ids ) , ( ' use_parent_address ' , ' = ' , True ) ] , context = context )
if orphan_contact_ids :
# no longer have a parent address
self . write ( cr , uid , orphan_contact_ids , { ' use_parent_address ' : False } , context = context )
return super ( res_partner , self ) . unlink ( cr , uid , ids , context = context )
2014-05-16 14:09:27 +00:00
def _clean_website ( self , website ) :
( scheme , netloc , path , params , query , fragment ) = urlparse . urlparse ( website )
if not scheme :
if not netloc :
netloc , path = path , ' '
website = urlparse . urlunparse ( ( ' http ' , netloc , path , params , query , fragment ) )
return website
2014-07-06 14:44:26 +00:00
@api.multi
def write ( self , vals ) :
# res.partner must only allow to set the company_id of a partner if it
# is the same as the company of all users that inherit from this partner
# (this is to allow the code from res_users to write to the partner!) or
# if setting the company_id to False (this is compatible with any user
# company)
2014-05-16 14:09:27 +00:00
if vals . get ( ' website ' ) :
vals [ ' website ' ] = self . _clean_website ( vals [ ' website ' ] )
2013-06-11 05:58:03 +00:00
if vals . get ( ' company_id ' ) :
2014-07-06 14:44:26 +00:00
company = self . env [ ' res.company ' ] . browse ( vals [ ' company_id ' ] )
for partner in self :
2013-08-01 06:27:06 +00:00
if partner . user_ids :
2014-07-06 14:44:26 +00:00
companies = set ( user . company_id for user in partner . user_ids )
if len ( companies ) > 1 or company not in companies :
2013-08-01 06:27:06 +00:00
raise osv . except_osv ( _ ( " Warning " ) , _ ( " You can not change the company as the partner/user has multiple user linked with different companies. " ) )
2014-07-06 14:44:26 +00:00
result = super ( res_partner , self ) . write ( vals )
for partner in self :
self . _fields_sync ( partner , vals )
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
return result
2014-07-06 14:44:26 +00:00
@api.model
def create ( self , vals ) :
2014-05-16 14:09:27 +00:00
if vals . get ( ' website ' ) :
vals [ ' website ' ] = self . _clean_website ( vals [ ' website ' ] )
2014-07-06 14:44:26 +00:00
partner = super ( res_partner , self ) . create ( vals )
self . _fields_sync ( partner , vals )
self . _handle_first_contact_creation ( partner )
return partner
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
def open_commercial_entity ( self , cr , uid , ids , context = None ) :
""" Utility method used to add an " Open Company " button in partner views """
partner = self . browse ( cr , uid , ids [ 0 ] , context = context )
return { ' type ' : ' ir.actions.act_window ' ,
' res_model ' : ' res.partner ' ,
' view_mode ' : ' form ' ,
2013-04-18 14:45:33 +00:00
' res_id ' : partner . commercial_partner_id . id ,
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
' target ' : ' new ' ,
' flags ' : { ' form ' : { ' action_buttons ' : True } } }
def open_parent ( self , cr , uid , ids , context = None ) :
""" Utility method used to add an " Open Parent " button in partner views """
partner = self . browse ( cr , uid , ids [ 0 ] , context = context )
return { ' type ' : ' ir.actions.act_window ' ,
' res_model ' : ' res.partner ' ,
' view_mode ' : ' form ' ,
' res_id ' : partner . parent_id . id ,
' target ' : ' new ' ,
' flags ' : { ' form ' : { ' action_buttons ' : True } } }
2011-11-07 15:19:49 +00:00
def name_get ( self , cr , uid , ids , context = None ) :
if context is None :
context = { }
2012-06-20 09:58:12 +00:00
if isinstance ( ids , ( int , long ) ) :
ids = [ ids ]
2012-03-02 12:29:17 +00:00
res = [ ]
2012-06-25 18:22:29 +00:00
for record in self . browse ( cr , uid , ids , context = context ) :
name = record . name
2013-04-19 16:47:28 +00:00
if record . parent_id and not record . is_company :
2014-10-20 13:41:52 +00:00
name = " %s , %s " % ( record . parent_name , name )
2013-09-28 16:43:36 +00:00
if context . get ( ' show_address_only ' ) :
name = self . _display_address ( cr , uid , record , without_company = True , context = context )
2012-06-25 18:22:29 +00:00
if context . get ( ' show_address ' ) :
name = name + " \n " + self . _display_address ( cr , uid , record , without_company = True , context = context )
2013-09-28 16:43:36 +00:00
name = name . replace ( ' \n \n ' , ' \n ' )
name = name . replace ( ' \n \n ' , ' \n ' )
2012-12-20 18:16:04 +00:00
if context . get ( ' show_email ' ) and record . email :
name = " %s < %s > " % ( name , record . email )
2012-06-25 18:22:29 +00:00
res . append ( ( record . id , name ) )
2008-07-22 14:24:36 +00:00
return res
2008-09-18 11:28:57 +00:00
2012-08-31 22:52:05 +00:00
def _parse_partner_name ( self , text , context = None ) :
2012-08-31 17:12:47 +00:00
""" Supported syntax:
2012-08-31 22:52:05 +00:00
- ' Raoul <raoul@grosbedon.fr> ' : will find name and email address
2012-08-31 17:12:47 +00:00
- otherwise : default , everything is set as the name """
2014-06-27 14:47:20 +00:00
emails = tools . email_split ( text . replace ( ' ' , ' , ' ) )
2013-03-13 10:56:40 +00:00
if emails :
email = emails [ 0 ]
name = text [ : text . index ( email ) ] . replace ( ' " ' , ' ' ) . replace ( ' < ' , ' ' ) . strip ( )
2012-08-31 22:52:05 +00:00
else :
name , email = text , ' '
return name , email
2012-08-31 17:12:47 +00:00
2012-07-13 14:22:27 +00:00
def name_create ( self , cr , uid , name , context = None ) :
2012-07-19 14:27:59 +00:00
""" Override of orm ' s name_create method for partners. The purpose is
to handle some basic formats to create partners using the
2012-07-13 14:22:27 +00:00
name_create .
2012-08-31 17:12:47 +00:00
If only an email address is received and that the regex cannot find
a name , the name will have the email value .
If ' force_email ' key in context : must find the email address . """
2012-09-03 17:48:29 +00:00
if context is None :
context = { }
2012-08-31 22:52:05 +00:00
name , email = self . _parse_partner_name ( name , context = context )
2012-08-31 17:12:47 +00:00
if context . get ( ' force_email ' ) and not email :
2013-04-29 07:29:38 +00:00
raise osv . except_osv ( _ ( ' Warning ' ) , _ ( " Couldn ' t create contact without email address! " ) )
2012-08-31 17:12:47 +00:00
if not name and email :
name = email
2012-08-21 18:04:09 +00:00
rec_id = self . create ( cr , uid , { self . _rec_name : name or email , ' email ' : email or False } , context = context )
return self . name_get ( cr , uid , [ rec_id ] , context ) [ 0 ]
2012-07-13 14:22:27 +00:00
[FIX] res.partner: search using 'child_of' should include inactive children
This is necessary for 2 reasons:
- when searching on Business documents the search domain will be
[('partner_id', 'child_of', 'ACME')] in order to match all
descendants, and it must match inactive children as well
- in other cases like for resolving IDs to update via store
triggers, it is necessary that 'child_of' returns inactive
children too.
The implementation is tricky because the ORM automatically
transform 'child_of' domains into recursive searches with
[('parent_id', 'in', ids)], which is the same query that the
reverse one2many 'child_ids' will also use to find contacts.
The overridden search() therefore matches this domain pattern
only when there is one criterion (to avoid side-effects in
other cases) and a dummy extra 'domain' was added to the
definition of the 'child_ids' o2m so it won't match.
The net result is that child_ids will not return inactive
children while child_of will return all descendants when
it is the only criterion. This is the expected behavior
whenever child_of is used on res.partner, because
it's safer to always show business documents.
The only side-effects will be for custom/manual search
calls with a single criterion of the form ('parent_id','in', x)
and those can be fixed by adding an extra domain
component ('active','=',True), just like child_ids does.
bzr revid: odo@openerp.com-20130419135756-2kbhwr23lygqdoob
2013-04-19 13:57:56 +00:00
def _search ( self , cr , user , args , offset = 0 , limit = None , order = None , context = None , count = False , access_rights_uid = None ) :
""" Override search() to always show inactive children when searching via ``child_of`` operator. The ORM will
always call search ( ) with a simple domain of the form [ ( ' parent_id ' , ' in ' , [ ids ] ) ] . """
# a special ``domain`` is set on the ``child_ids`` o2m to bypass this logic, as it uses similar domain expressions
2014-01-30 16:24:19 +00:00
if len ( args ) == 1 and len ( args [ 0 ] ) == 3 and args [ 0 ] [ : 2 ] == ( ' parent_id ' , ' in ' ) \
and args [ 0 ] [ 2 ] != [ False ] :
[FIX] res.partner: search using 'child_of' should include inactive children
This is necessary for 2 reasons:
- when searching on Business documents the search domain will be
[('partner_id', 'child_of', 'ACME')] in order to match all
descendants, and it must match inactive children as well
- in other cases like for resolving IDs to update via store
triggers, it is necessary that 'child_of' returns inactive
children too.
The implementation is tricky because the ORM automatically
transform 'child_of' domains into recursive searches with
[('parent_id', 'in', ids)], which is the same query that the
reverse one2many 'child_ids' will also use to find contacts.
The overridden search() therefore matches this domain pattern
only when there is one criterion (to avoid side-effects in
other cases) and a dummy extra 'domain' was added to the
definition of the 'child_ids' o2m so it won't match.
The net result is that child_ids will not return inactive
children while child_of will return all descendants when
it is the only criterion. This is the expected behavior
whenever child_of is used on res.partner, because
it's safer to always show business documents.
The only side-effects will be for custom/manual search
calls with a single criterion of the form ('parent_id','in', x)
and those can be fixed by adding an extra domain
component ('active','=',True), just like child_ids does.
bzr revid: odo@openerp.com-20130419135756-2kbhwr23lygqdoob
2013-04-19 13:57:56 +00:00
context = dict ( context or { } , active_test = False )
return super ( res_partner , self ) . _search ( cr , user , args , offset = offset , limit = limit , order = order , context = context ,
count = count , access_rights_uid = access_rights_uid )
2009-12-09 11:42:41 +00:00
def name_search ( self , cr , uid , name , args = None , operator = ' ilike ' , context = None , limit = 100 ) :
2008-07-22 14:24:36 +00:00
if not args :
2011-10-11 16:34:35 +00:00
args = [ ]
2012-12-20 18:16:04 +00:00
if name and operator in ( ' = ' , ' ilike ' , ' =ilike ' , ' like ' , ' =like ' ) :
2014-01-29 10:55:48 +00:00
self . check_access_rights ( cr , uid , ' read ' )
where_query = self . _where_calc ( cr , uid , args , context = context )
self . _apply_ir_rules ( cr , uid , where_query , ' read ' , context = context )
from_clause , where_clause , where_clause_params = where_query . get_sql ( )
2014-01-29 11:39:38 +00:00
where_str = where_clause and ( " WHERE %s AND " % where_clause ) or ' WHERE '
2014-01-29 10:55:48 +00:00
2012-03-20 10:02:51 +00:00
# search on the name of the contacts and of its company
2012-12-20 18:16:04 +00:00
search_name = name
if operator in ( ' ilike ' , ' like ' ) :
search_name = ' %% %s %% ' % name
if operator in ( ' =ilike ' , ' =like ' ) :
operator = operator [ 1 : ]
2014-01-29 10:55:48 +00:00
2014-04-04 14:16:11 +00:00
unaccent = get_unaccent_wrapper ( cr )
2014-04-04 15:58:58 +00:00
query = """ SELECT id
2014-04-04 14:16:11 +00:00
FROM res_partner
{ where } ( { email } { operator } { percent }
OR { display_name } { operator } { percent } )
ORDER BY { display_name }
""" .format(where=where_str, operator=operator,
2014-04-04 15:58:58 +00:00
email = unaccent ( ' email ' ) ,
display_name = unaccent ( ' display_name ' ) ,
percent = unaccent ( ' %s ' ) )
2014-01-29 10:55:48 +00:00
where_clause_params + = [ search_name , search_name ]
2012-04-17 10:18:10 +00:00
if limit :
2014-01-29 10:55:48 +00:00
query + = ' limit %s '
where_clause_params . append ( limit )
cr . execute ( query , where_clause_params )
2012-03-20 12:48:15 +00:00
ids = map ( lambda x : x [ 0 ] , cr . fetchall ( ) )
2014-01-29 11:39:38 +00:00
2011-10-11 16:34:35 +00:00
if ids :
return self . name_get ( cr , uid , ids , context )
2014-01-29 12:34:04 +00:00
else :
return [ ]
2011-10-11 16:34:35 +00:00
return super ( res_partner , self ) . name_search ( cr , uid , name , args , operator = operator , context = context , limit = limit )
2008-07-22 14:24:36 +00:00
2012-09-04 15:20:02 +00:00
def find_or_create ( self , cr , uid , email , context = None ) :
""" Find a partner with the given ``email`` or use :py:method:`~.name_create`
to create one
2012-09-18 14:14:21 +00:00
2012-09-04 15:20:02 +00:00
: param str email : email - like string , which should contain at least one email ,
e . g . ` ` " Raoul Grosbedon <r.g@grosbedon.fr> " ` ` """
assert email , ' an email is required for find_or_create to work '
emails = tools . email_split ( email )
if emails :
email = emails [ 0 ]
ids = self . search ( cr , uid , [ ( ' email ' , ' ilike ' , email ) ] , context = context )
if not ids :
return self . name_create ( cr , uid , email , context = context ) [ 0 ]
return ids [ 0 ]
2008-07-22 14:24:36 +00:00
def _email_send ( self , cr , uid , ids , email_from , subject , body , on_error = None ) :
partners = self . browse ( cr , uid , ids )
for partner in partners :
2012-02-21 13:08:57 +00:00
if partner . email :
tools . email_send ( email_from , [ partner . email ] , subject , body , on_error )
2008-07-22 14:24:36 +00:00
return True
def email_send ( self , cr , uid , ids , email_from , subject , body , on_error = ' ' ) :
while len ( ids ) :
2013-03-27 11:10:14 +00:00
self . pool [ ' ir.cron ' ] . create ( cr , uid , {
2008-07-22 14:24:36 +00:00
' name ' : ' Send Partner Emails ' ,
' user_id ' : uid ,
' model ' : ' res.partner ' ,
' function ' : ' _email_send ' ,
' args ' : repr ( [ ids [ : 16 ] , email_from , subject , body , on_error ] )
} )
ids = ids [ 16 : ]
return True
2008-09-18 11:28:57 +00:00
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
def address_get ( self , cr , uid , ids , adr_pref = None , context = None ) :
""" Find contacts/addresses of the right type(s) by doing a depth-first-search
through descendants within company boundaries ( stop at entities flagged ` ` is_company ` ` )
then continuing the search at the ancestors that are within the same company boundaries .
Defaults to partners of type ` ` ' default ' ` ` when the exact type is not found , or to the
2013-04-10 12:15:36 +00:00
provided partner itself if no type ` ` ' default ' ` ` is found either . """
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
adr_pref = set ( adr_pref or [ ] )
if ' default ' not in adr_pref :
adr_pref . add ( ' default ' )
2012-03-06 06:49:43 +00:00
result = { }
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
visited = set ( )
for partner in self . browse ( cr , uid , filter ( None , ids ) , context = context ) :
current_partner = partner
while current_partner :
to_scan = [ current_partner ]
# Scan descendants, DFS
while to_scan :
record = to_scan . pop ( 0 )
visited . add ( record )
if record . type in adr_pref and not result . get ( record . type ) :
result [ record . type ] = record . id
if len ( result ) == len ( adr_pref ) :
return result
to_scan = [ c for c in record . child_ids
if c not in visited
if not c . is_company ] + to_scan
# Continue scanning at ancestor if current_partner is not a commercial entity
if current_partner . is_company or not current_partner . parent_id :
break
current_partner = current_partner . parent_id
2013-04-10 12:15:36 +00:00
# default to type 'default' or the partner itself
default = result . get ( ' default ' , partner . id )
[FIX] res.partner: autosync of commercial fields and address fields + correct views accordingly + basic tests
* Commercial fields (bug 1160365)
Fix autosync of accounting/invoicing-related fields on contacts,
just as if they were actually modeled as fields.related to the
parent commercial entity.
This starts with the addition of the new functional field
`commercial_id`, to locate the commercial entity for any partner.
The commercial entity is defined as the first ancestor (starting
at the partner itself) that is either marked `is_company` or has
no parent. [This is Part A of the solution on bug 1160365].
Then, whenever a partner is created or modified:
- if it is a commercial entity, the commercial fields are synced
downstream to all its descendants, stopping at company boundaries.
- if is is not a commercial entity, the commercial fields are
synced from its parent commercial entity.
The list of fields to sync is determined by calling the new
res.partner method `_commercial_fields()` which can be easily
extended by any module that adds commercial fields on res.partner.
A utility method `open_commercial_entity()` was added to
res.partner to make it easy to include a button for editing the
parent commercial entity, to be displayed instead of now-hidden
commercial fields.
[This is part B of the solution on bug 1160365]
The res.partner.address_get() method (used to find child partners
of certain types, e.g. "invoice") was udpated to take the new
"commercial entity" notion into account: it will now look for
matches in children but also parents and siblings that are part
of the same "commercial entity". The default partner `type` is
now "contact" to reflect the new model ; "default" is
inappropriate because it is a wildcard and would stop the type
lookup early.
[This composes parts C and D of the solution on bug 1160365]
Note: This fix comes with a matching addons fix to implement
module-specific extensions of part B, as well as part E of the
solution.
* Address fields (bug 1160425)
Corrected autosync of address fields is also included in the
same branch, because those two mechanisms are closely related
and share some parts of the implementation.
The `use_parent_address` field now defaults to False (except
in the mini-kanban view of contacts on a partner form), and
the autosync of address fields has been modified to only work
downstream and never update a parent company if a child contact
is modified. Instead, the address fields are now displayed
readonly on contacts that use the parent address, with a button
to edit the parent address (new method open_parent(), similar
to open_commercial_entity() but opening the direct parent).
To make the initial creation of a contact + company pair,
a special case was added: when a new contact is created for
a company that has no other contact and no address, the
address of the contact is assumed to be that of the company
so it is moved to the company, then the `use_parent_address`
flag is enabled on the contact, and the `is_company` flag on
the company. This covers a use case where contact and
company are created on-the-fly when creating a new document.
Many logical flaws in the autosync of address fields have been
corrected and are now covered by unit tests.
* Misc related fixes
- checking `is_company` does not reset the parent_id field
anymore, to allow for multi-level structures. The field is
still hidden automatically because having an empty "Company"
field on the form view of a company is quite suprising), but
this UI behavior is easily customized;
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that
were sometimes synced when changing parent company are now
properly left alone;
- the `use_parent_address` field is now always visible next
to the parent_id field when a parent is set
lp bug: https://launchpad.net/bugs/1160425 fixed
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130408013742-tm8w0w0nmunanokk
2013-04-08 01:37:42 +00:00
for adr_type in adr_pref :
result [ adr_type ] = result . get ( adr_type ) or default
2008-07-22 14:24:36 +00:00
return result
2008-09-18 11:28:57 +00:00
2008-08-25 20:15:55 +00:00
def view_header_get ( self , cr , uid , view_id , view_type , context ) :
res = super ( res_partner , self ) . view_header_get ( cr , uid , view_id , view_type , context )
if res : return res
2012-12-14 12:38:03 +00:00
if not context . get ( ' category_id ' , False ) :
2008-08-25 20:15:55 +00:00
return False
2013-03-27 11:10:14 +00:00
return _ ( ' Partners: ' ) + self . pool [ ' res.partner.category ' ] . browse ( cr , uid , context [ ' category_id ' ] , context ) . name
2012-03-06 06:49:43 +00:00
2014-07-06 14:44:26 +00:00
@api.model
@api.returns ( ' self ' )
def main_partner ( self ) :
''' Return the main partner '''
return self . env . ref ( ' base.main_partner ' )
2012-03-06 06:49:43 +00:00
2012-06-25 18:22:29 +00:00
def _display_address ( self , cr , uid , address , without_company = False , context = None ) :
2012-03-23 06:40:37 +00:00
2012-02-27 10:05:30 +00:00
'''
The purpose of this function is to build and return an address formatted accordingly to the
standards of the country where it belongs .
2012-12-11 18:29:34 +00:00
: param address : browse record of the res . partner to format
2012-02-27 10:05:30 +00:00
: returns : the address formatted in a display that fit its country habits ( or the default ones
if not country is specified )
: rtype : string
'''
2012-03-06 06:49:43 +00:00
2012-03-06 06:09:34 +00:00
# get the information that will be injected into the display format
2012-02-27 10:05:30 +00:00
# get the address format
2014-07-06 14:44:26 +00:00
address_format = address . country_id . address_format or \
2012-09-11 10:17:29 +00:00
" %(street)s \n %(street2)s \n %(city)s %(state_code)s %(zip)s \n %(country_name)s "
2012-02-27 10:05:30 +00:00
args = {
2014-07-06 14:44:26 +00:00
' state_code ' : address . state_id . code or ' ' ,
' state_name ' : address . state_id . name or ' ' ,
' country_code ' : address . country_id . code or ' ' ,
' country_name ' : address . country_id . name or ' ' ,
2014-10-21 12:33:36 +00:00
' company_name ' : address . parent_name or ' ' ,
2012-02-27 10:05:30 +00:00
}
2013-04-11 19:11:10 +00:00
for field in self . _address_fields ( cr , uid , context = context ) :
2012-02-27 10:05:30 +00:00
args [ field ] = getattr ( address , field ) or ' '
2012-06-25 18:22:29 +00:00
if without_company :
args [ ' company_name ' ] = ' '
2012-09-11 10:17:29 +00:00
elif address . parent_id :
address_format = ' %(company_name)s \n ' + address_format
2012-02-27 10:05:30 +00:00
return address_format % args
2012-03-06 06:49:43 +00:00
2008-07-23 15:01:27 +00:00
# vim:expandtab:smartindent:tabstop=4:softtabstop=4:shiftwidth=4: