Do log it, but do not let it propagate.

Since early days of @arnau work on ERP5 components, we have pylint integrated as a way to check the code in components and in python scripts but nothing prevents us from commiting code with lint errors, leaving the problem for the next developer. 

For this, I extended [`CodingStyleTestCase`](https://lab.nexedi.com/nexedi/erp5/blob/88e4b34ff67aa07447f81c8af836feba607843e8/product/ERP5Type/tests/CodingStyleTestCase.py) that was introduced for very similar purpose so that it also  use our tool to check python code. This way,  we can have failing tests when the code do not pass pylint.

What's still not good is that if we want a business template to be tested, we have to explicitly add a test for this business template, but it's also the case for all our "static" tests (naming conventions, HTML validation etc).


A missing feature was that there was no way to get an overview of all the reported problems on a business template. For this, I added a report action on business template that uses the same code to display errors in all *python* code from a business template:

![ERP5_pylint_business_template](/uploads/13613199227884f0340b8f1c40ca4418/ERP5_pylint_business_template.png)
( the lines have direct links to edit python code )

Because `testERP5WebCodingStyle` was already here checking `erp5_web` (well not really because it was no longer using `CodingStyleTestCase` correctly) , I fixed all problems reported by pylint in erp5_web. In reality it only took a few minutes to do this.

PS: I don't know exactly how we could integrate javascript linter in all this. We have a [`test_javascript_lint`](https://lab.nexedi.com/nexedi/erp5/blob/master/product/ERP5/tests/testXHTML.py#L171), but it does not test much of the code written recently because it only checks portal skins. @romain and @vincentB maybe have plans for this. Anyway, it's out of the scope of this.

/cc @kazuhiko @vpelletier @tc 

/reviewed-on !308

erp5_mysql_innodb_catalog: add safety LIMIT in z_getitem_by_path and z_getitem_by_uid to avoid fetching all rows in case of empty argument.

otherwise Localizer will not work in grouped activity.

business template metadata was not commited

This replaces ERP5Site_checkPythonScriptsWithPyflakes that I guess
nobody was using

CodingStyleTestCase tests by default the last business template returned
in getBusinessTemplateList, but  getBusinessTemplateList returned value
changed overtime and this test did not really test erp5_web

Also name include "ERP5 Web" in test class name, as it tests ERP5 Web.

This is for catalog brain displayed in Listbox.

It exists in portal_types

* explain how to use
* remove useless getTitle method
* fix indentation

[erp5_hal_json_style] Fix ordering of annotations in the test to set the right skin at the beginning

Catalog does not need "resource_uid" when it requested for
"resource_use_uid", so don't spend time computing it.

Allows searching for, for example:
  some_relation_uid=[123, None]
without having to resort to:
  ComplexQuery(
    SimpleQuery(some_relation_uid=123),
    SimpleQuery(some_relation_uid=None),
    logical_operator='OR',
  )

To prepare for extension.

Otherwise, some otherise-matching predicates may be excluded from the
search, and will not be applied.

Query has a higher overhead than SimpleQuery, and should be avoided
wherever possible.
Also, get rid of two unnecessary intermediate ComplexQuery levels.
There are a few remaining Query uses here, which should go away soon.

Also, use valid base categories for
not-in-preferred_predicate_category_list test.
Also, improve coding style.
Also, after changing preferred predicate category list, only reindex
the module containing predicates instead of the whole site, to reduce
test duration.

This ZSQLMethod is shadowing the one ERP5Catalog is trying to use, and
it has a table list incompatible in 2 ways:
- it joins again with catalog, despite only being used to pick the uid,
  which ERP5Catalog stopped doing for auto-generated related keys
- it is actually a chained related key: resource, then use. But
  "resource_use" exists as a Base Category, and is accessible (but broken
  until this change) as "default_resource_use_uid" (for example).

aggregate_uid can be auto-generated with one less join, and chosen
ZSQLMethod name gets in the way of auto-generated related key
(default_aggregate_uid and the like).

* Remove include_empty_item: We always want an empty item in dialogs
* Remove include_gap_in_path: This was always true

simplify code a little bit.

* There was another level of cache in Account_hashGapItemList
* Category title was used in AccountModule_getAvailableGapList

Unlike other database adaptors, memcache adaptors can be shared among
transactions. So pool them in order to reduce the number of connections
established to memcached servers. And as the connections handle
thread-safety internally (by inheriting from threading.local), threads
can share the same connection instance.
Also, do not create a new connector each time we get disconnected, just
reconnect.
Also, memcached internally retries connection, so no need to retry it
ourselves.
Also, do not log when failing to update & delete entries in cache
server: this is a racy cache, each read much be checked anyway, so
failed writes are just business as usual.
Also, document a bit more why we catch "any" exception happening during
finish, and specify base exception class following python coding best
practices.
Also, use named constant for loggin levels for remaining log directives.
Also, display traceback when catching a connection issue during
__getitem__, as the original exception gets converted into a KeyError.

/reviewed-on nexedi/erp5!305

This includes two parts, first is to change the condition for an organisation to be able to use the bank accounts from organisations from parent groups. This is useful for the case where organisations from subgroups does not represent different legal entities but simply some "business units". 

The condition for that have always been: if organisation does not contain bank account, this organisation can use bank accounts from the parent groups.

To be consistent with other places, such a closing accounting periods or setting grouping references, change the condition to: if the organisation does not contain accounting periods, this organisation can use bank accounts from parent organisations.

The behavior should not change much and allow to create bank accounts or cash registers that can be used only in one sub-group organisation.


Second part is about making it visually easier to understand which organisation the bank account belong to by adding some non-selectable options in the select for the organisations. This is only enabled when available bank accounts are not all contained in the same organisation.

![Screenshot_2017-06-19_at_15.24.35](/uploads/dc538645bb79a00f25444547d524635f/Screenshot_2017-06-19_at_15.24.35.png)

/reviewed-on !299