This patch comes with a corresponding server-side patch (revision 4946 revid: odo@openerp.com-20130420032529-pvv6vuelp84bt26j)
- module-specific overrides of _commercial_fields() for all modules adding accounting/invoicing-related fields to res.partner
- corresponding changes to inherited views of res.partner form to hide these commercial fields when they are in fact "related fields" of their parent commercial entity. This mainly concerns 2 sections of the Partner form: the whole Accounting tab, and the bottom of the Sales&Purchase tabs with the pricelists and invoicing fields. These sections are replaced by a short message and a button to open the commercial entity to view/edit the fields
- a few fixes to properly delegate the resolution of various contact/address types to the corrected res.partner.address_get()
- changes to search views of the main business documents so that searching for a company name will also match its contacts
- a fix of the _find_accounting_partner() method that the account module uses to locate the partner to which journal entries must be linked - it will now use the same semantics as for "commercial entity"
- fix issue detected by Joël Grand-Guillaume in comment #34 of bug 1160365: when invoicing after delivery, the invoicing contact/address must be used rather than the main customer. Tests updated accordingly.
- add new 7.0 module "account_report_company": this module adds an extra stored field "commercial_partner_id" on Invoices to make reporting/aggregating by partner easier in the Invoice list and in the Invoice Analysis report. This module is expected to be merged in the main account module in the next major release. The module can be installed without any risk on any existing 7.0 databases.
This module also mitigates group_by issues on all models by adding a new stored function field `display_name` on res.partner that contains the name_get() result in the form "ACME, John Doe" and set it as the default _order for res.partner. This ensures that group_by entries for the same company will always be next to each other on all documents: "ACME" is directly followed by "ACME, John Doe", "ACME, John Anderson", etc. This field also replaces the `name` field in the list and kanban views of Partners, so that the display order matches the display labels.
- fixed unique constraints definition on some commercial fields on res.partner (l10n_ro)
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130420034221-2wvf6rezwl7gog74
- 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
It works when installing the module but would break
everytime another module that inherits from res.partner
is installed/update from command-line (e.g. -i/-u crm),
as account_report_company is low in the dependency graph
so the field is dropped when the ORM notices that
the current field definition is not stored.
This can be solved in trunk by making the field stored
directly in 'base'.
bzr revid: odo@openerp.com-20130420015003-8y48xrb14cjif60w
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
This is not strictly necessary, but can be useful for other
modules in order to ease SQL reporting, without even needing
to store a denormalized copy of the "commercial partner" key
on the documents themselves.
Also renamed the Python fiel to something generic since
it now inherits multiple models.
bzr revid: odo@openerp.com-20130419134335-rhsg24f2uuwl3kla
Martin Trigaux