Some portal types such as Business Template were not tested by testXHTML
because this tests started by modules and recursively tests views based
on allowed content types. Because of this approach, types that are not
created in a module but in a tool were never tested.

With unittest, the only way to dynamically add test methods to a class
is to generate a test class in test_suite function. At this stage, the
ERP5 site is not created yet, so the test had to introspects business
templates XML.

This now uses a slightly different approach, instead of finding modules
and chain of allowed content types from business template XML, we only
use business template to introspect the list of actions.
The lookup of the appropriate containers is no longer done before setup
by static analysis of business templates XML, but later once the site is
created, by dynamic analysis of the modules and allowed content types on
the running ERP5 site during the test method.
If we don't find a chain of portal types, we create the test document in
portal_trash, a tool without filter of content types.

This way, we can test all views of all portal types. This revealed a few
problems:
 - we need developer role to create components in portal_components, for
this we add developer role to the current user.
 - Delivery Cell portal type looks not used, there are no container
accepting it. We don't test delivery cell views for this reason.
 - VCS view on business template needs preferences and working copy
setup. We just mark this test as expected failure for now.
 - Solver Decision has a form conditionnaly displayed when there's a
relation to a solver, but this test does not evaluate action conditions
and does not allow to call a script (that would made it possible to
modify the document so that the condition is true). For now we also
mark this as expected failure.

Delivery Cell is not really used these days and cannot be created in
testXHTML, so drop these useless views.

For reference, the same views still exists on all other movements portal
types, so we don't "loose anything important" by removing the views
here.

The corresponding form, BudgetTransfer_viewBudgetTransferLine does not
exist, so mark view as not visible for now so that it's not tested.

This redirects to another site, so it is not really a view action.

This also confuses testXHTML.

Maybe what's missing is an interaction to update cache internals with
updateCache when a cache is added, but that's enough to make TestXHTML
pass now.

DublinCore was missing, so getCompactTitle was causing AttributeError
_baseGetTranslatedTitle

When listboxs has an editable field, but the field is non editable, it
produces a markup like:
  <a href="link to the line"><EditableField/></a>
This is fine for most fields, but some editable fields are rendered as
an <input> even if they are not editable - this is the case for
CheckBoxField.
To prevent rendering <a><input></a> which is not valid HTML, configure
the enabled field as non-editable on alarm list view, with this change
listbox treats the field as an editable field and just render the field
as <EditableField/> without the <a>.
To keep the same visual appearance of having a disabled checkbox field,
make this field disabled with extra.

The action was in erp5_core, but the form in erp5_forge. Move the action
in erp5_forge.

The listbox list method was raising error because it was using catalog
with unsupported installation_state=. Change to use contentValues
instead.

This listbox had "Listbox" as a title, use "History" instead, which
makes a little more sense in this context.

MissingCategoryDocumentConstraint was incorrectly using
unrestrictedTraverse, unlike category API which uses its own
resolveCategory method with better semantics.

Because of this, some problems were not reported:
 - categories using paths that resolve by acquisition, but does not
exists as such (like in the test)
 - categories using path with dynamic objects, like a website language.

/reviewed-on nexedi/erp5!986

checkRevision now returns a callable, return a do-nothing lambda when
the expected revision is already checked out

/reviewed-on nexedi/erp5!990

With this merge request we add the feature of allow a gadget to call submitDialog  *and* the prototype of scan documents from mobile with new ERP5 UI

/reviewed-on nexedi/erp5!932

For now, this is chrome only

erp5_document_scanner_ui_test: Add tests to Document Scanner gadget

- tests updated

- test extended

If automatic GC happens just after the testnode repository is updated,
the repository in the SR may lose objects and fail to update.

See commit 9634a7d8.

Pylint warnings are now causing test failures.

/reviewed-on nexedi/erp5!987

revision(s) a Test Result has already been completed.
Thus we need to properly handle this use case otherwise simply failing makes "client
side" - i.e. testnode keep trying forever in its _retryRPC calls which
indefinitely blocks further tests executions.

A new test suite to perform static check on business templates using  `CodingStyleTestCase`.

This runs a coding style test for each business template, after installing the business template and its dependencies listed in business template metadata.

---

In order to start with a test suite with no failure, business templates that does not pass this test today (because they don't install or because pylint issues still needs to be reviewed) are skipped with an ad-hoc  `bt/skip_coding_style_test` in the business template. Note that this file is not created by business template system as it is a temporary measure, business templates must pass pylint and other checks from `CodingStyleTestCase`.

---

I took the approach of creating one independent test per business template, instead of the approach of creating a site with all business templates like we did in testNamingConventions or testHTML. This appears as another "Coding Style" test, like Performance or Scalability tests.

The idea behind this was that if we extend our business template checks ( for example when we translate the [ERP5 Module Creation Guidelines](https://www.erp5.com/documentation/developer/guideline/module) to some scripts we can run on a business template ), we can check that each business template contain what it should contain and not just that the global result is OK.



/reviewed-on nexedi/erp5!629

PortalTransforms: safe_html: Changes in b255c894 were not actually applied so merge FS module and portal_transforms/safe_html.

These titles duplicate listbox configuration, preventing any change from
reaching users (...who customised their listbox).
Also fixes cases where column title was stored in selection after
translation, which breaks some reports.

Avoid double-calls when one is enough.
Avoid unused locals.
Avoid repeating conditions.
Inline single-use expressions.

Bootstrap is actually the automatic migration of tools. It happened to me
several times that I mistakenly start an old instance on a too new version of
products and this instance is migrated automatically.

By leaving a note in transaction it's easier to find out which
transaction performed the automatic migration to revert to the state
before using technique such as
https://blog.gocept.com/2019/06/14/undo-transactions-by-truncating-zodb-data-fs/
for FileStorage.

with this change, a command such as;

    python -m ZODB.scripts.fstail -n 20 ./instance/slappart6/srv/zodb/root.fs

show something like:

    2019-11-12 02:46:42.106313: hash=44fecb9a63411fbf305cea82f4c699c478000d61
    user=' None' description='/timer_service/process_timer\nSite migrated' length=462938 offset=881877846 (+70)

for the transaction which did the migration, so it's easy to repair.

/reviewed-on nexedi/erp5!975

* erp5_dms: ERP5OOo/ConversionServer-related Transforms.
* erp5_web: Web Page-related Transform.
* erp5_base: Everything else.

Also, ZODB Components Transforms modules were 'Document Component', whereas
it should be 'Module Component' (introduced recently) considering that they
have no Portal Type.