To write a pid file so that logrotate can send us signals. This is
still needed for neo storage for now.

See nexedi/slapos!1395

Loading ZConfig will initialize storage and generally might do things
that will cause messages to be emitted.
One actual problem is with neo storage, which configure root logger
when it's not already configured [1], this was causing all logged
messages to be logged in the console when using neo storage.

1: https://lab.nexedi.com/nexedi/neoppod/blob/fd87e153/neo/lib/logger.py#L63-64

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

  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.

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

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

See merge request nexedi/erp5!1763

XLTE(*) follows the same top-level packaging structure like
wendelin.core does.

Registration is done via new `register_xpkg` function instead of just
loop so that pkgname argument is properly captured in created lambda and
does not change after going to next iteration.

(*) https://lab.nexedi.com/kirr/xlte

/reviewed-by @jerome
/reviewed-on nexedi/erp5!1762

In 5796a17a (core_test: Add test to make sure that wendelin.core
basically works) I added wendelin_transform to pylint so that the
checker could recognize wendelin.core's special wendelin top-level
module/package and handle ok

	from wendelin.bigarray.array_zodb import ZBigArray

this works, but e.g. for plain

	import wendelin			or
	from wendelin import bigarray

pylint currenly fails with

	AssertionError: explicit relative import, but no context_file?

To better see what is going on let's conside the following test program

	"""ZZZ"""

	from wendelin.bigarray.array_zodb import ZBigArray
	from wendelin import bigarray

	def main():
	    """main"""
	    _ = ZBigArray

and run pylint on it. Here is what it gives:

          wendelin_transform Module(wendelin)
          -> Module()

    visit_from From()
      basename: wendelin.bigarray.array_zodb
      names:    [('ZBigArray', None)]
      modnode:  Module(test)
        get_imported_module From() wendelin.bigarray.array_zodb
      importedmodnode: Module(wendelin.bigarray.array_zodb)
    ('_add_imported_module', <From() l.3 [test] at 0x7ff214b4cb90>, 'wendelin.bigarray.array_zodb.ZBigArray')
          wendelin_transform Module(wendelin)
          -> Module()

    visit_from From()
      basename: wendelin
      names:    [('bigarray', None)]
      modnode:  Module(test)
        get_imported_module From() wendelin
          wendelin_transform Module(wendelin)
          -> Module()
      importedmodnode: Module()
    ************* Module test
    W:  4, 0: Relative import 'wendelin', should be '' (relative-import)
    ('_add_imported_module', <From() l.4 [test] at 0x7ff214b4cf50>, '.bigarray')
    Traceback (most recent call last):
      File "./x.py", line 22, in <module>
        Run(['test.py', '--reports=n'], exit=False)
      File "/home/kirr/src/tools/py/pylint/pylint/lint.py", line 1332, in __init__
        linter.check(args)
      File "/home/kirr/src/tools/py/pylint/pylint/lint.py", line 747, in check
        self._do_check(files_or_modules)
      File "/home/kirr/src/tools/py/pylint/pylint/lint.py", line 869, in _do_check
        self.check_astroid_module(ast_node, walker, rawcheckers, tokencheckers)
      File "/home/kirr/src/tools/py/pylint/pylint/lint.py", line 946, in check_astroid_module
        walker.walk(ast_node)
      File "/home/kirr/src/tools/py/pylint/pylint/utils.py", line 874, in walk
        self.walk(child)
      File "/home/kirr/src/tools/py/pylint/pylint/utils.py", line 871, in walk
        cb(astroid)
      File "/home/kirr/src/tools/py/pylint/pylint/checkers/imports.py", line 288, in visit_from
        self._add_imported_module(node, '%s.%s' % (importedmodnode.name, name))
      File "/home/kirr/src/tools/py/pylint/pylint/checkers/imports.py", line 328, in _add_imported_module
        importedmodname = get_module_part(importedmodname)
      File "/home/kirr/src/tools/py/astroid/astroid/modutils.py", line 359, in get_module_part
        'explicit relative import, but no context_file?'
    AssertionError: explicit relative import, but no context_file?

we see that the line

	from wendelin.bigarray.array_zodb import ZBigArray

corresponds to

	('_add_imported_module', <From() l.3 [test] at 0x7ff214b4cb90>, 'wendelin.bigarray.array_zodb.ZBigArray')

and the line

	from wendelin import bigarray

corresponds to

	('_add_imported_module', <From() l.4 [test] at 0x7ff214b4cf50>, '.bigarray')

notice that in the latter case there is no 'wendelin' prefix and the
import goes as just '.bigarray' instead of 'wendelin.bigarray' which
leads to further crash in get_module_part.

-> Fix it by initializing wendelin module yielded by wendelin_transform
with .name set. Not sure why it is working longer imports without that.

Without the fix added test breaks as

    .../instance/slappart5/bin$ ./runUnitTest -v -v -v  testDynamicClassGeneration.TestZodbModuleComponent
    ...
    Running Unit tests of <class 'testDynamicClassGeneration.TestZodbModuleComponent'>
    ok
    testImportVersionedComponentOnly (testDynamicClassGeneration.TestZodbModuleComponent) ... ok
    testInvalidId (testDynamicClassGeneration.TestZodbModuleComponent) ... ok
    testInvalidSourceCode (testDynamicClassGeneration.TestZodbModuleComponent) ... ok
    testModuleSecurityInfo (testDynamicClassGeneration.TestZodbModuleComponent) ... ok
    testPylint (testDynamicClassGeneration.TestZodbModuleComponent) ... FAIL
    testPylintAstroidModuleGeneratedOnce (testDynamicClassGeneration.TestZodbModuleComponent) ... ok
    testPylintNamedtupleUnicodeLiteralsRegression (testDynamicClassGeneration.TestZodbModuleComponent) ... ok
    testReferenceWithReservedKeywords (testDynamicClassGeneration.TestZodbModuleComponent) ... ok
    testValidateInvalidateDelete (testDynamicClassGeneration.TestZodbModuleComponent) ... ok
    testVersionPriority (testDynamicClassGeneration.TestZodbModuleComponent) ... ok
    testVersionWithReservedKeywords (testDynamicClassGeneration.TestZodbModuleComponent) ... ok
    testWorkflowErrorMessage (testDynamicClassGeneration.TestZodbModuleComponent)
    Check that validation error messages are stored in workflow ... ok

    ======================================================================
    FAIL: testPylint (testDynamicClassGeneration.TestZodbModuleComponent)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File ".../parts/erp5/Products/ERP5Type/tests/testDynamicClassGeneration.py", line 2347, in testPylint
        component.checkSourceCode()
      File ".../parts/erp5/product/ERP5Type/mixin/component.py", line 329, in checkSourceCode
        return checkPythonSourceCode(self.getTextContent(), self.getPortalType())
      File ".../parts/erp5/product/ERP5Type/Utils.py", line 540, in checkPythonSourceCode
        Run(args, reporter=TextReporter(output_file), exit=False)
      File ".../develop-eggs/pylint-1.4.4+slapospatched002-py2.7.egg/pylint/lint.py", line 1332, in __init__
        linter.check(args)
      File ".../develop-eggs/pylint-1.4.4+slapospatched002-py2.7.egg/pylint/lint.py", line 747, in check
        self._do_check(files_or_modules)
      File ".../develop-eggs/pylint-1.4.4+slapospatched002-py2.7.egg/pylint/lint.py", line 869, in _do_check
        self.check_astroid_module(ast_node, walker, rawcheckers, tokencheckers)
      File ".../develop-eggs/pylint-1.4.4+slapospatched002-py2.7.egg/pylint/lint.py", line 946, in check_astroid_module
        walker.walk(ast_node)
      File ".../develop-eggs/pylint-1.4.4+slapospatched002-py2.7.egg/pylint/utils.py", line 874, in walk
        self.walk(child)
      File ".../develop-eggs/pylint-1.4.4+slapospatched002-py2.7.egg/pylint/utils.py", line 871, in walk
        cb(astroid)
      File ".../develop-eggs/pylint-1.4.4+slapospatched002-py2.7.egg/pylint/checkers/imports.py", line 253, in visit_import
        self._add_imported_module(node, importedmodnode.name)
      File ".../develop-eggs/pylint-1.4.4+slapospatched002-py2.7.egg/pylint/checkers/imports.py", line 319, in _add_imported_module
        importedmodname = get_module_part(importedmodname)
      File ".../develop-eggs/astroid-1.3.8+slapospatched001-py2.7.egg/astroid/modutils.py", line 359, in get_module_part
        'explicit relative import, but no context_file?'
    AssertionError: explicit relative import, but no context_file?

    ----------------------------------------------------------------------
    Ran 13 tests in 137.609s

    FAILED (failures=1)

/helped-and-reviewed-by @jerome
/reviewed-on nexedi/erp5!1762

See merge request nexedi/erp5!1759

See merge request !1538

  On the automatic upgrade some bt5 (erp5_core) can be upgraded
  before erp5_property_sheets. Since, it isnt a problem if this happens
  if no Mixin configuration is present, it is better directly check the
  existence of the property on the bt5.

  In general we expect that erp5_property_sheets is upgraded before any
  other bt5 with TypeMixin definition.

       Use the proper way to include Mixin into a portal type

   Use the proper way to include Mixin into a portal type

  This value isnt exported anymore

 Handle type_mixin like property_sheets and use Business Template properly

  Allow the developer associate a Mixin on Business template level
without require to overwrite the portal type itself

  Include mixins can be done in the same way, allowed content types or
property sheets are set.

After updating Products.CMFCore we had issues on sites where URLTool was registered as ISiteRoot.

In the case of ERP5, we don't really need portal_url.getPortalObject(), this changes to use ERP5Site.getPortalObject(), while at the same time doing something so that portal_url.getPortalObject() also works.

See https://github.com/zopefoundation/Products.CMFCore/pull/126 for more details

See merge request !1758

this is a "magic" local variable used to add more debugging information
in zope traceback, it's not supposed to be used directly so it was a
false positive in our case.

This extends the default value of --dummy-variable-rgx that was defined
to _$|dummy in pylint 1.4.4 (
https://github.com/PyCQA/pylint/blob/pylint-1.4.4/pylint/checkers/variables.py#L296
)

This can happen when request is used as a cache storage, especially
after eab00f14 (deferred_style: Properly keep request parameters,
2021-03-10)

  that it was created.

  squash me

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).

See merge request nexedi/erp5!1756

Products.CMFCore's version 2.7.0 of portal_url.getPortalObject
returns the portal in an incomplete acquisition context, which
causes issues when the site is registered as ISiteRoot utility
(the typical error being AttributeError REQUEST)

ERP5Site.getPortalObject works just fine and is used in many
places, this commit replaces all occurences of
portal_url.getPortalObject by getPortalObject.

and adjust the test for better python3 compatibility

we don't use these

This TALES is complex, especially if we need to support python3 as well

Some old ERP5 site were registered as ISiteRoot and this cause
issues with Products.CMFCore update 2.2.10 -> 2.7

this interaction adjust membership criterions when variation
categories is changed, but we don't really need security
restriction in the interaction, because security is already
checked when setting variation categories.

This factorize code and fix a problem that when the variation
category was a Category from the same variation base category,
we had the base category twice ( something like
group/group/nexedi )