Implement IJSONSummarySerializerMetadata

[ericof]

This allows addons to extend the metadata returned by the Summary serializer

To always return image_field metadata on summaries, in an addon you will implement a new file called summary,py with content

from plone.restapi.interfaces import IJSONSummarySerializerMetadata
from zope.interface import implementer


@implementer(IJSONSummarySerializerMetadata)
class JSONSummarySerializerMetadata:
    def default_metadata_fields(self):
        return {
            "image_field",
        }

and register it with:

<utility factory=".summary.JSONSummarySerializerMetadata" name="plone.volto.summary_serializer_metadata" />

[mister-roboto]

@ericof thanks for creating this Pull Request and help improve Plone!

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass.

Whenever you feel that the pull request is ready to be tested, either start all jenkins jobs pull requests by yourself, or simply add a comment in this pull request stating:

@jenkins-plone-org please run jobs

With this simple comment all the jobs will be started automatically.

Happy hacking!

[tiberiuichim]

A Plone addon for an image gallery (as an example), wouldn't know which fields it should return in default_metadata_fields. We either need named utilities (so that we can use getUtilitiesFor() ) with one such utility per field, or use a subscriber system (and let them write into a list).

If we go named utility route, we can also do some plone.directive integration, so that we can mark a field as "included in json summary".

[ericof]

@jenkins-plone-org please run jobs

[ericof]

A Plone addon for an image gallery (as an example), wouldn't know which fields it should return in default_metadata_fields. We either need named utilities (so that we can use getUtilitiesFor() ) with one such utility per field, or use a subscriber system (and let them write into a list).

To be honest I was mostly concerned with the use case of a policy package controlling everything (instead of having each package register its own metadata).

@sneridagh, @tisto, opinions?

[tiberiuichim]

@erico sorry, I misread your comments and didn't look at your implementation. Good to go, from my part

[ericof]

@tiberiuichim, @sneridagh We need to worry about the errors on Jenkins. It looks like @ale-rt merged his "Plone site root on the catalog", and this will start breaking tests here

[tisto]

LGTM. I'd love to have a short section in the docs and maybe a short how-to about how to override this. Maybe @ThomasKindermann @steffenri @iFlameing @jackahl can work on this with a few pointers.

[ericof]

I will merge this, then open a new PR for the documentation
Also, we need to decide how to deal with the Plone 6 master tests failing

[ale-rt]

I saw that coming...
This was the reason for #1259 but after a long discussion with Timo it was decided to close it.
I still think it was a bad idea not to merge it.

See also https://github.com/plone/plone.restapi/pull/1251/files on how to adapt tests for Plone 6.