The original query did two passes (SQL query and orm search). This was a problem due to the limit parameter where the second query could reduce the number of results to a smaller number than the asked limit.
This code reproduces the orm _search behaviour to execute only one SQL query mixing both the ACL clauses and the complexe name_search without degrading the performances (removing the limit in the first query would have).
lp bug: https://launchpad.net/bugs/1203727 fixed
bzr revid: mat@openerp.com-20140129105548-dd6zmy9uc2cuowpq
The main reason for the semi-random behavior
observed during auto-completion is the
missing ORDER BY clause in the pre-filtering
SQL query.
The ORDER BY clause is expensive but inevitable
if we want to apply a correct LIMIT, otherwise
we would return random `limit` results among
all the possible matches.
The current SQL query seems convoluted due
to the duplicated CASE clause but it
performs slightly better than the equivalent
CTE-based (WITH...) query, so it was preferred.
There is still a chance of returning too
few results due to double limit application,
as further discussed in bug 1203727
lp bug: https://launchpad.net/bugs/1203727 fixed
bzr revid: odo@openerp.com-20130905170251-x47w1zrm43d0k9wb
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
- 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
It is valid to use the parent address but still set a different
type of address - the name, email, phone, etc. could be different.
bzr revid: odo@openerp.com-20130410123229-9l60sbcks3tpmy7x
Using the commercial entity is not a very good default choice
in many cases. If a new contact is created on-the-fly for a
new document (e.g. sales order), his/her company may be an
empty shell and/or a large corporation that should not be
directly used for e.g. billing/invoicing purposed.
Once a contact/company is set to "invoicing" or "delivery"
we use it, but in other cases we stick to the provided
partner/contact as a saner default.
This should not change anything for cases where advanced
contact management is used and proper address types are
set.
bzr revid: odo@openerp.com-20130410121536-vm93o6vxhi3b8feu
* 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
* when writing an empty value to ADDRESS_FIELDS, that value
should also be propagated by update_address()
* when creating a contact from a company form view, even with
'use_company_address', company's contact address remains empty. We
now force adding missing address fields uppon creation when default
'use_company_address' is True.
bzr revid: xal@openerp.com-20130329112317-6lat4jx5x2yh18t6
Either use openerp.modules.registry.RegistryManager when the full
new() signature is needed, or use openerp.registry().
Replaced also some pool.get() with pool[] because KeyErrors
are better than AttributeErrors on None.
bzr revid: vmt@openerp.com-20130327111014-2i0hlvpy5y5ku7hm
Fixes some of access rights issues. This server branch features :
- update of res.users model, where the feature allowing to write on its own user on WRITABLE_FIELDS is duplicated for reading. This allows for users not having read access on res.partner to read some of their data.
bzr revid: abo@openerp.com-20120928173657-2a25tw1ewc7ugyr3
Martin Trigaux
Darshan Kalola (OpenERP)
Thibault Delavallée
Fabien Pinckaers
Christophe Simonis
Olivier Dony
Denis Ledoux
Holger Brunn
Rifakat
Jigar Amin (OpenERP)
niv-openerp
Christophe Matthieu
Vo Minh Thu
Amit Bhavsar (Open ERP)
Cedric Snauwaert
Dharmraj Zala (OpenERP Trainee)
ggh-openerp
Xavier ALT
Fabien Pinckaers
Niels Huylebroeck
Cecile Tonglet
Raphael Collet
Xavier Morel
Fabien Meghazi
Antony Lesuisse
Divyesh Makwana (Open ERP)
ajay javiya (OpenERP)
Nimesh (Open ERP)
Quentin (OpenERP)
Antonin Bourguignon
Amit Patel
Khushboo Bhatt (Open ERP)