Products.cmfplone: PLIP: Portal actions control panel

[ebrehault]

Proposer : Eric Bréhault

Seconder : T. Kim Nguyen

Abstract

Allow to manage portal actions from a Plone site setup control panel.

Motivation

Everytime I show how to manage a Plone site to a customer, everthing looks nice and great, but when he/she asks if we can also manage the footer links, I am a little ashame to show the portal_actions ZMI interface.

Assumptions

N/A

Proposal & Implementation

I propose to implement a regular Plone control panel (based on z3c.form) that will reproduce the very same features as the portal_actions ZMI interface.
This PLIP is just about UI, it will not impact the action object model or implementation, it will not impact the way they are accessed in other packages, and it will not impact the way they are declared in a GS profile.

Deliverables

New version of Products.CMFPlone.

Risks

None

Participants

[gforcada]

:+1:

[mauritsvanrees]

+1

[hvelarde]

+1

[vangheem]

+1

[frisi]

you might want to have a look at https://pypi.python.org/pypi/quintagroup.plonetabs/

[tkimnguyen]

Could I second this, given that I created #1253? :) or does it have to be a FWT member?

[ebrehault]

Sure you can :)

Everybody can second a PLIP (just like anybody can propose a PLIP). In the PLIP process, the FWT team has 2 major roles:

• at start, accepting or rejecting the PLIP,
• during the implementation, to provide support, and to review the code.

[prakharjoshi]

@ebrehault @tkimnguyen Can this be done under GSOC for this summer ? This seems like a good feature to implement.

[ebrehault]

@prakharjoshi sorry but I have already implemented it during the weekend :) (see #1342).
But don't be disappointed because it was probably too small for a GSOC anyway.

[prakharjoshi]

@ebrehault Oh its a good thing you finished it. :+1:

[jensens]

Note to self: In order to apply this the following outcomes need to be merged:

• [x] Implementation for PLIP 1342 portal actions #1385
• [x] new vocabularies for portal actions plone/plone.app.vocabularies#26
• [x] theme additions plone/plonetheme.barceloneta#87

merge after 5.0.3 release for 5.1 release

[gforcada]

@jensens should we use the milestones for keeping these things more or less organized?

[jensens]

+1 - i can auto apply the missing ones tomorrow

[tkimnguyen]

@ebrehault you are too efficient :)

[esteele]

@ebrehault Can you sync up with the @plone/documentation-team to make sure this feature is covered in the docs?

[ebrehault]

@esteele oh right, I forgot to update the doc: http://docs.plone.org/develop/plone/functionality/actions.html?highlight=actions#creating-actions-through-the-web is still mentionning ZMI.
I make a PR on the doc ASAP.

[esteele]

Two comments from some integrators after I gave a short demo:

• They'd like drag/drop reordering since we've got that elsewhere now
• They'd prefer the ability to toggle visibility instead of deleting in the actions listings.

[ebrehault]

@esteele yes it makes sense.
I have created #1613 and #1615. The hide/show thing was easy, the PR is done (waiting for tests to finish).
Drag&drop implies to create a Mockup pattern, it will take longer.

[gforcada]

@ebrehault if I get it right only https://github.com/plone/Products.CMFPlone/issues/1615 is missing to be able to mark this PLIP as finished and merged (on 5.1)?

[ebrehault]

@gforcada the PLIP did not mention that reordering should be done using drag&drop, so in my opinion, we can already mark this PLIP as finished and merged.

[jensens]

this one is finished, merged and can be closed, right? So I do.

[tisto]

Hey @ebrehault, we just had a discussion about an actions endpoint for plone.restapi at the Plone-React sprint in Bonn and we were wondering if it wouldn't be better to just completely move the portal actions to the registry instead of creating an actions endpoint.

Is that something you thought about? Is there a good reason in your opinion not to move to the registry?

If we move to the registry, we have the chance to get rid of the actions entirely at some point. cc @robgietema @sneridagh

[jensens]

IIRC, the discussion was: control-panel first (keep the scope of the PLIP narrow), then we don't need the ZMI any more and a migration to a registry based solution is easier (another PLIP).
IMO, the next logical step is to move the configuration to the registry.

[tisto]

@jensens ok, makes sense. I guess we will go ahead and implement the actions as registry entries for plone.restapi (since it does not make much sense to implement an actions endpoint that will be deprecated at some point). If anybody is up for the task to push this in Plone core they can rely on our work...

[tkimnguyen]

I'm curious why move or get rid of portal_actions, as it is a well understood mechanism that has been around for eons, and we finally got this nice control panel. What does it improve to move these to the registry?

[tkimnguyen]

@jensens you wrote "Unification of configuration, also in the profile. Also we get rid of the tool at all. Portal actions are very dumb, no own place needed."

Thinking about this some more, maybe this is too philosophical and/or something to ask in the forum, I agree that portal actions are very simple, why not store them as their own Dexterity content type? Configuration vs. content. Plone is great for managing content; why do we feel the need to create yet another mechanism to store configuration?

[jensens]

.oO( seems I got it on the wrong thread... Never answer Github messages on mobile...)

I think the configuration registry is the place where configuration has to be stored. We should not abuse content here unless we have a way to cleanly divide between configuration types and content types. Sometimes this could be handy.

[tisto]

@tkimnguyen just to be clear, we do not want to get rid of portal-actions. We just want to store them in the right place so we can get rid of all the CMF cruft at some point...