> -----Original Message-----
> From: David Sean Taylor [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, September 08, 2001 8:30 PM
> To: [EMAIL PROTECTED]
> Subject: RE: XML Database schema for DatabasePsmlManager
> Implementation
>
> > -----Original Message-----
> > From: Dave Carlson [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, September 08, 2001 6:24 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: XML Database schema for DatabasePsmlManager
> > Implementation
> >
> >
> > Or, if a user has more than one possible profile,
> >
> > a) create a sceen on user login where the user can pick which
> > profile is
> > preferred.
> >
>
> Yes, I've discussed that scenario with Raphael -- its definately needed.
> Right now, when you create a new user, you simply get the Turbine user
> default profile -- and thats it.
> If the Turbine user isn't there, then you get exceptions...
> No other choice. Our (vague) idea was an intermediate screen that you are
> shown after creating a new user, that allows you to choose from a list of
> default profiles for new users. You could even choose: public projects to
> join, and roles that you want to take on, although for some sites this may
> be preferred as an administrative task.
>
> > b) if the user is in more than one group (project), create a
> > login screen
> > where the user selects the project that is used to create a
> > context/profile
> > for this login session.
>
> That has some possibilities, like introducing the 'project' variable to
> the
> portal.
>
> >
> > c) generate a set of top-level tabbed panes, one per project profile
>
> Yes, this is still possible with option (b), since you still have multiple
> profiles per user.
>
> With option (b), Jon's recommendation for basing profiles on
> user/role/project(group) does make sense.
> So when a user logs on -- they logon with their username/password and
> optionally their project.
> If they don't log on to a project, then we can just use a default project.
[Atul Dambalkar] I like option (b). I think, basically, Jon's
recommendations do cover more use cases...but we'll gather user
requirements.
> I still think there is a need for common profiles that are not specific to
> a
> user.
> On a previous project, I made use of that a lot.
>
[Atul Dambalkar] I fully agree, we need a common profile for each
profile-type user/role/group, something like "anonymous".
> -david
>
> >
> > I think I prefer option (b)
> >
> > -- Dave
> >
> > ----- Original Message -----
> > From: "Atul Dambalkar" <[EMAIL PROTECTED]>
> > >
> > > 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
> > > 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...
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]