An insolvency proceeding represent a justice decision about the insolvency of a person or an organization.

An insolvency proceeding is defined by: an Insolvency Proceeding Type, a Creditor, a Debtor, Judicial Administrator, Judicial Representative.
The insolvency proceeding follow the ticket workflow

This test should catch when business templates metadata in `bt/` is different from the actual content in `*TemplateItem/` . It should not happen, but sometimes we can forgot to include one or the other in commit.

This also fixes problems in the currently tested business templates, there was three kind of problems:
 * binary files are now exported with `bin` extension, it use to be `obj`.
 * In several business templates, we export categories as `portal_categories/category/*`, while this looks convenient, it's problematic when categories are added by other business templates, every time developer export the business template they have to consider whether the new paths should be exported or not. This changed to list explicitly all the paths to include in business template.
 * some business templates were partially commited ( "erp5_dms_ui_test:  Add selenium tests" )

/reviewed-on nexedi/erp5!1049

Make it pass coding style

"Hide" an action that is not really useful and problematic when used by mistake

/reviewed-on !1051

This way, the substitution mapping method can return a dynamic mapping,
the only requirement is to implement __getitem__

ne use case is to be able to use the same substitution script for
different CRM notification messages and only compute the "heavy"
substitution variables when they are actually needed.

See nexedi/erp5!1047

We run them in coding style test suite already.

Also these test now need business template repository properly
configured in template tool, which is not set in default setup, so
keeping them working would require extra work.

This reverts commit f9391847.

These two paths were only half-committed, for the PDF we don't have the
file content, for the test we don't have the .xml, so in practice this
test never ran.
I tried to run it but it does not pass, uses pause command and some
xpath selector that are now unclear.

PDFJS is also tested in portal_tests/erp5_km_zuite/testCheckPDFPreview

This action is very rarely used, typically once for each section and
then never used again.

Make it only enabled for Manager user, as a way to disable it, but it's
still here and it still works, but it's not useful in normal operations.

also open a new window / tab.

- use global preference to get publication section value
- test updated

/reviewed-on nexedi/erp5!1017

ZODB Components: Resetting Portal Type classes was also clearing Interfaces of erp5.component.* modules.

__implemented__ and __provides__ attributes are cleared on Portal Type reset
to break a circular reference (11e2b506). Resetting of ZODB Components is
done independently of Portal Type classes, so until the next ZODB Component
reset, Interfaces were not implemented anymore.

11e2b506 states that this creates a memory leak but this is not actually true
as Python garbage collector will break such circular reference and collect
this object, as asserted by a newly introduced Unit Test. This is probably
less efficient than explicitly breaking the circular reference and thus relies
on reference counting (rather than the garbage collector) but doing otherwise
would require introspecting ZODB Components module to find classes implementing
Interfaces (erp5.portal_type only contains classes).

This only takes care of ZODB Components modules but maybe breaking circular
references for Portal Type classes is not even needed (if so, this will be done
in a later commit).

ZODB Components: When migrating FS Mixin, set the ZODB Component reference to the class name (like Interfaces).

ZODB Components: Non-core bt5 with 'Document Component' overriding standard ERP5 Document must create its own version_priority.

Otherwise this will clash when standard ERP5 Document will be migrated to ZODB
Components to erp5_base.

Like Document and Interface Components for the same reasons (694c9fee).

Since 264ded5c in ERP5JS we render the form directly after a successful edit, but this was done sometimes too early, namely, the next form was rendered before interaction workflows and this leads to problems like the ones discussed in nexedi/erp5!982 (comment 92893)

/reviewed-on nexedi/erp5!1040