Now that we fail immediately in case of failure, the deadline can be
safely increased, because it only protects against kind of infinite loops.

Increasing the delay should fix RuntimeError: tic is looping forever
errors with only messages in status -1, that we sometimes saw on testnodes.

Now that tic retries until the deadline is reached or all messages has
failed, it can lead to situations where developer have to wait until the
deadline, when a message failed but other messages (typically scheduled
to run after the failed message) were still running.

By stopping as soon as one message is failed, in this scenario the
developer does not need to wait until the deadline.

1. don't manipulate data base to avoid resend to web service in case of data base conflict
2. use existing property
3. change alarm frequency

In our use, waitress is embedded in Zope and not as a proxy, so it has no
legitimacy emitting Via headers.
While this process often is the origin server, Server response header is
optional and should be left to the lower layers to control, and not
auto-generated by waitress.

See merge request nexedi/erp5!1500

1. display employee number
2. add preview
3. add parameter to send to maileva

maileva

See merge request nexedi/erp5!1544

erp5_api_style: Use default module for object creation

erp5_api_style: jIOStyle fix error handling for post

erp5_api_style: Start improving error feedback

erp5_api_style: Add error record module and portal type

erp5_api_style: Fix error output as jIO Style

erp5_api_style: Introduce jIO Web Section

erp5_api_style: catch value Error when error text is not a json

erp5_api_style: Add generic way to handle errors

erp5_api_style: Fix Web Section Portal Type for api style

erp5_api_style: Fix jIO Api Style

* use self.REQUEST instead of parameter in jIO Web Section
* Use List error in allDocs

erp5_api_style: API error return http error code 400

erp5_api_style: Display actions title in jio web section configuration listbox

erp5_api_style: allDocs return indented result

erp5_api_style: Add response schema to jIO Style. Object creation return 201 http code

erp5_api_style: Post set status to 201 only if status is not yet defined

erp5_api_style: action list is now sorted by float index

erp5_api_style: all docs return error dict like post

erp5_api_style: error can return error name and error link

erp5_api_style: improve error handling in jIO Style

* Give name to errors
* Error Name is stored in error record title

erp5_api_style: Add views for error records

erp5_api_style: add script to provide JSON API Hyperschema

erp5_api_style: fixup not found document return 404 error

erp5_api_style: api is in charge of JSON decoding and provide utf 8 data

erp5_json_form: Improve error feedback

erp5_json_form: Add missing property sheet JSON Form

erp5_json_form: Add response Schema to JSON Form

erp5_json_form: Add Init Script on JSON Form

* Useful to set content type to "application/json"

erp5_json_form: Cleanup JSON Form document

* Add basic property sheets
* Add init script to set Constraint and Type
* Validator can return the list of errors
* Provide field library

When EmptyCriterionValid property is true, this method is expected to
return a query which does not match any document. This only happens when
query_list is empty, but because of category membership checking,
query_list is never empty: it at least contains two ComplexQueries which
themselves may contain an empty query list, and which match all documents.
Calling getCategoryParameterDict with an empty list is dubious, but
changing its behaviour in ZSQLCatalog may affect more than just predicates,
so change the behaviour in Predicate class directly by checking whether
there is any category being matched to begin with.

Pygolang installs import hooks for pytest and ipython, to add
exception-chaining support into them(*) _iff_ (if and only if) those
modules are actually used. This works via Importing[1] which
pre-installs artificial modules into sys.modules that catch
__getattribute__ and try to import corresponding module for real on
first access. Usually everything is fine.

But with pylint/astroid, if the checker code happens to run with those
LazyModules installed, and the checked code has `import sys` somewhere,
astroid eventually delves into processing sys, then sys.modules and
wants to represent that sys.modules dict as dict of constant. Then, when
e.g. sys.modules['_pytest'] is processed, corresponding module object is
checked for .__class__, which raises ImportError if pytest is not
actually available:

    ( https://erp5js.nexedi.net/#/test_result_module/20220127-129289AE2/33 )
    ...
    File ".../eggs/astroid-1.3.8-py2.7.egg/astroid/node_classes.py", line 553, in __init__
        for k, v in items.items()]
      File ".../eggs/astroid-1.3.8-py2.7.egg/astroid/node_classes.py", line 962, in const_factory
        return CONST_CLS[value.__class__](value)
      File ".../eggs/Importing-1.10-py2.7.egg/peak/util/imports.py", line 254, in __getattribute__
        _loadModule(self)
      File ".../eggs/Importing-1.10-py2.7.egg/peak/util/imports.py", line 222, in _loadModule
        reload(module)
    ImportError: No module named _pytest

-> Fix it by detecting those lazy modules and not letting them go through
normal const_factory not to crash.

/cc @jerome, @arnau
/reviewed-by @rafael
/reviewed-on nexedi/erp5!1546 and nexedi/slapos!1117

[1] https://pypi.org/project/Importing/

(*) see:
    https://lab.nexedi.com/nexedi/pygolang/blob/pygolang-0.1-0-g7b72d41/golang/_patch/__init__.py
    https://lab.nexedi.com/nexedi/pygolang/blob/pygolang-0.1-0-g7b72d41/golang/_patch/pytest_py2.py#L48-51
    https://lab.nexedi.com/nexedi/pygolang/blob/pygolang-0.1-0-g7b72d41/golang/_patch/ipython_py2.py#L45-48

See merge request nexedi/erp5!1517

erp5_base: add constraint and action to make sure Employee Number is unique instead of manually setting

We make it possible to define function the same way it's currently
possible to define accounts. The idea is similar: to be able to use this
information in accounting generation rules.

The typical accounting generation configuration using this will use the
function defined on the supply line if any is defined and with a fallback
to the function defined on business process' trade model path.

For now we don't introduce such configuration by default, but this may
become part of  the configuration generated by configurator some day.

The view of accounting transactions have dynamic columns so that all the
information that matters the most is displayed directly on the "main"
view. This extends the columns to add a column for all the items attached
to accounting movements.

Without these accessors, we have to use constructs like:

    resource.edit(
        default_purchase_supply_line_destination_account='account_module/123'
    )

with the accessors, we can use:

    resource.edit(
        default_purchase_supply_line_destination_account_value=account,
    )

The former is a bit error prone, because typos in the property name
silently create a local propery and typos in the relative URL make a
"broken" relation.