> -----Original Message-----
> From: David Sean Taylor [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, September 08, 2001 8:15 PM
> To:   [EMAIL PROTECTED]
> Subject:      RE: XML Database schema for DatabasePsmlManager
> Implementation
> 
> > > 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.
> 
        [Atul Dambalkar]  Sure.

> > 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
        [Atul Dambalkar]  I read and liked the article, thanks for the
pointer.
> articles on de-embedding foreign keys with associative tables) -- I do not
> think we should be modifying this table.
> 
        [Atul Dambalkar]  As long as we can identify a user profile with
particular group-role... But of-course as you said, we should first gather
Jetspeed-user requirements before taking any decision on profiling.

> > 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).
> 
        [Atul Dambalkar]  Sure, a default profile is definitely needed in
any case.

> Currently Roles can be specified in the request param as in
> /role/roleResource.
        [Atul Dambalkar]  True.

> 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.
        [Atul Dambalkar]  That would be one more step towards
customization..and would be a nice to have feature.

        -Atul

> -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]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to