See merge request nexedi/erp5!1759

See merge request nexedi/erp5!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 nexedi/erp5!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 )

We have been using scripts returning categories but it was
missing in the relation field.

otherwise it is acquired from BudgetLine, which is bad because:
- the value of catalog.has_cell_content will be wrong
- hasCellContent is slow and this was called for all cells in a budget line

/reviewed-on !1757

In 79fa584e we moved
some security definition from wendelin to erp5, but we didn't add any
tests anywhere. Recent project based tests revealed that this
migration actually failed [1]. We should therefore add a test for
this.

[1] wendelin@f8678468 (comment 181134)

/reviewed-on !1757

This reduces dependency on DCWorkflow and cleanup StateChangeInfo monkey patch.

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.

See merge request nexedi/erp5!1537

And the Product was removed in recent ERP5 SR.

This patch seems not needed

This is in SyncMLUtils

Now this is defined from new workflows, we no longer need the
DCWorkflow version

This was only useful during the transition to ERP5 Workflow, now
that workflows are migrated, Category API (setDestination) is more
natural, so there's no reason to keep this patch

Conflicts:
	bt5/erp5_crm/bt/revision