This makes the inherited view still compatible with
modules that depend on the presence of the `name`
field in the list view (otherwise it would depend on the
module loading order and would sometimes work and
sometimes not).
bzr revid: odo@openerp.com-20130422141518-imyiuu59uxnzq5eh
integer/float fields were not offering auto-completion in search views,
making them unsearchable except via advanced search.
This patch adds the missing complete() function and removes the incorrect
value_from() function that did not conform to the 7.0 search view API.
It seemed to be a leftover of the 6.1 search field implementation
of get_value(), wrongly renamed for 7.0.
Also includes corresponding tests.
bzr revid: odo@openerp.com-20130418112001-388op1t8ugr0rhfn
This patch will be forward ported in trunk by changing the behaviour of account_period.find() in order to fetch the normal periods by default (account_period_prefer_normal will be True by default) because there are no business case i could think of where you'd like to get the opening period (except in the closure but it's held in a different way there). On the other hand, it's pretty easy to forget to put that key in the context and introduce a new bug that will select the opening period instead of the wanted one
bzr revid: qdp-launchpad@openerp.com-20130418102433-t52uj23trkpr8vnb
When extending a controller in-place (e.g. A(Controller), B(A)) and
providing the exact same _cp_path as parent (no-op) execution path
would go into handler for _cp_path overwriting and raise an assertion
error for overwriting of existing controller.
Except this is allowed (if ugly) pattern, so warn & ignore behavior
(it is harmless).
bzr revid: xmo@openerp.com-20130418092405-wrmmrd648b9koefu
Failing to force a manual update of the mail module would cause
all composer wizards to display html contents without the WYSIWYG
editor, making it mostly unusable for regular users. Users are
not expected to always force an update of all modules after
updating to the latest source code.
bzr revid: odo@openerp.com-20130417081410-dwc33ymizlihvbng
When a record is activated, the listview will do some jiggling around
assigning the ids of internal dataset to the one shared between all
views, this is mostly for the case where one switches from a "grouped"
list view, so the form view only cycles on the "current" group.
Problem is, that internal dataset is not correctly synchronized with
the shared one, so when the id is removed from the shared dataset it
is *not* removed from the internal one(s), and when the switch is made
the ids from the internal dataset are set on the shared one and
reintroduce the deleted record, leading to the form view's incorrect
state.
Fix the issue by updating the dataset's ids list when a record is
deleted from the records tree.
Also extracted some stuff from DataSetSearch's unlink callback so it
can be overridden and is more stable across datasets.
lp bug: https://launchpad.net/bugs/1161210 fixed
bzr revid: xmo@openerp.com-20130416152000-06dbwkgdb8zlf9pc
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
Dharti Ratani (Open ERP)
Quentin (OpenERP)
Launchpad Translations on behalf of openerp
Olivier Dony
Cedric Snauwaert
Thibault Delavallée
Fabien Meghazi
niv-openerp
Xavier Morel
Antony Lesuisse
Stephane Wirtel
Christophe Matthieu