Proposal for the relations-endpoint

Fixes #1432

@pbauer thanks for creating this Pull Request and helping to improve Plone!

TL;DR: Finish pushing changes, pass all other checks, then paste a comment:

@jenkins-plone-org please run jobs

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically.

Happy hacking!

✅ Deploy Preview for plone-restapi ready!

Name	Link
🔨 Latest commit	9191069bcf2a5d88a08493a42efb9f924bda949a
🔍 Latest deploy log	https://app.netlify.com/sites/plone-restapi/deploys/634d1a8f557a4500087697aa
😎 Deploy Preview	https://deploy-preview-1431--plone-restapi.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

GET request: It would be nice to get not only the dictionary of relation tuples by relation, but also the request and some items_total info.

I played with the new module. Apart from

• adding additional info to the GET request: requesting uri and items_total info
• the not solved question, if and how a second endpoint @relations-catalog could be abanndoned (please, what's the use case for a relation affecting the Plone site root?)

I would like to suggest some changes on documentation. Instead of many change suggestions I'll provide a PR.

My 2cents!

I'm still kind of torn on the naming, I still haven't gone through the new duality full-fledged DX root vs portal root. I guess it's my main pain point here. Aside naming, I can understand that for the relations control panel, you need a centralised query point in the "portal root", where you can issue general queries to retrieve bulk and generic relations data, but the fact that we are introducing the ability of doing all the operations in two ways, centralised and in-object... it kind of unease me.

@ksuess since you have experienced and tried out first hand while doing the control panel, what's your take on this?

@plone/volto-team opinions?

It's the decision if Plone site root should be a potential source of a relation element.

If not, then /root/@relations is the endpoint request for global stuff.

That's not really a open decision since the site-root is now dexterity and has a intid it can have relations. The use-case to relate from there to other content also makes sense to me. The only option I see to have only one endpoint and avoid duplication and is to remove the one on the content and handle everything using target, source and relationship parameters on the site-root.

@pbauer, @sneridagh, @tisto, adding 'UID' to metadata_fields in ISerializeToJsonSummary is not necessary. I reverted the commit. Instead the UID is added just for @relations and @relations-catalog endpoint.

https://github.com/plone/plone.restapi/pull/1431/commits/0773403428060ca0a2aced7a0e95f048c1dde7c2

At the Volto team meeting on 2022-05-24 we discussed two options:

1. We could drop the endpoint on content and only have a /@relations endpoint on the portal that works with the source/target/relation parameters as proposed for the @relations-catalog endpoint.
2. We could use /@controlpanels/relations instead of /@relations-catalog on the site-root. This would be similar to the dexterity types endpoint (https://plonerestapi.readthedocs.io/en/latest/controlpanels.html#dexterity-types).

No decision has been made so far.

In that case I would say that we need to control the user persmissions in the endpoint not to allow unauthorized users to get the relation information, while if we have 2 endpoints the zope2.View would handle it, right?

@stevepiercy Could you please take a look at the conflicting file?

@stevepiercy Could you please take a look at the conflicting file?

Done. I merged master into this branch to bring in the reorganization change, then cleaned up relations.md, which could still use a little more filling in, assuming y'all want to use request and response files for the examples.

@pbauer this PR still needs a changelog entry and blackification, but the docs are OK by me to get something published now. We can always fill in the details later, if details are desired.

The latest work on this is in https://github.com/plone/plone.restapi/pull/1602, if I understand correctly.

The latest work on this is in #1602, if I understand correctly.

Yes, I started with a new branch, because the concept changed: No endpoint on context, but one single endpoint /@relations on portal root.