This reverts commit 35b2c024.

Allow edition in the new UI

This make everything slow as hell and prevent to quickly save.

Example: <h2 class="foo">bar</h2> => <h3 class="foo">bar</h3>

This should have no impact on existing code as pylint is ran on a named
temporary file anyway but it avoids useless checks for relative imports
and thus is slightly faster.

See merge request nexedi/erp5!1144

adjust tests now that the test component itself is found by catalog.

* Import Movement Document:
  + Event
    + MailMessage
  + Project
  + ImmobilisationMovement
* Imported by IMovement:
  + IAccountingMovement
  + IAmountGenerator
    + AmountGeneratorMixin
    + AmountGeneratorLine
  + IAssetMovement
  + IProductionMovement
* Used by MovementGeneratorMixin:
  + IMovementGenerator
  + IMovementList

Also, define providesI<INTERFACE_NAME>() on Base class for migrated Interfaces as
these needs to be available before bt5 containing the ZODB Component Interfaces are
upgraded (see also c86107bf). Otherwise, testUpgradeInstanceWithOldDataFs fails as
z_catalog_item_list (newActiveProcess() from upgrader) calls providesIMovement().

This also moves ImmobilisationItem and its interface from erp5_immobilisation
to erp5_core as ImmobilisationDelivery import them.

* Discount: Portal Type actually uses Resource Document.

We were only checking if the defaut charset or default collation were
same, but if anything is different in the table options, we should
update it.

Also add a missing test for updating column comment

Not a proper tool to search source code, but makes it possible to search
for source code in component.

test_apply_model_filled_computer_batch_mode did not pass batch_mode
and was wrongly checking that result is True

Test was passing, because without batch_mode Computer_applyComputerModel
returns Base_redirect, so the result is indeed evaluated as True.
Yet in this case we should expect False, since no changes are applied

this is required for stock browser to work in ERP5JS with Component
portal type

and make it possible to create the test delivery using a component as
resource

Do it once, after any business template deletion and install happened.

Several bug fixes for business template update bugs, including a fix for the problem preventing to update erp5_accounting_l10n_fr

See merge request nexedi/erp5!1112

These new versions contain several small improvements.

It seems this version of prettier formats javascript in a way that jslint does not complain about.

Also contain some small fixes for our renderjs and rsvp type definitions, so that monaco-editor-gadget.js can typecheck.

See merge request nexedi/erp5!1139

* "Create Skin Folder" action had a typo, so it was not setting the `business_template_skin_layer_priorty` property that business template is using when installing.
* "Create Report" was not updated for the new "action title" feature of forms.

This time, add the missing tests that should have prevented these problems.

See merge request nexedi/erp5!1133

Enable coding style on erp5_forge, after removing several problematic scripts that did not seem used.

See merge request nexedi/erp5!1134

This is not supposed to happen and can hide errors.

This addresses the problem of
https://nexedijs.erp5.net/#/bug_module/20180719-135FAA8 a KeyError
raised when some categories in a subtree are modified and some are
removed and the corresponding base category is also installed as a base
category.

The problem was that both CategoryTemplateItem, which is in charge of
updating the base category and PathTemplateItem, which is in charge of
updating the categories listed as path both use the same
ObjectTemplateItem.install method, with the same object_to_update dict.
ObjectTemplateItem.install uninstall all objects that are listed in
object_to_update and not in self._objects so something like this
happened when business template from
test_update_business_template_with_category_having_subcategory_tree_modified
is updated:

  1. PathTemplateItem.install is called for the base category,
portal_categories/test_category/modified/removed looks removed, so it is
backed up. Because the the parent paths are not parts of self._objects,
trash tool will create simple trash folder for
portal_categories/test_category/modified

  2. PathTemplateItem.install is called for the paths,
portal_categories/test_category/modified is modified, so the previous
version will be backed up. At this point trash tool looks in the trash
bin and the path for portal_categories/test_category is already present,
so trash tool sees that path exists and does not return subobjects, so
after portal_categories/test_category/modified is modified, the subjects
such as
portal_categories/test_category/modified/container_in_which_child_is_added
are not restored and creating 'added' caused a
KeyError('container_in_which_child_is_added')

The approach is to make CategoryTemplateItem.install only consider base
categories - ie. objects where path is portal_categories/* and not the
subobjects, because they don't belong to CategoryTemplateItem but to
PathTemplateItem.
Co-authored-by: Georgios Dagkakis <georgios.dagkakis@nexedi.com>

Business template have some logic to keep uids when updating objects:
during installation, when an object is modified, business template first
remember the uids for this object and all its sub-objects,
replaces this object with the new version then recursively set the uid
on updated objects, so that updating an ERP5 document by business
template does not change its uid because this would break catalog.

When an object containing sub-objects is updated, it becomes a new
object in ZODB and sub-objects of the previous object are set as child
of the new object. This works even if the case of sub-objects being
instances of ZODB Broken class, except that the step where we restore
the uid fail as it's not allowed to modify a broken object.

Instead of unconditionnally setting the sub-objects uids, check that we
actually need to set it, because if it's already the expected value then
we don't need to touch the object.

In monaco 0.20.0 "peek references" is not properly displayed when
automaticLayout is true. This is fixed on master branch so next release
should be OK.

For now, use a resize event handler to re-layout the editor when size
change, then we don't need the automaticLayout.