> > My intent in my original profile proposal was that any user
> who is granted
> > a
> > given role is also granted access to the profiles for that
> given role. The
> > use-case was to share profiles(psml) by role -- i.e. psml
> pages for all
> > accountants.
> >
> I guess, by saying this, it is trying to change the semantics
> of Turbine's
> user-group-role access control semantics, where a role is
> always associated
> to user-group combination and is not a separate entity. So
> there can be
> multiple profiles associated to same role, through multiple
> groups. And
> since a user can be in multiple groups, the one-to-many
> relationship between
> user and profiles still holds. And as far as permissions
> goes, since they
> are defined, per role basis, we are just fine.
>
Yes, we don't have to follow the Turbine model, but I think there is a lot
of value in following it.
We should identify the requirements and then see if the Turbine model is the
right one.
I think we should gather more requirements from Jetspeed users and get some
opinions on the Jetspeed user list.
See Dave Carlson's email for a good example.
I know Paul Spencer has some good ideas on this subject.
Lets see what other requirements we can gather, and extend the profiler to
meet the needs of the Jetspeed community.
> Being said above, (and of-course if Jetspeed Profiler wants to follow
> Turbine's Access Control) we need to extend,
> TURBINE_USER_GROUP_ROLE table
> rather than TURBINE_USER table. We would be adding profiling
> information to
> the TURBINE_USER_GROUP_ROLE table along with other parameters like
> media-type, language, country etc..
>
I don't follow that at all, and I still don't understand why we need to
extend the TURBINE_USER table for a 1-many relationship.
TURBINE_USER_GROUP_ROLE is an associate table (see
http://www.dmreview.com/master.cfm?NavID=198&EdID=2308 for a good set of
articles on de-embedding foreign keys with associative tables) -- I do not
think we should be modifying this table.
> Also, then the Profiler has to smart enough, to decide the
> exact profiler to
> pick, depending upon the role/permissions. So, if a user is
> in two different
If no profile is specified, the algorithim right now is to use the default
profile for the current user based on the runtime request parameters
(mediatype language, country).
Currently Roles can be specified in the request param as in
/role/roleResource.
It would be nice if the profile location algorithm could be pluggable, so
that you could easily plug-in a different algorithm such as the one you are
explaining.
-david
> roles e.g. Architect and Programmer then a particular role has to take
> precedence over the other. Some one (Jetspeed Administrator/Security
> Portlet) has to maintain this information for Profiler.
>
> Hope, I am not complicating things even further...
>
> -Atul
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
