@actions does not include the action URLs

[zopyx]

I wonder why @actions does not include the URLs of actions? When I need to render actions then I need their URLs. Otherwise the @actions endpoint has no value. Or?

https://plonerestapi.readthedocs.io/en/latest/actions.html 2

[tisto]

Just for the record my comment on PR #1076 (maybe it is better to continue the discussion here):

@libargutxi thank you for your contribution! This issue might be more complex than it looks at first sight because REST API design principles need to be taken into account.

Plone REST API uses the concept of resources that are linked via the "@id" attribute, this is the idea of a hypermedia API with linked resources. We currently do not have a similar concept for "actions". There are concepts in the JSON-LD standard but they are very academic and we never implemented them.

If we just expose the Plone Classic URLs, like in this PR, we only serve the Plone Classic use case and ignore Volto and other REST API consumers. The question is: how is Volto or another consumer suppose to handle this URL field in a generic way. If we start using consumer-specific fields, like this URL field, we risk ending up with an overly complex API and duplicate fields (e.g. how should we call the Volto URL actions field, how the Vue actions field, etc.). I think you get the point.

I don't have the answers to the questions that I raise. I just would like to point out the underlying complexity here and that there is no easy and straight-forward solution IMHO.

[erral]

correct my if I am wrong but from my limited Volto experience I see that Volto already handles REST API generated URLs, for instance when showing the breadcrumb, here: https://github.com/plone/volto/blob/master/src/reducers/breadcrumbs/breadcrumbs.js#L40

In this case Volto should handle that too (we are preparing a PR also for the actions reducer on Volto to handle these changes in @actions endpoint).

The point is that if we are exposing the actions, we need to somehow expose the URL of the action, otherwise the endpoint is useless in our point of view.

[sneridagh]

@erral @ionlizarazu my 5cents, @actions is used in Volto like this in the toolbar: https://github.com/plone/volto/blob/master/src/components/manage/Toolbar/Toolbar.jsx#L279

then we infer them from the action, using Volto's own URLs. That allows also the frontends not to be tied to old naming like "contact_info", etc.

We could have set the Volto URLs in the @actions endpoint, then all the other frontends that want to use this would have been out, so we decided not to bind that to any (including classic Plone).

@erral the breadcrumbs reducer is "normalising" the backend (of content resources, not CMSUI) URL to the Volto ones.

[erral]

I see... the point is that in Volto you are not effectively using the URL of the action, just the id or name. The same goes for the toolbar actions.

Then I see no harm on exposing the URL in the action, right? Anyway Volto is not using it. But if someone wants to use those action registration (for instance to expose some other links) could benefit from that.

[sneridagh]

Then we would "marry" the endpoint to one consumer (in this case Plone classic UI) which is what IMHO is wrong... We need to draw the line at some point to maintain the loose coupling of the REST API.

Another option would be that the integration packages (which we still do not have one for Volto) in the Python site, modifies the actions URLs to match the consumer ones, but again, Plone classic UI shouldn't be the default in any case...

[erral]

Plone Classic UI never consumes the REST API but uses the action urls to provide links.

What Andreas asked here and we have provide the PR is to expose that URL in the REST API. Then I think it's up to the frontend to decide to use them or not, like for instance Volto has done.

[sneridagh]

Maybe we are no talking about the same... but the action URL (as it is in Plone right now) eg: https://github.com/plone/plone.restapi/pull/1076/files#diff-4687f8d7daf6e93d8126e241143a0a10e27fae17bdf5e8b43f1b96bbeacd1a6cR25

        {
          "icon": "", 
          "id": "folderContents", 
          "title": "Contents"
          "title": "Contents", 
          "url": "http://localhost:55001/plone/folder_contents"
        }, 

is not a Plone Classic URL? I think it is. In Volto that action points to a different "route" contents, and in other frontend, it might be just another name/URL.

As I said, sorry if I might be missing something.

[sneridagh]

So by adding it, it will be useful only to Plone Classic, if Plone Classic never ever use p.restapi in its own JS.

[erral]

Yes, we are in the same car :) And I do agree with you, but Plone Classic doesn't use the REST API to get the action url, it queries directly the action provider with its methods.

What we want here is to expose that URL in the REST API. Perhaps Volto will not use them when using the folder_contents / contents route, but Volto could benefit from other links entered in the actions.

Imagine that we want to provide to the end user a list of editable links and we achieve that using the actions functionality already available in Plone. For instance, we want to let the user to freely change the site_actions to enter the URLs they want. If those URLs were provided by the REST API, we could get them in Volto and render directly the link.

What I want to say is that although not used in Volto, exposing action URLs is basic if we want to be able to use that URLs without modification in Volto. I don't want to change Volto's routes to be like the ones coming from the actions in edit or contents, but at least to have available the URL in the REST API's @actions endpoint.

[tisto]

@erral maybe you could elaborate your actual use case. That might help us to understand what you are up to.

I guess we could add a "plone_classic_action_url" field. In any case, the field would need to make it obvious that it does not expose an action in an API sense but rather just solves a single (legacy) use-case.

[tiberiuichim]

The question is: Should plone.restapi expose any stuff that's specific to a particular frontend? The view names are specific to Plone Classic. Perhaps it's not Volto that needs the integration package, it is classic plone if the intention is to use plone.restapi there.

[sneridagh]

@erral I think now I got it :) sorry for the noise. So you are thinking in the "site actions" use case (or any other "manual" user action that you could set as an action then use it throught the site). What happens is that we kind of "forgot" that use case because we hardly never used it in the last years. Do you heavily rely on them? Which are the use cases?

For that use case I think it's legit to have it, however it's true that can lead to confusion for the newbies (and not that newbies). If we really wanted to use it, we would need at some point that the integration package overwrite those actions to avoid them (and make that Plone Classic does not set them by default). On the other hand, we could happily ignore them if present (or only use them when they make sense).

Also, there is the drawback that we don't have a proper actions control panel in Volto (yet).

[nileshgulia1]

@erral I think now I got it :) sorry for the noise. So you are thinking in the "site actions" use case (or any other "manual" user action that you could set as an action then use it throught the site). What happens is that we kind of "forgot" that use case because we hardly never used it in the last years. Do you heavily rely on them? Which are the use cases?

One use case of mine is, I'm trying to get those footer links( CMS login, sitemap, contact ) in https://demo-www.eea.europa.eu/en configurable through controlpanels, which clearly we don't have in Volto.

Now, as per https://github.com/plone/plone.restapi/pull/1076 atleast we now have the URL so that we can consume them in the frontend. I don't know how well it's gonna integrate with other frontends, perhaps we need to find a way to override them through a custom footer.jsx component in projects.