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.

we don't use these

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

and adjust the test for better python3 compatibility

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

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 nexedi/erp5!1757

In nexedi/erp5@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] nexedi/wendelin@f8678468 (comment 181134)

/reviewed-on nexedi/erp5!1757

This reduces dependency on DCWorkflow and cleanup StateChangeInfo monkey patch.

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

Test setup monkey-patched some function which we removed when merging
Zope4 support. This function was used in translationContext, it was
working fine in the tests, because the function was here thanks to the
monkey-patch, but it failed with ImportError when used for real.

This fixes the import to use the real getRequest and drop the patch to
prevent similar problems.

According to https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000027804775/
ValidDate is the date when the transaction was validated ( "16. La date
de validation de l'écriture comptable"), this implementation was simply
returning the modification date, which was not always correct, for
example after causality state was recaculated.

This keeps the `getModificationDate` fallback for cases where FEC is
used with some non validated transactions, in order to keep compatibility

   On the implementation 0 dont set stop date on the Assignment

  If preferences sets a negative duration, don't set stop/start dates on
assignments.

See merge request nexedi/erp5!1754

This fixes some regressions introduced by !1545 when searching the catalog for non ascii text

See merge request !1752

Using unicode with a catalog key or related key got broken in the merge
of zope4 support, but using unicode on a translated key (such as
translated_portal_type or translated_validation_state_title) was not
working before.

it supports text, but unless they have non-ASCI characters, so it's
better to always pass bytes.

In original Products.ZSQLMethods, this is text, we want to keep the
same semantics and encode only at a lower level.

MySQLdb's string_literal is a method from the C API and the name is not
natural for python programmers, because it manipulates bytes. It
supports str, unless they have non ASCII characters, so it's better to
always pass bytes.

On python2, this change repairs a regression visible when searching
catalog with translated related keys. This regression was introduced in
the merge of zope4 support, more specifically with 610972af (py3:
Update Shared.DC.ZRDB.{sqltest,sqlvar} monkey patches., 2022-04-16),
because with the new version of the patches this method gets passed
unicode strings, which is fine, unless they contain non ASCII characters.

This reverts commit 149fdd1d.

This did not support the case of updating old emails for which
url_string was set, it was setting coordinate_text and causing
emails to have two properties ( url_string to the old value
and coordinate_text to the new value ).

See discussion on nexedi/erp5@149fdd1d (comment 180744)

- make the editor bigger
- use monospace font for params

This can happen with cross origin document, when using open on another
domain. In that case selenium crashes and the test never finishes, this
allows selenium to finish and report the error.

With 12f110d4 (testTableStructureMigration: update test after
mariadb 10.3.38, 2023-02-22) we changed the test to support mariadb >=
10.3.38 but it broke the test under 10.3.35.

This makes the test support both 10.3.35 and 10.3.38.