We were installing erp5_upgrader with its test dependencies, so it was
installing erp5_full_text_mroonga_catalog. We were also installing
erp5_full_text_myisam_catalog, so we ended up with two full text
business template installed (and the order of this installation was not
deterministic).
This was problematic, because we were installing all the test dependencies
of erp5_upgrader, but we don't really need them here and one goal of
CodingStyleTest is to install only the dependencies of tested business
templates, as a way to verify that dependencies are correctly specified.

This new approach hooks at another level, to install a full text business
template only if the tested business template has a dependency to the
virutal "erp5_full_text_catalog" bt, but no dependency to a concrete bt
(which happens for example in erp5_base) and to install erp5_upgrader
without its test dependencies.

As a result, we also run without erp5_base unless it's an explicit
dependency.

This also reverts commit ab44309f (
full_text_myisam_catalog: skip coding style test) that is no longer
needed with this new approach.

Some other documents from erp5_core import it, this can not be in
erp5_base

These forms use proxy fields from erp5_base, they can not be in
erp5_core.

In case of snapshot test failure, we generated a form in a data:test/html
link. This was working on chrome at the time, but it no longer work these
days, probably because we switched to Same-Site cookie for authentication.
Anyway, this also had the problem that it's not so convenient to use
when updating the reference from the actual screenshot took from the
test running on test node.

These change this to generate a simple download link, and the workflow to
update reference snapshot becomes to click this link to get the new image,
upload it to development zope instance and re-export the business template.

This business template conflicts with full_text_mroonga_catalog, because
it overrides same paths. Because this bt is generally not recommended
and might even be removed, it's better not to complicate coding style test
infrastructure to support this pattern.

follow up of 8a335cca (component: fix error_message saved in every line of history, 2022-02-18)

re-exporting a business template that was just installed should not be
different.

By having a test reporting diffs in export, we can detect changes in ERP5 or
dependencies which would cause the business template format to become different.
The primary reason for doing this was to make sure that on the way to Zope4 we
don't have changes in exported data, especially lossly changes that would not
be detected in test suite, but this is also good because it helps detecting
changes that cause a difference in output - then if we introduce a change that
cause different business template export, we also have to make a change to
re-export everything to new format, which helps keeping the git history cleaner
because there's one big commit with all the changes instead of having many small
commits. This is also good because it detects mistakes when modifying business
templates files directly with a text editor.

The test can be configured to ignore some paths, using fnmatch pattern (which
unlike business patterns do not support ** for recursive match). This is also
helpful when using this test case to check customer configuration business
templates, where we may want to ignore some PathTemplateItem for conveniance.

This also include fix for almost all current cases where re-exporting produce
a diff, except a few cases that the reason for the diff was not understood, they
were added to the ignore list instead.


See merge request nexedi/erp5!1575

This way, clicking on the label is enough to select the radio button,
or tick the checkbox, no need to click on the small button.
This is also probably better for accessibility.

CSS is adjusted a bit, so that the style for "general" field labels
do not apply to this new label.

The status message no longer use system-msg class, use simpler
"assertTextPresent" that should be enough.

Simplify the waiting for static pages, clickAndWait is enough.

Always recalculate the full matrixbox content if one change is found.

Add mutex to prevent raise condition between render and getContent.

See romain/erp5@ed0c1297

With the new workflow implementation, error_message variable is required, because
we intentionally clone previous workflow history entries when passing transition,
as this leads to smaller pickle size

See merge request nexedi/erp5!1560

Use the html_viewer gadget

fix internal API mis-use and other small fixes

See merge request nexedi/erp5!1583

This was creating different message for each number of tasks

This uses an internal API that has changed in 0aeea3c4 (Validation
message translation, 2021-01-06)

With this, user can see stop_date from events

With TALES in default, we prevent acquisition from the start date. When default is None, the field will try to display now on the stop date.

The goal is, if stop_date is None, we don't display anything in this field.

stop date is very useful to Phone Call and Visit. For example, if you want to calculate the time spent in one phone call, you can handle it using start and stop date.

But, Event_view does not display stop_date. So, we display stop_date if hasDuration is True.

No need to introduce one more random number here,
anyway the tag that is passed to this script contains one, so use that

Base_report needs to get also the cleanup_tag
to make sure it is launched before active process is deleted

When rendering a proxy field, 3 different fields can come in play:
1. the field to be rendered
3. the template field (i.e. not a proxy field) that knows how to render
2. possibly an intermediate proxy field that contains the value to render

What's difficult when rendering a proxy field is to take the above 3 fields
into account and this commit does it by creating a temporary field:
1. 'field' variable in TALES
2. the value
3. the code

Before this commit, 1 could be wrong.

This was deprectated because we don't have get*ById for other modules
and tools, we just use OFS API. This should also be slightly faster
because one less method call (and one less call to warning)

exiting the context manager restores the original DateTime behavior

This tests the test framework, because this code is tricky.

I'm not sure if this is used, but not being valid python code cause
problems with code analysis tools

Maybe this made sense long time ago, but nowadays we are using
equivalence testers which tolerate date differences with more flexibility.

createDateTimeFromMillis was also problematic as it uses internal
private attributes of DateTime which is a pylint error with more recent
DateTime