But chrome is now unhappy...

GadgetField doesn't know how to validate/store REQUEST form data.
Use an external field to handle this task.
The external field must be located in the same form, and can be put in the hidden group if not rendered.

Add a test with a stringfield and a textarea field as validator.

Make ckeditor responsive.
Disable ACF.

Notify on changes.
Allow to save with Ctrl+S
Add a ruler
Disable Crtl+R

Thanks to Tristan Cavelier for his original work.

Listbox can embed rjs gadget

It is no longer maintained.
Switch to ck_editor instead.

ung has been replaced by officejs.

This editor has been deprecated and is not supported anymore.

This bt5 provides required portal types (Web Style, ...)

This reverts commit 8076005e.

Web Illustration is already provided by another bt5.

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 !433

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

/reviewed-on !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 !456