Show Toolbar permission is necessary, not sufficient to show toolbar contents

[seanupton]

Documenting a quirk of Plone (Classic UI) toolbar visibility here:

1. In Plone 5.0+, the @@plone view's showToolbar method checks user for any of three permissions (toolbar contents shown if any of these, otherwise additional logic below applies):
   a. Modify portal content
   b. Add portal content
   c. Review portal content
2. In ~2017, a Show Toolbar permisssion was added to plone.app.layout presumably for purposes of hiding toolbar.
   • but it is critical to note that this is not itself sufficient to show the toolbar's contents — you can end up with an empty toolbar, despite having this permission.
3. As it ships now (6.1), @@plone view logic will not show toolbar if you do not have non-View actions in the top-level of the toolbar (that is, any action not named view in tabSet1 of tabSet2), even if you have perfectly useful and relevant content menus to display in the toolbar.
   • is it reasonable to assume that if a non-empty menu is visible to user, the toolbar at large should be displayed?
4. My use case is a user:
   a. with permission to view content in a particular state
   b. without permission to Modify portal content in that state
   c. but a permission to see and execute a retract transition from that state from the workflow menu
   d. and for which the only top-level action is view, but ideally should get a content menu if that menu is applicable.
5. My plan for my integration case is to subclass and override @@plone view to wrap OOTB method with logic to handle this case (non-empty menu).
   • although it would be nice if there was some consensus for what this looks like in the general case; it would probably require both True return value for plone.app.contentmenu.menu.WorkflowSubMenuItem.available and a non-empty return value for plone.app.contentmenu.menu.WorkflowSubMenuItem._transitions to consider non-empty. For all other menus shipped in plone.app.contentmenu the available() method is a sufficient check on visibility for determination of whole-toolbar visibility, in my opinion.

[yurj (Yuri)]

I agree. I don't see myself use cases to hide the toolbar when you're logged in, but maybe there are valid cases. I'm sure that having the toolbar is ok. Another option is to have a simple button on the template that lets you "retract" the object. Generally speaking, the view should have a way to force showing or hiding the toolbar, so applications can use it to get around corner cases or undocumented cases.

[petschki (Peter Mathis)]

We recently had the need to hide the toolbar for special members. So we

1. Did this with the mentioned permission.

2. When the toolbar is hidden, the viewlet plone.membertools shows up in plone.portalheader when this member is logged in, so we put some user specific actions to portal_actions/user which showed up in this dropdown ...

I quickly set up a member without toolbar permission on the classic demo page and it looks like this ... maybe you could place your workflow actions there?

[MrTango (Maik Derstappen)]

that's exactly the use case for what it was introduced by @agitator back then, if i remember correctly.