This business template contains all the objects needed to bootstrap an ERP5 instance in order to prepare it for scalability tests:
- A business configuration object (generated after standard configurator installation)
- A bootstrap script (pending)
- A script that generates a specific amount of users (person-assignment-login per each)

The main change here is the reduction of try..except scope, so failing the
first assertion does not cause an AttributeError about original_query.
Also, avoid code duplication by just checking final number of messages
outside the try..except block.
Also, improve coding style (spaces around operators and commas).
Also, avoid single-use variable.
Also, fix typo in comment.

to fit to the new behavior related to these changes :
- 2c74e408
- a40266af

Commit 89a17f04 broke live tests using
ERP5TypeTestCase.publish when they are run from command line. Note that such
live test could not be run from ERP5.

More refactoring is needed because ERP5TypeLiveTestCase should only take care
of adapting ERP5TypeTestCaseMixin to an ERP5 environment, and runUnitTest
should never use it. Commit fd9219af looks a
wrong approach.

Usually, the split and defer dialog suggest you to define start and stop date. So if you have
already an existing delivery and you would like it to be updated, you have to set correct start
and stop date and, if all categories are fully the same, you might have some chance to see
this delivery updated.

To improve the case where you would like to move quantity to existing delivery, add option in the
solve divergence dialog of "Move to existing Delivery" that allows you to select similar deliveries. Then
this specific solver would set correct properties for you to make sure the expected delivery would be updated.

A change that also applies to traditional tests is that the password does not
need to be known when logging with basic authentication. If the given password
is empty (e.g. 'ERP5TypeTestCase:'), password validation passes regardless the
actual password: to keep things secure, this exception is only valid for the
test thread and during the call to publish(). This is a simple way to deal with
random passwords in live tests.

* For the purpose of easy customisation

We use internal transactions for invoices and any kind of accounting transactions (in reality, it's not limited to *invoice*), this is a set of changes to make it easier to record payments between two entities with internal transactions.

* We add a *Section Bank Account* field directly on the view ( ![Screenshot_2017-10-04_at_19.36.53](/uploads/4b1f22b5d5e6c1f77a70ea717c2323d9/Screenshot_2017-10-04_at_19.36.53.png)
* Reconfigure  *Causality (Invoices ...)* relation fieds to allow allow every accouting transactions portal type, so also Internal Invoice Transaction ...").  This way, when creating the "payment" internal transaction, we connect it to the "invoice" internal transaction  and grouping reference is set automatically when posting to general ledger.
*  Enable the *Create Payment* action from (which exists on sales and purchase) on normal invoices.

The rest is  small cleanup / fixes described in commit messages.

/reviewed-on nexedi/erp5!433

Various improvements to `CodingStyleTestCase` so that it can be used in a project test suite.

/reviewed-on nexedi/erp5!455

Usually, the split and defer dialog suggest you to define start and stop date. So if you have
already an existing delivery and you would like it to be updated, you have to set correct start
and stop date and, if all categories are fully the same, you might have some chance to see
this delivery updated.

To improve the case where you would like to move quantity to existing delivery, add option in the
solve divergence dialog of "Move to existing Delivery" that allows you to select similar deliveries. Then
this specific solver would set correct properties for you to make sure the expected delivery would be updated.

when form is used in another context (web section for exemple).

/reviewed-on nexedi/erp5!456

Not used in this test, but since it's made to be reusable in projects.

do not limit to the first script with errors

It produces almost same visual result

they may contain folder containing skins

Don't test a skin folder twice when business template is present more
than once

/reviewed-on nexedi/erp5!453

To make predicate lookup a bit faster by keeping `predicate` and `predicate_category` small, do not index the documents we do not need in these table. This is done for `Assignment`, `Career`, `Payment Condition`, `Delivery Cells`, `Budget Line` and `Budget Cells`.

/cc @vpelletier @kazuhiko  @tiwariayush 

/reviewed-on nexedi/erp5!257

ERP5's Code mirror supports viewing history of editions using codemirror's merge mode ( http://codemirror.net/demo/merge.html ).

This was enabled for portal_components, but not for web pages.

This moves the methods used by the components in a mixin class and make `TextDocument` class use this mixin.

This way, we can benefit from diff view on web pages as well:

![ERP5-history-on-web-pages](/uploads/2bd381948266da46225ae26fd807bd51/ERP5-history-on-web-pages.png)

@romain @vincentB @katomaso unless this interfere with your work of making codemirror works in renderjs ui, I think we can enable this. It does not include any change to codemirror code, just enable everywhere what was available only on components.

@klaus I did not check, but we probably want this enabled for PyData Script as well.

/reviewed-on nexedi/erp5!449

keep backward compatibility with erp5_officejs_support_request_ui

- fails if 0
- fails if too much
- also applied for predecessor

keep backward compatibility with erp5_officejs_support_request_ui