This should not be needed but in the initial 7.0 branch
the default for use_parent_address was True so it was
set even on partners that had no parent company.
Now that the fields are read-only when that option
is enabled, it makes the address impossible to
edit. At least by making it visible we give the
user the opportunity of fixing it manually.
Can also be fixed at once with a single SQL
query:
UPDATE res_partner set use_parent_address = false
WHERE parent_id IS NULL;
bzr revid: odo@openerp.com-20130425163916-ou7jjr6xbopfwvrc
- 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_partner_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.
- Corrected autosync of address fields (bug 1160425). Also included in the same patch, because those two mechanisms are closely related and share some parts of the implementation. "use_parent_address" now defaults to False, and auto-sync only happens downstream, except for a special case when creating a new company and a new contact at the same time
- `is_company` does not reset the parent_id field anymore, to allow for multi-level structures. The `parent_id` field now also stays visible if it has a non-empty value
- the `email`, `phone`, `fax`, `mobile`, `lang`, etc. that were sometimes synced when changing parent company are now properly left alone
- res.partner.address_get() now defaults to the partner being looked up rather than company when no match is found at all and no "default" exists. This avoids losing the contact info on invoices when a new contact+company pair is created.
- the embedded contact creation mini-form was updated to include the address fields and the `type` field
- res.partner.name_get now return "Company, Contact" rather than "Contact (Company)" to make it clearer that the company is selected as well.
- Added warning message when changing the Company of a Contact that already has a company, so it is clear that it should only be done if the Company was incorrect - in other cases a new contact must be created under the new company.
- Fixed search domains using "child_of" to also include deactived records, so that using this operator in the search view of business documents returns the expected results.
- fixed propagation of "is_supplier" flag when creation a parent company for a contact created on the fly on a Purchase Order, and when adding contacts to an existing Supplier Company
lp bug: https://launchpad.net/bugs/1160365 fixed
lp bug: https://launchpad.net/bugs/1122363 fixed
lp bug: https://launchpad.net/bugs/1160425 fixed
bzr revid: odo@openerp.com-20130420032529-pvv6vuelp84bt26j
Now that res.partner.child_ids has an extra domain
attribute the exact number of parameters of queries
using `child_ids` in the WHERE clause is different.
bzr revid: odo@openerp.com-20130419173159-ef1onm3823hsi77n
This is more consistent with the way we expect reporting
to work, and will also ensure that these companies
appear right above their contacts in search order
(which will match name_get)
bzr revid: odo@openerp.com-20130419164728-25312wtyzt9h6egw
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
The name `commercial_partner_id` better reflects its
purpose and the fact that it is a FK to a partner.
An extra indirection through a lambda function was
also added to the definition of the function field
to make it possible to override it in other modules
(otherwise the function is passed by copy directly
and cannot be inherited later)
bzr revid: odo@openerp.com-20130418144533-owupfwn6h83q432x
This prevents hiding real data and also allows creating more
complex/flexible structures by setting the values of these
fields before or after setting is_company, to reach the
desired result.
bzr revid: odo@openerp.com-20130416093403-9m484d30qqq5ab8l
This is not necessary for the `is_customer` flag, as it is
always True by default (customers are created more frequently).
Passing the field value via an invisible field in the mini
contact form is necessary because context `default_*` values are
automatically discarded by the ORM when creating o2m
or m2m records (as they are supposed to apply to a different model).
bzr revid: odo@openerp.com-20130416091027-y7iwvpjhowg53lry
- res.partner must prevent creating loops in partner
hierarchies, and this can be done easily with an
extra _constraint using the ORM's builtin _check_recursion
- _check_recursion's implementation incorrectly
assumed that the provided 'ids' were unrelated
(not part of a common hierarchy).
- add tests for _check_recursion via extra
tests on res.partner structure
(explains why both patches are in the same
commit)
bzr revid: odo@openerp.com-20130415171732-aj3j2e2mycvzf4kp
super() finds the MRO parent of the provided class to resume the
execution chain from there, so the class being defined should be
provided.
Here view called super(osv.osv, self).create so if osv.osv (Model) had
a create() defined (which luckily it does not) it would've been
skipped.
bzr revid: xmo@openerp.com-20130415105744-cfx47t01oc7loyes
Xavier Morel
Olivier Dony
Launchpad Translations on behalf of openerp
Quentin (OpenERP)
Antony Lesuisse
Christophe Simonis
Stephane Wirtel
Cedric Snauwaert