Thanks to Vincent Pelletier for his help on this bug fix.

See merge request nexedi/erp5!1782

also set hide_rows_on_no_search_criterion to force displaying the list
even without search, this is a report, we we always want to see records.

See merge request nexedi/erp5!1781

This is done on the process running test (by
ERP5TypeTestCaseRequestConnection) and when using timerserver loop (by
TimerServer which calls publish_module), but this was never set in
processing_node.

Before 3b874e49 (ERP5Type/tests: review requests in tests, 2023-04-19)
getRequest could find a request anyway, because the test pached
getRequest to find a request from the app, but after this change
executing activities in an instance running with runUnitTest without
test specified failed with:

    Module importlib, line 37, in import_module
      __import__(name)
    Module Products.ERP5Type.dynamic.component_package, line 412, in load_module
      return self.__load_module(fullname)
    Module Products.ERP5Type.dynamic.component_package, line 379, in __load_module
      erp5.component.ref_manager.add_module(module)
    Module Products.ERP5Type.dynamic.dynamic_module, line 75, in add_module
      self.add_request(get_request())
    Module Products.ERP5Type.dynamic.dynamic_module, line 53, in add_request
      self.setdefault(last_sync, (WeakSet(), set()))[0].add(request_obj)
    Module _weakrefset, line 86, in add
      self.data.add(ref(item, self._remove))
  TypeError: cannot create weak reference to 'NoneType' object

( maybe we remove processing_node and use only timerserver, these two
methods are more or less equivalent for simple cases and timerserver is
closer to what a "real" zope does )

unittest executes the cleanups after `tearDown`, after the ZODB
connection is closed, so accessing database objects cause errors.

According to python unittest documentation, it is safe to call
`doCleanups` ourselves when we need the cleanup to be executed earlier,
this is a typical case where we want the cleanup to be called before
closing the database connections.

ID is not something we like to show to users, modification date and
validation state can be better - this assumes that most of the
relation are made to nodes, which typically have a validation state
and not a simulation state.

The general idea of this patch is that now that we are using
zope.globalrequest, we no longer need to patch get_request, we can
simply call zope.globalrequest.setRequest with the request from the
test and restore the "real" request afterwards.

To achieve this, we reuse Testing.ZopeTestCase.connections.registry,
which already has the logic of cleaning up resources in the right place
and use a "Request" resource that calls setRequest(test_request) and
setRequest(real_request) when closed, so that:
 - test runs with an independant request
 - this test request is closed at the end
 - the real request is restored at the end

This also fixes a bug with self.publish when runnning
ERP5TypeLiveTestCase from portal_components of a running instance,
after a call to self.publish the current request was lost.

The testing for this revealed that ERP5TypeLiveTestCase.publish way
of dealing with zope.security interaction was not always correct: when
running a live test inside runUnitTest (like we do here in
testDynamicClassGeneration), there is no security interaction. This
was reviewed to use the high level API instead of changing directly the
internal storage.

This can be useful when making a report on movements and when we list
properties of the movements that depend on the side but are not
directly exposed on MovementHistoryListBrain. One use case was
`Movement_getSpecificReference`, which shows `source_reference` when
the brain is for the source and `destination_reference` otherwise.

With this new approach, instead of guessing we record the "is_source"
information at indexing time, when we know this for sure.

This also simplifies `MovementHistoryListBrain.date` and
`MovementHistoryListBrain.mirror_date` which no longer need to guess
the side and fix a problem that because this guessing was done using
`movement.getSourceUid()` - which cause security errors when users can
not access the source of the movement.

When editing a state permission mapping the roles were not sorted,
because WorkflowState_getPermissionMatrixContext uses a set. Sort
before setting the attribute, to prevent useless diffs in ZODB history
and business template.

default activate() behavior is to not queue the activity if another
activity with the same path/method_id already exist. We don't want this
here.

We don't even use the new updateLocalRolesOnSecurityGroups instead,
because roles are supposed to be applied by an interaction workflow.

to make it easier to find related documents

This compatibibility script was guessing the side, but this is exposed
in brain

See merge request nexedi/erp5!1768

The way addToDate was working with dates was not good, and creating
confusion when removing 1 month from the last days of a 31-day month, as
the previous day had less days than the current month:

date = DateTime(2023, 5, 31)
print date
print addToDate(date, month=-1)
> 2023/05/31 00:00:00 GMT+2
> 2023/05/01 00:00:00 GMT+2

This was even more confusing in March, with february having only 28
days:

date = DateTime(2023, 3, 31)
print date
print addToDate(date, month=-1)
> 2023/03/31 00:00:00 GMT+2
> 2023/03/03 00:00:00 GMT+2

The new behavior is to, when removing a month, if the new day of the new
month is more than the number of days in month to default to the last
day of the month. For exemple, removing one month from 31/05 becomes
30/04, and from there it will add/remove the days as necessary.

The real issue being that removing a month is ambiguous and can mean
a different thing for different people.

For reference, the reference implementation of timedelta in python
doesn't support adding months:

https://docs.python.org/3/library/datetime.html#datetime.timedelta

I hope my solution will make the more sense in ERP5's context.

For zope, a request to /erp5/person_module/person1 or
/erp5/organisation_module/person_module/person1 can both be resolved
and are (more or less) equivalent. This change brings support for
similar request paths for Open API Connectors.

( until we finalize the complete integration of SlapOS parameter
editor )

We set the module as a source to acquire roles. Also, we need to store request and response in HTTP Exchange.

This merge request is to fix nexedi/erp5@ec4a3f9d

See merge request nexedi/erp5!1771

We set the module as a source to acquire roles. Also, we need to store request and response in HTTP Exchange.

This is a simple framework to implement services in ERP5 based on an
OpenAPI document.

A new type "Open API Type" (similar to "Base Type") is introduced,
this is responsible for the definition of operations and types.
The Open API document is set as text content of the Open API Type
and can be edited from the Open API Type.

For each service, a new portal type will be created. The portal type
use OpenAPIService as class and this is responsible for serving
requests. The process of serving requests is:
 - find the matching operation from the request method and request
   path
 - extracting request parameters and request body using the parameter
   definitions from the Open API Document
 - validate parameters and request body according to the schema from
   the Open API document
 - finding the method, this is done by using _getTypeBasedMethod with
   the operationId
 - calling the method and formatting the result or handling error.
   The default handling of errors is to reply with rfc7807 json
   responses, but it can be customized by defining an
   `handleException` type based method.

Typically, the services will be created in portal_web_services. From
there, there is also a view using a new SwaggerUI gadget to try out
the API.

What's not supported:
 - OpenAPI document in YAML format is only partially supported and
   have some limitations over JSON:
    - On python2 the order of operations is lost, the lookup of
      operations is not made in the order of the operations from the
      document. Also the operations are not in order in the SwaggerUI
      gadget.
    - The text editor does not provide rich editing of YAML
 - "partial" parameters in path elements ( /users/{user_id} is
   supported, but /documents/report.{format} is not )
 - XML (decoding of request bodies and parsing of responses) is not
   supported.

We use to show ID in case reference is missing, but since many years
this is no longer the case.

See merge request nexedi/erp5!1766

See merge request nexedi/erp5!1767

The fix from 7597c300 (accounting_l10n_fr: don't export
lines with 0 quantity in FEC, 2023-03-31) was not 100% correct,
lines with a quantity but with an asset price of 0 were still
exported.

We used a wrong condition that was causing lines with a debit
and asset credit (ie. different sides) to be output wrongly
with debit and credit.

in 5ae0508d (accounting_l10n_fr: Workaround encoding bugs
in Test Compta Demat, 2023-03-31) we replaced a few characters
that were known to be problematic, but while trying on some
other production data, we found new problematic characters.
This shown that this approach was too "optimistic" and that we
the safest way to have a file that is compatible with Test
Compta Demat is to use only ascii characters, this use
unicodedata to try to retain the original characters (so that
"Jérôme" becomes "Jerome") and also special case € to replace
it by "EUR"

    If two open orders are validated on the same transaction, archivePrevious script will get the an already archived as catalog will be outdated.

we pass the schema already, but for now this only supports basic
syntax highlighting

programmatically calling script.setParameterSignature('') was
setting _params to None and making it causing errors when calling
the script

This change modifies the FEC export to conform to the test software from
https://www.economie.gouv.fr/dgfip/outil-test-des-fichiers-des-ecritures-comptables-fec 
/ https://github.com/DGFiP/Test-Compta-Demat.

A new `test_compta_demat_compatibility` to enable compatibility mode was introduced.
This will be True when rendering the report from the dialog, i.e., using `AccountingTransactionModule_viewFrenchAccountingTransactionFile` and False when
using `AccountingTransactionModule_viewFrenchAccountingTransactionFileActive` directly
so the behavior of reusing FEC export for accounting interfaces should be the same as before.


See merge request nexedi/erp5!1764