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.

Allows triggering the regular not-found error handling path from within
the rendering of a form.

Form.__call__ replaces page template call, so it is also responsible
to set the content type in response.

With Page Templates, ZopePageTemplate._exec (called by
Shared.DC.Scripts.Bindings.__call__ and _bindAndExec) sets the
response content type and calls pt_render. Form.__call__ also calls
pt_render, so to behave like page template, it should also sets the
response content type.

In erp5_xhtml_style, we don't notice this, because global_definitions
contains a setHeader call to set content type to html.

Done through various 2to3 fixers (zope.fixers, modernize, future) and manual
changes. This is a single commit so that we have a clearer picture of how code
converted with my2to3 should look like.

Except straightforward @implementer decorator 2to3 fixer, only product/ folder
was considered as the goal was to be able to create an ERP5Site.

* Use @implementer decorator introduced in zope.interface 3.6.0 (2010):

  The implements syntax used under Python 2.X does not work under 3.X, since it
  depends on how metaclasses are implemented and this has changed. Instead it
  now supports a decorator syntax (also under Python 2.X).

  Applied thanks to 2to3 `zope.fixers` package.

* Use `six.moves` rather than `future` install_aliases() feature because the
  latter use unicode_literals and "wraps" module aliases so that unicode() are
  returned for text rather than str() (Python2 standard library). This notably
  breaks BusinessTemplate code which uses urllib quote() for filesystem paths...

* No more unbound methods in python3 so use six.get_unbound_function().

* dict.(iteritems,iterkeys,itervalues)() => six.\1(dict) thanks to `dict_six`
  2to3 fixer from `modernize`:
  $ python-modernize -w -f dict_six product/

* Manually make sure that dict.{items,values,keys}() returns a real list when it
  is latter modified rather than a dict_{items,values,keys} (ensure_list()). By
  default, 2to3 blindly does list(dict.{items,values,keys}()) which is not
  acceptable from performances point of view. With my2to3, this will be possible
  to handle such case automatically.

* Replace cStringIO.StringIO() by six.moves.cStringIO() (a module alias for
  cStringIO.StringIO() on py2 and io.StringIO() on py3).

* Use six.text_type which maps to unicode() on py2 and str() on py3. This also
  makes a clearer difference between text and binary strings.

* Replace map()/filter() with lambda function by list comprehension (this has
  the benefit to avoid casting to list for py3 as it returns iterators).

When rendering a proxy field, 3 different fields can come in play:
1. the field to be rendered
3. the template field (i.e. not a proxy field) that knows how to render
2. possibly an intermediate proxy field that contains the value to render

What's difficult when rendering a proxy field is to take the above 3 fields
into account and this commit does it by creating a temporary field:
1. 'field' variable in TALES
2. the value
3. the code

Before this commit, 1 could be wrong.

  Those 2 exceptions are from SlapOS Master codebase, and for now we cannot remove it.

  Rather them complexify the ignore lists, we are hardcoding the values for minimase the ignore list
  to the least entries as possible.

TALESValue always had a strange behavior of setting the request as `cell` when
rendering a matrixbox in the case where there was no cell at the given
coordinates, but this code was not used, becase the request was not passed in
kw. When in 777c5e6c ([ERP5Form] Pass request to fields, 2017-12-29) we
changed to always pass the request, this changed the behavior. After this
change when there was no matrix cell, in the TALES context the variable `cell`
became request.

This restore the original behavior (cell being the cell or None), by changing
the questionable code that was not used before.

For now this only checks that every entries in .tales are also in .values
so that .has_value works as expected. This also supports repairing the
structures with fixit argument.

We could check more, because there are other problems with proxy fields
internal structures:
 - sometimes some keys are in .values / .tales but not in .delegated_list
   this seem to happen after changing the target to a field of a different
   type, with different keys.
 - .delegated_list are not always sorted

The internal data structures are made of two dicts: .values for values and
.tales for TALES. Formulator expect that these two dicts have keys for all
properties, because of the implementation of Field.has_value which checks
for the presence of the key in .values

When making a field with only TALES, this method was setting the value only
in .tales but the same key needs to be present also in .values, otherwise
get_value would return False for this key.

For same reasons as 5b1c03c8 (sort delegated lists to make proxy field
representations more stable., 2009-05-18)

Checking some conventions for form, dialog and reports based on
https://www.erp5.com/documentation/developer/guideline/programming/
and https://www.erp5.com/documentation/developer/guideline/module/

For now we implement only a few checks, we will extend later.

This has been banned since the introduction of Portal Type class. When creating
a new ERP5Form via addERP5Form/ZMI, its MRO:
  * Before:
    <class 'Products.ERP5Form.Form.ERP5Form'>
    <class 'Products.ERP5Type.Base.Base'>
    ...
    <type 'ExtensionClass.Base'>
  * Now:
    <class 'erp5.portal_type.ERP5 Form'>,
    <class 'Products.ERP5Form.Form.ERP5Form'>,
    <class 'Products.ERP5Type.Base.Base'>,
    ...
    <class 'erp5.accessor_holder.property_sheet.SimpleItem'>
    <class 'erp5.accessor_holder.property_sheet.Folder'>
    <class 'erp5.accessor_holder.property_sheet.Base'>
    <class 'erp5.accessor_holder.property_sheet.CategoryCore'>
    <class 'erp5.accessor_holder.BaseAccessorHolder'>
    <class 'Products.ERP5Type.dynamic.portal_type_class.GetAcquireLocalRolesMixIn'>
    <type 'ExtensionClass.Base'>

Thus it was missing many accessors and was working only by chance (or at least
unless these accessors were not called until the object was automatically migrated
by the next call to __setstate__). Namely, as `providesI*` accessors are now in
BaseAccessorHolder rather than Base due to ZODB Components, this breaks reindexing
(`AttributeError: providesIPredicate`).

Also, remove hardcoded _getAcquireLocalRoles() now that it is not used as a regular
class anymore. Set this on the portal type object instead.

content_type is a bit special, because CMF's PortalFolderBase also have
a content_type method, so this was confusing ERP5Type dynamic properties
system. When the property was never set, the default value was the
method acquired from PortalFolderBase.

Fixes this by defining conten_type class attribute where needed.

This also fixes an old expected failure test, it's now possible to use
edit(content_type=something) in document without content type property
set. It works now, but thanks to what seems to be outdated code in
_valid_property_id from product/ERP5Type/patches/PropertyManager.py,
because we have stopped setting all properties to None in Base years
ago. For now, this works, but because of an outdated condition in
_valid_property_id. We may revisit later in the future.

Simpler, and reduces the exposure of exc_info (which can be tricky to use
in other contexts).

Put auto-generated _getAcquireLocalRoles at the end of mro, removing it
from Base.
Also, document why it is treated specially here.
Also, add _getAcquireLocalRoles methods on a few leaf classes whose
instances fake being portal types, without actually being proper document
instances. At least, the ones which are detected in unit tests. The
proper fix would likely rather be to make them proper document classes,
but this carries data migration concerns which go beyond the scope of
this regression fix (_getAcquireLocalRoles was not possible to override
anymore).

/reviewed-on nexedi/erp5!652

Similar to commit e1d57590

On sites with more than one Zope, this code was causing the cookie to be
bumped each time a form is rendered, causing unneeded cache misses and
slight ZODB bloat (estimated around 100B per form view).

So, Relation Fields in ListBox were ignored during validation as the input
value is compared with the current (default), thus the field could not be
cleared as the value from the actual object was not retrieved at all.

Before, the field value cache was only invalidated on the node where a field
has been modified, so similarly to reset of ZODB Components, implement
synchronization on all nodes through ZODB Cache Cookie.

'REQUEST' exists, then variable 'cell' becomes request value and
breaks matrixbox. I must check what must be done when cell is None.
when cell is explicitly specified as None, is it ok to override,
I do not have answer yet.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@45397 20353a03-c40f-0410-a6d1-a30d3c3de9de

for the compatibility to relation string field. See
MultiRelationStringField.get_value.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@45154 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@43408 20353a03-c40f-0410-a6d1-a30d3c3de9de