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 server branch comes with an addons branch where the various
items of the history tab are removed and transformed into
contextual buttons.
Names are added to two pages of the partner notebook to be able
to reference them in future inheritance.
bzr revid: tde@openerp.com-20130614120540-5qvvh07cu2quwi71
The policy is to have a one-line paragraph with
class `oe_view_nocontent_create` that directs the
user to the create button. There are exceptions
when the action is not supposed to be used to
create new records, in which case the help
text should indicate so.
lp bug: https://launchpad.net/bugs/1165321 fixed
bzr revid: odo@openerp.com-20130607162045-7di6r2fllm6k988x
Unfortunately the group names are translatable,
and the display name is based on the hierarchy
of groups, so this will not give a satisfactory
result. What we would need ideally is to be able
to sort on the translated "full name" value,
but this is not supported by the ORM yet.
But a stable order is still better than no
order at all
bzr revid: odo@openerp.com-20130522163201-f9zo7xnjvbs2mi97
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
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
We should never turn the `use_parent_address` option on
unless the user explicitly wants to use it. It makes
further editing more convoluted (need to go to the
company address) and is really an advanced feature.
It was only set by via context defaults when adding
contacts to a company ; we can replace that with a
set of defaults that will copy the company address
fields to the contact. Users can still switch to
automatic synchronization if they really want it,
or simply further edit the address of the contact.
Also fixed the layout of the mini-form view, now
using a simpler vertical layout with address at
bottom, since the main info of a contact needs
to be entered first.
bzr revid: odo@openerp.com-20130410170101-t9covdj6nmyn44jf
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
Apprently on 2013-03-08 Google Maps stopped
returning a location in Belgium for this invalid
street name.
We consider Google Maps as a commodity so it
is ok to have the crm_partner_assign tests
fail in case our lookup mechanism does
not work anymore.
Note: this is a cherry pick of the 7.0
fix as a quick fix because the complete
forward-port of 7.0->trunk will require
some more time for conflict resolution
bzr revid: odo@openerp.com-20130308103110-eoj3lme49vy5jo91
Apprently on 2013-03-08 Google Maps stopped
returning a location in Belgium for this invalid
street name.
We consider Google Maps as a commodity so it
is ok to have the crm_partner_assign tests
fail in case our lookup mechanism does
not work anymore.
bzr revid: odo@openerp.com-20130308094115-frjp99xi296oosxl
Some important points to consider:
- signaling should be done after any schema alteration (including module [un]installation),
service registration (e.g. reports)
- the changes need to be committed to the database *before* signaling, otherwise an
obvious race condition occurs during reload by other workers
- any call to restart_pool() must be considered a possible candidate for
signaling, and the 2 above conditions must be checked
The number of explicit calls was reduced by forcing the signaling at the end of
Registry.new() in case `update_module` was passed as True. In that situation
we always want to signal the changes - so all the redundant signaling calls
can be centralized. We can also assume that the relevant changes have already
been committed at that point, otherwise the registry update would not
have worked in the first place.
This means that there is no need for explicit signaling anymore everytime
`restart_pool` is called with `update_module=True`.
Some missing cr.commit() and explicit signaling calls were added or
moved to the right place. As a reminder: signaling must be done
*after* committing the changes, and usually *after* reloading the
registry on the current worker.
bzr revid: odo@openerp.com-20130301143203-e2csf5pkllwhmwqs
This config parameter is automatically updated when the admin log-in.
As this value is mean to be used in emails and links given to users, we sometime don't want
it to be updated inconditionnaly. In some cases, the admin may use alternative, private or
even local uri to connect to the server, which may not be suitable for users
bzr revid: chs@openerp.com-20130301095551-fzrlwblnawxqj9di
That function was kept because its `intersperse` reimplementation
behaves a bit differently but it was a long time ago and no bug
report appeared. So the new function is good enough.
bzr revid: vmt@openerp.com-20130212111244-aayco60ps923fn55
Fabien Pinckaers
Darshan Kalola (OpenERP)
Thibault Delavallée
Dharmraj Zala (OpenERP Trainee)
Atul Patel (OpenERP)
Christophe Simonis
Martin Trigaux
Pinakin Nayi (OpenERP)
Olivier Dony
Darshan Kalola
Denis Ledoux
Rohan Nayani (Open ERP)
Chirag Dodiya (OpenERP Trainee)
Holger Brunn
Rifakat
Vo Minh Thu
Quentin (OpenERP)
Jigar Amin (OpenERP)
niv-openerp
Christophe Matthieu
Nimesh Contractor (OpenERP)
Jignesh Rathod (OpenERP)
Amit Bhavsar (Open ERP)
cbi@openerp.my.openerp.com
Vishmita Jadeja (openerp)
Cedric Snauwaert
Raphael Collet
Jagdish Panchal
Tejas Tank
Xavier Morel
ggh-openerp
Ishwar Malvi (OpenERP Trainee)
Stephane Wirtel
Fabien Meghazi
Xavier ALT
Fabien Pinckaers
Ravish (Open ERP)
Antony Lesuisse
Niels Huylebroeck
Antonin Bourguignon
Ravi Gohil (OpenERP)
Josse Colpaert
Dhruti Shastri
Dharti Ratani (Open ERP)
Vidhin Mehta
Turkesh Patel (Open ERP)
Hiral Patel (OpenERP)