Santiago Gala wrote:
> Paul Spencer wrote:
>
> (I snip most. I agree with most of it)
>
>>
>>
>> Missing group = all user have access based on roles.
>
>
> As turbine roles are defined in a triple group-role-user, this
> should better be rephrased as "all users have access based on
> roles in global group". I'm not picky, this is important. This
> misunderstanding is the root of most problems we have experienced.
> A user has *no* role unless you pick up a group.
>
>>
>> Missing roles = all user have "default access"
>
>
> This could be the users have the permissions returned by
data.getACL().hasPermission("xxx"),
> but, again, this is implemented in turbine as return
> hasPermission(permission, TurbineSecurity.getGlobalGroup());, so
> it means "access according to permissions in the global group" The
> precise meaning of a role constraint is "data.getACL().hasRole(
> role ) && data.getACL().hasPermission( "xxx" ) returns true",
> where xxx is the action to be performed. It restricts the
> permission further, since I could have view permission, but not
> clerk role, for instance.
>
Since the user creation and group/role assignment is managed through
Jetspeed, we can enforce a user configuration the does not utilize any
group or role defaults. In addition, we should document "no group" and
"no role" as unsupported.
>>
>>
>> We also need to define a standard set of permissions: view -
>> Allows portlet content to be viewed and added to pane customize
>> - Allows portlet to be customized
>
>
> This can/should be required at the portletset level
This should be allowed. Granted the portlet type can enable of disable
a permission, like customize. I think the ability to say "this portlet
can be customized" in the registry entry is valuable. Doing this by
adding permissions to the <portlet-entry> is one way to do this. Another
is with parameters that are utilized by the allowCustomize type methods.
>
>>
>> minimize - allows portlet to be minimized
>>
>> maximize - allows portlet to be maximized remove - allows
>> portlet to be removed from pane
>>
>> move - allows portlet to be moved in pane
>
>
> This one looks very difficult to implement, since in a two column
layout,
> moving one portlet shuffles the rest (effectively moving them). Ideas?
>
Portlets can not move past a non-moveable portlet. This still leave a
few holes. Documented Known Problems/restrictions :)
o If the non-moveable portlet is not in the first row, then
preceding portlet can be deleted. Thus moving the non-moveable
portlet up.
o If the non-moveable portlet is not in the first row, then
the portlet can be moved down by a portlet that is moved to
the first row from an adjacent column.
>
>>
>>
>>
>> One other area the is related, it the ability to have common portlet(s)
>> the are maintained in one place for a group of users. As an
>> example corporate E-mail and corporate News should be on all
>> pages and in the left column. (I am not ask this be addressed
>> now, just be aware of this desired functionality while designing
>> the security changes)
>
>
> This again could be implemented with relative ease at the portletset
level, except that a multi-column layout is *not* a portletset. I mean
> something like the customiser not allowing to modify a given part of the
> PSML. If a Document is composed of a (role=admin)set which includes
> several (unrestricted)portletsets, the user could modify only the inner
> ones, but should respect the structure of the outer one. We will work
> security in the PSML structure/customiser later on, when we have the
> basics sorted out.
>
I expect the customizer will need to support nesting portlet sets. As a
enable having a "row" that contains a "column" and a "multi-column"
portletset. But this is outside the scope of "Security changes"
>
>
>
Paul Spencer
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
