Using elif, if a method was found but not exposed (because
internal/whatever) the controller's index method would be skipped
during URL dispatch leading to a 404.
Since matched method yields an early return, a simple if will work,
and will *not* skip case where ``method and not method.exposed``
bzr revid: xmo@openerp.com-20130507081611-t2bfba2ai79xj1ew
The http controllers handler crashes when there are non-ascii chars in the url path.
`openerp.modules.module.ad_paths` containing unicode strings, werkzeug fail to compare the path `module` which is converted to ascii.
force `module` to be bytestrings
bzr revid: chm@openerp.com-20130502122806-1i9h8v0cvhb6p63q
Impossible to load the website when there is a unicode char in the url path.
`openerp.modules.module.ad_paths` containing unicode strings, werkzeug fail to compare the path which is converted to ascii.
force `openerp.modules.module.ad_paths` to only contain bytestrings
bzr revid: chm@openerp.com-20130502104249-ttokukc2rpetxqkr
Via this wizard, you will be able to merge a lot of partners via the email,
name, vat or other columns.
It is available in the "Sales/Tools" menu.
bzr revid: stw@openerp.com-20130502103044-ljnj5n7pvs1vsbed
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
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
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
Thibault Delavallée