Concept of assigning permissions to roles

[Jefferson Uy <je...@islanddata.com>]

Hi,

I have posted this on the user's list but no one has commented on it.. so
maybe I'll try it with developers to see if my concept of using roles to
limit access to portlets is the way to go or not...

===

I have taken a good look at how Jetspeed works. However, there is one aspect
of it that is different from our own
concept. This is with regards to the assigning of permissions to Roles.

So far, the portals I have seen use Roles to choose which portlets/content
are available for a user to view/access. However, Jetspeed uses Roles
differently such that Roles are used to choose what type of action (i.e.,
close, customize,detach, info,maximize, minimize, personalize, view) a user
assigned with that role can do. 

Is there a plan to change this concept in future releases? (to use Roles for
choosing which portlets a user can access rather than actions as what it is
now is release 1.3a2) Actually, the concept I'm advocating is how the
"admin" role works now... such that if I assign a user the "admin" role, all
the security portlets associated with admin shows up in the list of portlets
to add to the desktop.

Another question I have is that the permission browser comes with the
following default permissions: close, customize,detach, info,maximize,
minimize, personalize, view. Only customize seems to work as intended. What
are the other permissions for or are they not working? I have an idea on
what maximize, minimize may mean but I can't get confirmation since it does
not seem to work.

thanks.. jeff

RE: Concept of assigning permissions to roles

[David Sean Taylor <da...@bluesunrise.com>]

> -----Original Message-----
> From: Jefferson Uy [mailto:jefferson.uy@islanddata.com] 
> Sent: Wednesday, March 27, 2002 8:58 AM
> To: 'jetspeed-dev@jakarta.apache.org'
> Subject: Concept of assigning permissions to roles
> 
> 
> Hi,
> 
> I have posted this on the user's list but no one has 
> commented on it.. so maybe I'll try it with developers to see 
> if my concept of using roles to limit access to portlets is 
> the way to go or not...
> 
> ===
> 
> I have taken a good look at how Jetspeed works. However, 
> there is one aspect of it that is different from our own 
> concept. This is with regards to the assigning of permissions 
> to Roles.
> 
> So far, the portals I have seen use Roles to choose which 
> portlets/content are available for a user to view/access. 
> However, Jetspeed uses Roles differently such that Roles are 
> used to choose what type of action (i.e., close, 
> customize,detach, info,maximize, minimize, personalize, view) 
> a user assigned with that role can do. 

Roles can be assigned to portlets. See the admin.xreg:

  <portlet-entry type="ref" parent="CustomizerVelocity"
name="RolePermissionForm">
    <security role="admin"/>

This portlet will not be shown in the add portlets list unless the user
has the admin role

> 
> Is there a plan to change this concept in future releases? 

Yes, there have been lots of plans, but no action.
See the cvs /proposals/0004.txt
I believe another security proposal or 2 should be arriving shortly to
this list...

> (to use Roles for choosing which portlets a user can access 
> rather than actions as what it is now is release 1.3a2) 
> Actually, the concept I'm advocating is how the "admin" role 
> works now... such that if I assign a user the "admin" role, 
> all the security portlets associated with admin shows up in 
> the list of portlets to add to the desktop.
> 
> Another question I have is that the permission browser comes 
> with the following default permissions: close, 
> customize,detach, info,maximize, minimize, personalize, view. 

Those are just the default permissions for windows controls.
You can add other permissions to the model.
I was under the impression that this worked. 
If it isn't working, please log a bug in bugzilla

> Only customize seems to work as intended. What are the other 
> permissions for or are they not working? I have an idea on 
> what maximize, minimize may mean but I can't get confirmation 
> since it does not seem to work.

Taking maximize action for example:
If you don't have permission for the maximize button, you won't see it
on the window.


> 
> thanks.. jeff
> 
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>