This is an alternetive way to login using Certificates. Probably this format
   will evolve into use caucase;  however this only introduce some most basic features.

   Use Certificate Login for store login definitions

  Please squash me in future.

  If the user wants actitivites, it should create multiples StandardBT5ConfiguratorItems,
  This should accellerate Tests based on ERP5Configurator.

  This should be recoded, but it should speed up bootstrap of a site,
  as get modified objects are not called.

It the user don't have fully permission on the object (already changed state), this set will fail to check if source should be defined.

  The upgrade ordering seems buggy and requires to force reinstall it

This allow during a subscription process, create a user and them create all
documents using that user w/o rely on proxy roles (keeping good ownership
across the documents).

Without this (on slapos master ui) the redirection places value unquoted causing parser to fail later on when resolve {n.me}

  The user can be present from diferent logins, password tool only works with ERP5LoginUserMager
  users.

Returning true allows to add movements to existing one, and this group shall
always separate them.

If 2 lines have the same effective date (catalog has a 1 second precision),
always return the validate and open first.

Commit: 02d06501

Changes applied from history:

http://git.erp5.org/gitweb/erp5.git/history/refs/heads/interaction-drop:/product/ERP5/Document/SubscriptionItem.py?js=1

Original commit from : Lukasz Nowak <luke@nexedi.com>
                       3e45ec35

Conflicts:
	bt5/erp5_crm/bt/revision

When start and end are setup on float/integer field, the max and mic attributes are also setup in the input html element.
So if the user enter a number outside this range, the browser should display an error.

using start and end filed on float, trigger web-browser error. But UI test are looking for multiple fields check by erp5.
2 validators script are added because no argument can be passed to external validator, so :
TALES: python: context.Base_ValidateFloatRange(value, mix=1, max=2)
doesn't work

On Zope2, python scripts do not have __code__, they only have
func_code (and same for __defauls__/func_defaults).
We tried to backport the support of __code__ from Zope4 as a Zope2
patch - it was SlapOS patch 4fa33dfc6 (erp5: py3: `func_{code,defaults}`
was replaced in Python3 by `__{code,defaults}__`., 2022-04-25),
but this patch was incomplete. We tried to backport more, but then
realized that we don't need to use __code__ on ERP5 master yet,
because ERP5 master branch is still supporting Zope2 only.

This patch revert a small part of a17bb910 (py2/py3: Make Products
code compatible with both python2 and python3., 2022-04-13), the part
where we use f.__code__ where f might be a python script. For now,
we'll apply this patch only on the Zope4 branch.

A few places where f.func_code was used and f was a for sure not a
python script but a simple class method or function are kept here, as
__code__ support is missing only on in ZODB scripts.

This is not really a test, but it reuses runUnitTest/runTestSuite
commands, because they are good tools to quickly create ERP5
environment and installing business templates.

To re-build and re-export all* business templates, use this command:

    ./bin/runTestSuite --test_suite=ReExportERP5BusinessTemplateTestSuite

--node_quantity argument can also be used to process multiple
business templates in parallel.

* note that this does not actually handle all business templates, but
only the ones for which coding style test is enabled, because most
business templates for which it is not enabled can not be installed.

This typically produces large diffs that should apply the same
change to many files and ideally, nothing else. We also developed a
simple tool which summarize the diff by detecting the same chunk
present in multiple files, it can be found at
https://lab.nexedi.com/nexedi/erp5/snippets/1171 and also below.

---

from __future__ import print_function
"""report similar hunks in a patch.
"""
__version__ = '0.1'

import argparse
import collections
import codecs
import unidiff # unidiff==0.7.3
import hashlib

parser = argparse.ArgumentParser()
parser.add_argument('patch_file', type=argparse.FileType('r'), default='-', nargs='?')
parser.add_argument('-v', '--verbose', action='count', default=0)
args = parser.parse_args()

patchset = unidiff.PatchSet(codecs.getreader('utf-8')(args.patch_file))

chunks_by_filenames = collections.defaultdict(set)

for patch in patchset:
  for chunk in patch:
    chunk_text = u''.join([unicode(l) for l in chunk])
    chunks_by_filenames[chunk_text].add(patch.path)

for chunk_text, filenames in chunks_by_filenames.items():
  chunk_hash = hashlib.md5(chunk_text.encode('utf-8')).hexdigest()
  print("Chunk %s is present in %s files" % (chunk_hash, len(filenames)))
  if args.verbose:
    print()
    print("\n".join("  " + f for f in sorted(filenames)))
    print()
  if args.verbose > 1:
    print()
    print(chunk_text)
    print()

To prevent rounding errors, we always compare rounded values to the
precision of the accounting currency. There was a place here where we
were using -= without rounding, which caused to detect a difference
between new and current stock and insert a line for 0 in an existing
instance for which some accounting lines were created with too precise
values - but not in a way that was detected by the assertions in
AccountingPeriod_createBalanceTransaction.

Rounding here as well solved the problem with that data.

Supports the case where Products.DCWorkflowGraph is not present.
Even though we are removing Products.DCWorkflowGraph from the
software release, we don't remove this monkey patch yet, because
this monkey patch also fixed a severe security issue. We keep the
patch for the cases where a recent ERP5 runs on an old SlapOS where
the product is still there.

This change just moves the existing code in a try/except ImportError
block

See merge request nexedi/erp5!1615

Rationale:

Converting * to data frame / numpy array efficiently is required in all
wendelin projects, without this functionality wendelin is useless.
Currently all projects allow this functionality in an insecure way.
This commit aims to improve the situation by supporting a secure way of
this functionality.

(See nexedi/wendelin!99 (comment 158474))

Because pandas (in restricted Python) can also be useful in 'pure' ERP5
(without Wendelin) the functionality is added to ERP5 source code.

---

Security:

Security is guaranteed by patching selected read_* functions and
allowing the patched versions. The patch prohibits anything but
string input which directly contains the data (e.g. no urls, file
paths). New unit tests ensure the restrictions of the patches
are actually effective.

---

Notes on implementation decisions:

Instead of offering new ERP5 extension methods (e.g. Base_readJson)
this commit adds patched pandas read functions in restricted Python.
In this way the change of the known API is as minimal as possible.

Instead of globally monkey-patching pandas read_* functions, only the
functions inside restricted python are patched.
In this way the fully-functional, original functions are still available
in Zope products or ERP5 extension code.

Minor changes in the way how pandas is allowed in restricted python
have been applied. Please consult the following discussions in the Merge
request for details:

nexedi/erp5!1615 (comment 159203)
nexedi/erp5!1615 (comment 159341)

See merge request nexedi/erp5!1630

...for  getPortalDataConfigurationTypeList.

See nexedi/erp5!1630 (comment 159889).

Translated property accessor accessor accidentally changed to return
on python2 unicode for translated messages and str for non translated
messages in a17bb910 

To make it worse, CMFCategory's Renderer was swallowing exceptions.

This restores translated accessors behavior and changes Renderer to
let exceptions propagate

See merge request nexedi/erp5!1629

partially revert a17bb910 (py2/py3: Make Products code compatible
with both python2 and python3., 2022-04-13) so that
TranslatedPropertyGetter keeps returning utf-8 encoded str (bytes) on
python2 and returns text only on python3.

This regression caused displaying categories to raise unicode error or
to silently not display the labels for.

This just hides issues.

In commit a17bb910 ("py2/py3:
Make Products code compatible with both python2 and python3"),
2to3 changed `_.has_key(...)` to `... in _` whereas _ is not a dict.

Traceback (innermost last):
 ...
 Module OFS.PropertyManager, line 309, in manage_editProperties
   manage_tabs_message=message)
 Module Shared.DC.Scripts.Bindings, line 322, in __call__
   return self._bindAndExec(args, kw, None)
 Module Shared.DC.Scripts.Bindings, line 359, in _bindAndExec
   return self._exec(bound_data, args, kw)
 Module App.special_dtml, line 185, in _exec
   try: result = render_blocks(self._v_blocks, ns)
 Module DocumentTemplate.DT_In, line 707, in renderwob
   try: append(render(section, md))
 Module DocumentTemplate.DT_Let, line 76, in render
   else: d[name]=expr(md)
 Module DocumentTemplate.DT_Util, line 210, in eval
  - __traceback_info__: _
   return eval(code, d)
 Module <string>, line 1, in <module>

TypeError: argument of type 'TemplateDict' is not iterable

See merge request nexedi/erp5!1628

Delete the content of the cache storage (used by erp5js), unregister the service worker and force the browser to reload.

It is now replaced by erp5_web_renderjs_ui