Hello Eric!
We were on Plone 5.1b2 before and after upgrading to 5.1b3 we have noticed two problems:
- The upgrade in the Plone configuration fails because the upgrade step
Update social media fieldsgives an error:
Traceback (innermost last):
Module ZPublisher.Publish, line 138, in publish
Module ZPublisher.mapply, line 77, in mapply
Module ZPublisher.Publish, line 48, in call_object
Module Products.GenericSetup.tool, line 1053, in manage_doUpgrades
Module Products.GenericSetup.upgrade, line 166, in doStep
Module plone.app.upgrade.v51.betas, line 130, in update_social_media_fields
Module plone.registry.recordsproxy, line 60, in setattr
Module plone.registry.registry, line 51, in setitem
Module plone.registry.record, line 82, in _set_value
Module zope.schema._bootstrapfields, line 183, in validate
Module zope.schema._bootstrapfields, line 310, in _validate
Module zope.schema._bootstrapfields, line 210, in _validate
WrongType: ('', <type 'unicode'>, 'value')
Doing the upgrade step Run to51beta3 upgrade profile. ... in ZMI works though.
- We feel extremely uncomfortable with the changes of
searchResultsinCatalogTool.py.
In our setup we have a Plone site at root.
In that Plone site are some Folders on the next level that are private by design.
In that private folders live several lineage subsites that are public and accessible through the web.
This setup has been working fine until now, but now in all portal queries the 'path' key is checked
and we have lots of errors because our first level folders are private.
We would be happy, if the old condition
if not show_inactive
and not _checkPermission(AccessInactivePortalContent, self)
could be kept and the new condition
could be used with a flag in the portal query like the show_inactive flag.
Something like
portal_catalog(path={"query": path, "depth": 1},use_new_strict_mode=True)
would fit our needs.