Ticket #9329 (closed PLIP: wontfix)
Manage actions through-the-plone
Reported by: | igbun | Owned by: | vangheem |
---|---|---|---|
Priority: | minor | Milestone: | 4.1 |
Component: | General | Version: | |
Keywords: | actions, controlpanel | Cc: | plip-advisories@… |
Description
Proposer: Ricardo Alves
Seconder:
Motivation
Currently, the only way to manage actions through-the-web is using the ZMI. There should be a management screen allowing the user to manage actions without leaving the Plone UI.
Assumptions
Plone uses action providers to include lists of configurable links in specific locations of the main template. Actions are divided into categories and mainly provided by the portal_actions tool, which can be configured though-the-web using the ZMI, and via GenericSetup using the 'actions providers' step.
The user should be allowed to add, edit and remove actions from a set of "plone managed" categories, using the Plone interface. On the other hand, It probably doesn't make much sense to allow the user to add new categories. So the managed categories would possibly be:
- document actions
- site actions
- portal tabs
- user
Proposal & Implementation
Add a new configlet to the plone control panel named "Actions". This configlet shows the list of actions for each category allowing to:
- add a new action;
- remove an action;
- edit/change an action;
- reorder existing actions within a category;
The implementation should be made in plone.app.controlpanel, adding a new ControlPanelView similar to the implementation of the "Types" control panel. The initial view should allow to select the action category. The form to edit actions should be a ControlPanelForm, using a schema interface describing the action fields.
Deliverables
A new release of plone.app.controlpanel, including the new confliglet and tests.
Documentation should be updated to describe the new configlet.
Not sure if a new icon will be necessary...
Risks
No risks that I can think of.
Participants
- Ricardo Alves (igbun)
Progress
No implementation available yet.
Change History
comment:2 Changed 7 years ago by hannosch
Once we get closer to Plone 5, many of the things currently done via actions will most certainly move to a different backend technology.
Especially document and site actions are really more part of the theme then they belong to the application space. They will probably become some sort of application tile instead, which offers configuration of its own. So you can go into the "edit my site theme" mode and then edit the "site actions" tile. Imagine the site actions viewlet to be something like a portlet of today, which can be configured on its own.
Many other uses of actions of today don't make any sense to be customizable in a general actions fashion. The cut/copy/paste actions or the various object tabs are part of the application logic and pretty uncommon to customize on their own without changing the things they call.
comment:3 Changed 7 years ago by igbun
I totally agree that it doesn't make any sense to customize object actions or object tabs. That's why I'm proposing to include only these categories: "site actions", "user", "portal tabs", and *maybe* "document actions".
OTOH, I think actions are more part of the site configuration them theming. The theme may even not know which actions will be included, but will assume there are certain categories of actions.
About the future, I have some questions:
- is the infrastructure going to change in a way that there will be no equivalent for the current implementation of categories and actions? I mean, in your example, when editing the "site actions" tile will you be able to add, remove, edit the list of links with the same possibilities (conditions, expressions, icons, etc)?
- has the future implementation (different from CMF actions or not) a direct matching to the current categories and actions? If so, then this control panel will still be useful. It will just need to be updated to match the new implementation.
Anyway, if Plone 5 is not going to be released before late 2010, a year is a lot of time to justify this feature, which I believe will be really useful :)
comment:4 Changed 7 years ago by pupq
"Actions may go away in 5" doesn't seem to be a good reason to not do this; we'll still have people using Plone 4 for years after Plone 5 comes out, and they could benefit from this.
As long as the TTP version of the actions uses the same syntax as the ZMI version, this seems like a low-risk idea.
It also doesn't seem too high-value, either, though--we expect people to go into the ZMI to change templates (portal_skins or portal_view_customizations). Should actions really be handled that differently?
On the other hand, most people in classes have *no idea* that all the buttons/tabs aren't in the templates directly, so exposing these might help people find them. I see people now sometimes editing the templates to add new actions, since they couldn't find the action registry.
comment:5 Changed 7 years ago by erikrose
- Owner igbun deleted
Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)
comment:6 Changed 7 years ago by alecm
- Owner set to igbun
This would be a nice little usability improvement. As Joel says, people will be using releases in the 4.x series for some time, making some nice control panels for existing functionality seems like a pretty obvious improvement. It should be fairly easy to determine if the new UI is worthwhile. This is certainly something that could be a part of later 4.x releases, in the unlikely event that it couldn't be completed in time for 4.0.
comment:8 Changed 7 years ago by rossp
FWT vote: -1
As an aside, It does seem that this could be a better way to meet the requirements that #9279 seeks to address.
That said, I think I agree more strongly with David and Hanno's argument that actions are a performance bottleneck that we'd like to replace than Joel and Alex's argument that the usability improvement is worth it. I think it's there's a TTP interface to actions, it will be a gateway for integrators and users to invest more in the actions infrastructure which will make moving away from it all the more surprising, disruptive and frustrating to them.
comment:9 Changed 7 years ago by MatthewWilkes
The actions tool is a bit esoteric and has weirdnesses. There are action providers that bring things in from all over the place. I don't think having this exposed to the Plone front-end would be useful without renovating the problems in the actions tool at the same time.
FWT Vote: -1
comment:10 follow-up: ↓ 11 Changed 7 years ago by igbun
@MatthewWilkes the idea is to have a set of "plone managed categories". This way we can control which actions can be managed using the control panel (e.g. "site actions" and "portal tabs" are the most common use cases). Not sure about what you mean with weirdnesses and problems renovated by this control panel...
@rossp I just find this argument that "actions may be replaced by something in the future", whenever that may be, a bit strange. If we're going to make decisions based on this assumption, then we should already know how are we going to replace this feature, i.e. the ability to configure links that may be: divided into categories; conditional; dynamic; guarded by permissions; i18n-aware. Will the future implementation be completely incompatible without a possible migration?
comment:11 in reply to: ↑ 10 Changed 7 years ago by rossp
Replying to igbun:
My argument concerned disruption to the integrator and add-on developer communities more than it did merits of any particular implementation as your reply concerns.
My experience has been that there is significant frustration in the wild that results from being told to invest in one technology/API/framework and then being told to abandon that investment in the next release.
Now surely, if we stopped making any changes that would be disruptive to those communities, we'd cease to innovate. Neither does that mean, however, that we can't get value from minimizing interruption when we have a chance to.
In this case, I have good reason to think that there is a need for a replacement (performance, and I've run into many other problems with the CMF actions framework) and there is good reason to think it will happen (hanno, Plone 5 discussions). Since I believe implementing this would encourage more investment, I see it as one of those cases when by declining to add something to core we have good odds of reducing disruption to the integrator and add-on communities without stifling innovation.
This is all, of course, just my opinion anyways. :)
comment:12 Changed 7 years ago by davisagli
FWT vote: +1, despite my criticism above. But please do start some discussion on plone-developers about what we should replace CMF actions with in the long term, so that we can try to make this UI be forwards-compatible.
If this PLIP isn't accepted, I do think this would be an excellent add-on product.
comment:13 Changed 7 years ago by jonstahl
I'm a little disheartened by the sentiment "we might come up with a paradigm shift later, so let's not incrementally improve what we have now." While I strongly appreciate the intent to avoid having integrators deeply invest in something that might require awkward migration later on, I think that we have are seeing our occasional tendency to "deprecate the imperfect by fiat" rather than by producing running, superior code.
comment:14 Changed 7 years ago by alecm
In case it wasn't clear:
FWT vote: +1
comment:15 Changed 7 years ago by calvinhp
FWT Vote: +1 about extending the UI to expose some of these configuration knobs and I don't think they have to be tightly coupled to the current implementation using actions, but general so that the underlying implementation can change, but the knobs still react the same for the user.
comment:16 Changed 7 years ago by hannosch
One thing to keep in mind is that so far there was a deliberate distinction between the Plone control panel and the ZMI. Anything listed in the Plone control panel should be targeted at normal users or site administrators.
The ZMI and some more screens like the ramcache-controlpanel and manage-viewlets where not put into the Plone control panel as these are targeted at a much more technical audience. Developing / customizing the theme itself is a ZMI or file system task so far on purpose.
I feel that exposing actions with their arbitrary Python expressions is not something for the site administrator audience. We already do have a UI in the actions tool and even if that is not looking too good, I don't see how you can actually simplify it in a way that requires less knowledge or no Python coding skills.
Maybe if the PLIP contained some more information on how exactly these things should be shown and what information would be exposed, I might feel more comfortable with the idea. If it would only be about showing/hiding some of the actions for example, that would be something I'd consider to be useful.
Otherwise I feel this is just trying to slowly replace the ZMI with a UI looking Plone-ish for no real benefit if just done for one or two random places, instead of trying to replace the ZMI wholesale.
comment:17 Changed 7 years ago by raphael
I've mixed feelings about this PLIP. One concern is that we would add even more confusion if we need to explain that there are now two different "kinds of actions": those managed TTP versus those managed through ZMI although we are dealing with the same action machinery.
I also don't by the argument of "being nicer". To use actions sensibly you need to know TALES. If you require that you can also handle the ZMI.
I'd turn it around and use the future perspective (moving away from CMF actions) as an argument in favor of this PLIP if we can be confident that whatever will come up can be handled through the same UI - ideally without changing it later even. So if this could be turned into a path moving forward (like managing CMF actions now while supporting "action tiles" or whatever later on) I'd be +1 on this.
comment:18 Changed 7 years ago by igbun
OK, after reading carefully all arguments and chatting with some of the people who commented this PLIP, I believe we should postpone it, even if accepted for Plone 4. As Raphael states, we should be confident that the UI will also fit whatever the future brings for actions. We're pretty far from that right now.
So, I'll happily re-submit this PLIP for Plone 4.1, if it still makes sense. Then we should have more information to base our decisions on, including: a more enlightened perspective of the future of actions; an add-on product providing this feature; we'll all be older and wiser :)
comment:19 Changed 7 years ago by erikrose
- In regard to Hanno's planned Plone 5 UI, I see no problem providing a configlet now and a direct-manipulation UI later. Sounds like a continual path forward to me.
- Editing actions in a common reason to need the ZMI, and I'm all about getting most site admins out of there. Besides, the portal_actions UI is awful. I look forward to seeing what the implementors come up with.
- I disagree that editing portal_actions should be a scary thing confined to the "Zope developers' interface". They're just links half the time. I have plenty of users who edit TAL and wouldn't have any trouble with a few CMF Expressions, though navigating the ZMI (which is organized according to implementation, not anything that makes sense to the user) confuses them.
As long as no new actions API (to remove in 5) is introduced with this implementation (and I don't see any reason why there would be), my FWT vote is +1.
comment:20 Changed 7 years ago by esteele
Approved by FWT vote.
comment:22 Changed 7 years ago by igbun
comment:23 Changed 7 years ago by elvix
comment:24 Changed 7 years ago by esteele
Your PLIP has been reviewed by the Framework team. Feel free to discuss any suggested changes either here in the PLIP ticket or on the mailing lists. Final deadline for this PLIP is set for September 23.
comment:25 Changed 7 years ago by esteele
comment:26 Changed 6 years ago by rossp
FWT vote: -1 for merge
comment:27 Changed 6 years ago by esteele
- Status changed from assigned to closed
- Resolution set to wontfix
Closing this PLIP as it wasn't completed for 4.0. Please feel free to reopen and submit to a 4.x release.
comment:28 Changed 6 years ago by vangheem
- Status changed from closed to reopened
- Resolution wontfix deleted
- Milestone changed from 4.0 to 4.1
I would like to revive this for 4.1 and would be willing to finish up the implementation if the framework team is still interested in it.
comment:29 Changed 6 years ago by vangheem
- Status changed from reopened to new
- Owner changed from igbun to vangheem
comment:30 Changed 6 years ago by esteele
- Status changed from new to closed
- Resolution set to wontfix
This PLIP has been declined for consideration for Plone 4.1.
Framework Team voting on this PLIP was: Alec +0 Craig +1 Elizabeth -1 Laurence -1 Martijn -1 Matthew -1 Rob +1 Ross --
The Framework Team felt that it wasn't worthwhile to expose as a Plone control panel unless the concepts could be made easier to understand (as opposed to just duplicating the ZMI forms). They have suggested this be created as an add on to help solidify its functionality and usability.
-1. I appreciate the concept, but am hesitant to actually support this PLIP because I know that Hanno would like to replace our use of CMF actions with something else entirely in the long term (because actions are a performance bottleneck, apparently), and so I'm not sure we should add additional action-related code. This also seems like something that could easily be implemented as an add-on product rather than being included with core.