Document created text was not translatable
Subtype was fetched without context, therefore not translated
Removed odd override of _t introduced in mail_followers at revision 7885
bzr revid: tde@openerp.com-20130408092447-3ri41v6xluuj0wha
* 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
Fixes handling of accounting/invoicing-related fields on partners
that are not "commercial entities" (either marked as "is_company"
or parentless).
The corresponding fields are also hidden from form views on these
partners and replaced by a short sentence and a link to edit the
"master fields" on the commercial entity.
This corresponds to part B of the solution described on bug 1160365.
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130407235013-j3tv4uxy46eej43i
Add support for 'no result' help message in kanban views.
Add css for empty list in kanban views + generic display of mail aliases.
bzr revid: tde@openerp.com-20130405152131-4auticfaj24wbpqx
This revision adds a configuration in Settings/Sales: enable the use of sales team. If not enabled, users have access to Leads and Opportunities menus; Sales Teams menu is hidden, as well as all fields related to sales teams. If enabled, a Sales Teams menu is added that works as the Project menu. The new sales Teams kanban view allows to have an overview of the sales team (leads, opportunities, quotations, sales orders, invoices). Clicking on a link of the kanban vignette redirect to the related list/kanban view, filtered by the chosen sales team.
This revision also improves the display of help message (also shown for empty kanban views) for leads, opportunities, tasks, issues, applicants. It displays the current sales team / project / job alias, or a default alias if no context is provided.
bzr revid: tde@openerp.com-20130405151914-8892yfmsmr2xwbbk
The conversion code is duplicated in sale_stock and purchase
instead of being factored out in the fields.datetime class
because as of v7.0 users are able to selectively update
a single module without necessarily updating the base module
or the framework. This will be improved in next stable version.
lp bug: https://launchpad.net/bugs/1153107 fixed
bzr revid: odo@openerp.com-20130405151451-anjsdt18gmsxr01k
ir_action:
- removed size on char fields
- help is now somewhat dynamic; it calls get_empty_list_help on the related model that could be overridden to display a custom message instead of the generic one defined on the action
BaseModel:
- added get_empty_list_help method, that basically returns the help that is given into parameter. Its purpose is to be overridden by models that should customize the empty list help message
bzr revid: tde@openerp.com-20130405150952-5f7sr2f61obl74yw
Cedric Snauwaert