What if any effect ought SELECT_PORTLET_TYPE permission to have on MANAGE permission over portlets of types that a user doesn't have SELECT_PORTLET_TYPE permission on?
Needs considered, documented, and clarified. Probably lack of SELECT_PORTLET_TYPE ought to veto the permission a user might otherwise enjoy to MANAGE a portlet. Adopters will be confused by this permission, might has well have the confusion fail closed rather than failing open, with lack of SELECT_PORTLET_TYPE having the probably intended effect of, well, preventing users from changing publications with that portlet type.
As it stands, each of these permission categories – SELECT_PORTLET_TYPE and the MANAGE* series – are intimately tied to a single screen in the Portlet Manager. The first (potentially) narrows your choices in choosing a CPD as you publish a new portlet; the second (potentially) narrows your choices in portlet lifecycle transition (i.e. defined/approved/published/expired). Currently you don't need any form of either permission to access the Portlet Manager or click the "New Portlet" button... those functions are controlled by the SUBSCRIBE permission on the Portlet Manager itself. (Though you will be remarkably unsuccessful doing anything with the Portlet Manager if you don't have some form of MANAGE* permission, and moreover you won't be able to publish a new portlet without SELECT_PORTLET_TYPE on at least one type.)
So these 2 permissions control your options when you reach a certain point in a wizard. I get the concern expressed in this ticket, but I wonder if it is misplaced as far as SELECT_PORTLET_TYPE. This new permission is a new-portlet-only option; once set, it doesn't change (as it stands). So there's no issue of someone somehow making a choice on edit s/he couldn't make on create – the screen for that is not available. The concern is for someone "taking over" a portlet of a type s/he couldn't define from scratch, and thereby using it to do something s/he is not intended to do. But honestly I can imagine – in delegated admin scenarios – you might want portlet approvers who are not portlet definers at all.
To me the concern voiced in this ticket smells more like another permission under the PORTLET_PUBLISH owner: PORTLET_MODE_CONFIG. This permission governs access to CONFIG mode, which is the likely home of any sensitive settings. (I do not think chrome style, timeout, and icon URL are especially sensitive.) If you don't have this permission, already you cannot enter config mode, even for a portlet you can MANAGE* in some fashion or for a portlet type you can SELECT.
Even with PORTLET_MODE_CONFIG, however, there is still a concern roughly analogous to the one described above in that a skilled user w/o CONFIG access can enter arbitrary portlet preferences and thereby accomplish (typically) anything the CONFIG view was designed to handle. So maybe this ticket should be re-cast as "Prevent users w/o CONFIG permission on a portlet from entering arbitrary portlet preferences on that portlet."
> So maybe this ticket should be re-cast as "Prevent users w/o CONFIG permission..."
No. I'll gladly support clarifying CONFIG permission and how it relates to MANAGE and how it relates to SELECT_PORTLET_TYPE, but somewhere we need to reconcile MANAGE[-*] and SELECT_PORTLET_TYPE specifically, and I hope this ticket is it. I'll go ahead and create a separate sub-task for reconciling SELECT_PORTLET_TYPE and CONFIG permission. ( ).
> [Portlet type] is a new-portlet-only option; once set, it doesn't change (as it stands). So there's no issue of someone somehow making a choice on edit s/he couldn't make on create – the screen for that is not available.
That's not correct.
Users with MANAGE permission on a portlet can navigate from edit view on that portlet publication to the portlet type selection step in the workflow by clicking on the portlet type value in the edit view.
For instance, here's the edit view on a CMS portlet:
Clicking on "CMS" in that view takes you to the portlet type selection screen.
Testing just now, if I MANAGE a portlet that I don't have SELECT_PORTLET_TYPE on its type, then the UI element for the type doesn't display in the edit view
but it's just a matter of adding "&pP__eventId=chooseType" to the URL to navigate to the type selection workflow step anyway.
So. I think not displaying the type (but allowing one to navigate to type selection anyway via URL manipulation) is not the desired behavior when MANAGEing a portlet one cannot SELECT_PORTLET_TYPE on the type of. Goofy seeing blank where one expects the type to be named.
What is the desired behavior? Should lacking SELECT_PORTLET_TYPE except that type of portlet from management to which a user might otherwise be entitled by virtue of MANAGE on that portlet's Category, and so the resolution to the currently goofy display of portlet type in the edit view of these entries is that users just can't manage these portlets at all? Or should having MANAGE on a portlet imply permission to select, in the context of managing that portlet, that portlet's type? I think the former in the interest of failing closed – in the ambiguous configuration of a user having MANAGE but not having SELECT_PORTLET_TYPE on the type, we should resolve the ambiguity by granting less access than might be expected rather than by granting more access than might be expected. Otherwise some poor adopter is going to deny SELECT_PORTLET_TYPE on scarier types, grant MANAGE on a category, someone is going to inadvertently add a scary-type portlet to that category, and viola, careful SELECT_PORTLET_TYPE granting is circumvented with folks managing portlets of forbidden types.
> So there's no issue of someone somehow making a choice on edit s/he couldn't make on create
There is an issue of someone making a choice on create or edit that s/he shouldn't have been able to make, though. Parallel subtask created to track that to resolution.
Okay – apparently you can re-enter the screen where you choose portlet type (though it's interesting that there is not a category-link option to do so... you have to click on one row within a larger division). I'm not sure it's a good thing that it's possible to change that. The CPDs each define a framework of choices specific to a portletapp/portlet combo. I'm not sure the choices of one CPD would blend sensibly with another Java portlet.