using json in 37b795fb was wrong,
because not all arguments can be converted to json (for example
DateTime instances)

This also enable the format using pprint.pformat for args, instead
of a simple str that was done in ActivityTool_getMessageList.

When spawning an activity, store the current security context's user in
the Message object itself, so the activity security context can be
re-created with the same security during activity execution.
This allows a user to be modified (different groups, global roles, maybe
removed altogether) after they spawned activities and before these activities
could run.
It also means that any temporary custom group or global role granted to
that user (by a privilege elevation mechanism out of the scope of this
change) will still be effective during the activity execution.
This follows the principle that
  foo.activate(...).bar(...)
should be equivalent to its "immediate execution" version
  foo.bar(...)
by ensuring that the security context of the activity is the same as the
one which was applied to the code which spawned that activity,
independently of any intermediate configuration change - hence improving
(deferred and fragmentary) transaction isolation.

This also removes the need to look the user up, then looking up their
assignments (and other documents involved in group computation), etc,
saving the cost of these calls.

Also, remove redundant user_name argument of Message.changeUser method.

The action was removed in 6dce55b0 (dms: drop PDF thumbnail view, 2021-06-01)
but some CSS declarations were not removed.

Also remove some old commented out javascript that was referencing the
old PDF preview

When a validated component is edited, `mixin.component.RecordablePropertyMetaClass`
records the `text_content` property. This recorded property will be cleared afterwards
if no errors are found, but this causes differences in business template XML for each
component the first time they are edited.

This change is about removing the `_recorded_property_dict` when there are no property
recorded, which leads to slightly smaller pickles (and business template XML, because
they are also pickles).

See merge request nexedi/erp5!1605

This makes smaller pickles

More investigations are needed on jio side

jio 3.45.0 fixed the issue

Proxy field rendering was improved by nexedi/erp5@25ad9ece

erp5_core_test already depends on erp5_base, no need to have another
organisation_module module.

This was problematic because uninstalling erp5_core_test removes
the organisation_module with everything inside.

since config['software_list'] is used several times, it must be a real
list object and not a filter object

See merge request nexedi/erp5!1602

This will allow to propagate the CSP configuration on officejs.com

Only ZEXP Export/Import is possible. These modules (namely OFS.XMLExportImport
and Shared.DC.xml.*) were heavily monkey-patched anyway and are only used for
BusinessTemplates.

* ERP5Type/XMLExportImport.py  => ERP5Type/XMLExportImport/__init__.py
* OFS/XMLExportImport.py       => ERP5Type/XMLExportImport/__init__.py
* Shared/DC/xml/{xyap,ppml}.py => ERP5Type/XMLExportImport/{xyap,ppml}.py

See merge request nexedi/erp5!1589

Instead of doing what loading zope.conf does (which is different
across zope versions), use the ZConfig configuration callback.

The old name was Zuite_viewZeleniumTestLauncher which is an violation
to erp5-Guideline.Form.Report.Dialog.Is.Postfixed.With.Dialog

ErrorLog is not allowed prefix, this was flagged by coding style test,
since the script is not used it's better to remove it

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 RoundingModel, all 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