You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Gary Lawrence Murphy <ga...@canada.com> on 2003/01/06 01:04:25 UTC

Role of psml role pages

This may be a naive question, but knowing one way or the other
might save me some time hunting (and the tutorial makes very few
mentions of the role psml files) ...

In the docs, the structure of psml files is said to be 'arbitrary'
but I'm expecting the psml for user roles to be somehow merged
with the user when they login.  Is this the way it is supposed to
work?  Or must I explicitly link the role psml in the user spec?

If roles are /merged/, then wouldn't it make sense to ship the
default/sample config where the roles contain most of the preconfigured
portlets instead of the current method where these are distributed
through the two sample user accounts?

-- 
Gary Lawrence Murphy - garym@teledyn.com - TeleDynamics Communications
   - blog: http://www.teledyn.com/mt/ - biz: http://teledyn.com/ -
  "Computers are useless. They can only give you answers." (Picasso)

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


Re: Generating Role-based Profiles? (was Re: Role of psml role pages)

Posted by Gary Lawrence Murphy <ga...@canada.com>.
>>>>> "D" == David Sean Taylor <da...@bluesunrise.com> writes:

    D> No, It should save it to the user's PSML if you customize.  

Ok, that's good news, but what happens when I change the user's
role to another role?  If I promote a member to paid membership,
I still have to add a link to the role-psml by hand, right?

I'm beginning to think my idea of using links to reference the role
might be the easiest method, so promoting someone means

      1) assign them to the new role, remove the old one
      2) manually delete the old role-psml link and add the new one

These two steps can probably (someday) get automated by an Action,
but I think that would give me what I seek since, if all they have
is a link to the role-psml, if I add or delete services to the
deref'd psml, the changes would show up universally across all
role members. (right?)

-- 
Gary Lawrence Murphy - garym@teledyn.com - TeleDynamics Communications
   - blog: http://www.teledyn.com/mt/ - biz: http://teledyn.com/ -
  "Computers are useless. They can only give you answers." (Picasso)

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


Re: Generating Role-based Profiles? (was Re: Role of psml role pages)

Posted by David Sean Taylor <da...@bluesunrise.com>.
On Sunday, January 5, 2003, at 10:58  PM, Gary Lawrence Murphy wrote:

>
> Thanks for the clarification on this, and I hope I can prod you
> for a few more questions :)
>
>>>>>> "D" == David Sean Taylor <da...@bluesunrise.com> writes:
>
>     D> There is another Profiler feature, Role-based fallback. It
>     D> could work for you, but only if your user has one role, and if
>     D> your user doesn't have his or her own PSML resource.
>
> I was almost using this method; I had assigned multiple roles so
> that's more like your extended fallback ...
>
>     D> One option would be to extend Role-based fallback to merge PSML
>     D> from all of the user's roles. This would require coding.
>
> The composite role trick might work, but just so I'm clear on this, if
> a user has only one role, no personal profile will be created, but
> doesn't that also mean the person can never edit their configuration?
> (or does it mean that, if they do any customizing, they edit the role
> for everyone?)
>
No, It should save it to the user's PSML if you customize.
I haven't tried it recently though. I always turn off customization for 
users with role-based fallback.

--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646




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


Re: Generating Role-based Profiles? (was Re: Role of psml role pages)

Posted by Gary Lawrence Murphy <ga...@canada.com>.
>>>>> "M" == Mark Orciuch <ma...@ngsltd.com> writes:

    M> Is this what you want?  # # Profiler Role-based merge fallback
    M> options # # When rolefallback is true and rolemerge is true,
    M> new user's profile will # be an aggregate of psml from each
    M> role the user is part of.  services.Profiler.rolemerge=true

    M> # Controller to use in merged profile
    M> services.Profiler.rolemerge.controller=TabController

    M> # Control to use in merged profile
    M> services.Profiler.rolemerge.control=TabControl

This is still basically a one-shot clone operation; the role-based
profile only works if there is only one role, and if that's the case,
then there's no need to merge it.

I think the only viable solution to this problem is programatic: There
needs to be a far more elaborate admin tool which, when it assigns
roles to people, links them to the role profile, and when it removes
roles, cuts the link -- this means the role psml is not customizable
so a secondary, but much more difficult change calls for customizations
to be held seperate from the portlet definition.

That may not be all that difficult: When a user is assigned to a role,
a new portlet is created in their profile, but as a "reference" style
and with no options or parameters; customizations would then be added
to that user-psml such that if the underlining role-psml definition is
altered, options the user /hasn't/ changed would show the change.

-- 
Gary Lawrence Murphy - garym@teledyn.com - TeleDynamics Communications
   - blog: http://www.teledyn.com/mt/ - biz: http://teledyn.com/ -
  "Computers are useless. They can only give you answers." (Picasso)

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


RE: Generating Role-based Profiles? (was Re: Role of psml role pages)

Posted by Mark Orciuch <ma...@ngsltd.com>.
Is this what you want?

#
# Profiler Role-based merge fallback options
#
# When rolefallback is true and rolemerge is true, new user's profile will
# be an aggregate of psml from each role the user is part of.
services.Profiler.rolemerge=true

# Controller to use in merged profile
services.Profiler.rolemerge.controller=TabController

# Control to use in merged profile
services.Profiler.rolemerge.control=TabControl


Best regards,

Mark Orciuch - morciuch@apache.org
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/
>
>
> Maybe this have already been answered, but here goes...
> By default in JetspeedResources.properties,
> services.Profiler.newuser.template=turbine
> which means that any new users "clone" the default.psml files as it's own.
> If you set
> services.Profiler.newuser.template=
> any new users clone the default.psml files for the role the new
> users are placed into, that's great...  BUT, if that new user
> then customizes somthing, it changes the default.psml file for
> that role, effecting all the other users under that role, not so
> great.  BTW, Jetspeed doesn't seem to create any new directory
> for that user on the psml/user directory for those customizations
> to be saved into...
> So here is the question, how do I use the role's psml files as
> the template, but  create a new directory for that user under
> psml/user, thus keeping his customizations separate?  Seems the
> most desirable (and obvious) behavior doesn't it?  It took me a
> while to figure what it was really doing (as described above).
> Thanks,
>              Mike
>


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


Re: Generating Role-based Profiles? (was Re: Role of psml role pages)

Posted by Mike Davis <th...@yahoo.com>.
Maybe this have already been answered, but here goes...
By default in JetspeedResources.properties, 
services.Profiler.newuser.template=turbine
which means that any new users "clone" the default.psml files as it's own.
If you set
services.Profiler.newuser.template=
any new users clone the default.psml files for the role the new users are placed into, that's great...  BUT, if that new user then customizes somthing, it changes the default.psml file for that role, effecting all the other users under that role, not so great.  BTW, Jetspeed doesn't seem to create any new directory for that user on the psml/user directory for those customizations to be saved into... 
So here is the question, how do I use the role's psml files as the template, but  create a new directory for that user under psml/user, thus keeping his customizations separate?  Seems the most desirable (and obvious) behavior doesn't it?  It took me a while to figure what it was really doing (as described above). 
Thanks,
             Mike
 
 
 Gary Lawrence Murphy <ga...@canada.com> wrote:
Thanks for the clarification on this, and I hope I can prod you
for a few more questions :)

>>>>> "D" == David Sean Taylor writes:

D> There is another Profiler feature, Role-based fallback. It
D> could work for you, but only if your user has one role, and if
D> your user doesn't have his or her own PSML resource.

I was almost using this method; I had assigned multiple roles so
that's more like your extended fallback ...

D> One option would be to extend Role-based fallback to merge PSML
D> from all of the user's roles. This would require coding.

The composite role trick might work, but just so I'm clear on this, if
a user has only one role, no personal profile will be created, but
doesn't that also mean the person can never edit their configuration?
(or does it mean that, if they do any customizing, they edit the role
for everyone?)

D> Yet another option: when you perform the maintenance functions:
D> add role upon registration, or remove role upon expiration,
D> programmatically remove the the portlets (or references) from
D> their personal PSML page.

This is more or less the Action-based promote-demote process I had
envisaged, only I hadn't considered also modifying their psml; it will
probably come down to this approach since any dynamic role-merging
appears to preclude other personal customizations.

Thanks again for the clarifications.

-- 
Gary Lawrence Murphy - garym@teledyn.com - TeleDynamics Communications
- blog: http://www.teledyn.com/mt/ - biz: http://teledyn.com/ -
"Computers are useless. They can only give you answers." (Picasso)

--
To unsubscribe, e-mail: 
For additional commands, e-mail: 



---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

Re: Generating Role-based Profiles? (was Re: Role of psml role pages)

Posted by Gary Lawrence Murphy <ga...@canada.com>.
Thanks for the clarification on this, and I hope I can prod you
for a few more questions :)

>>>>> "D" == David Sean Taylor <da...@bluesunrise.com> writes:

    D> There is another Profiler feature, Role-based fallback. It
    D> could work for you, but only if your user has one role, and if
    D> your user doesn't have his or her own PSML resource.

I was almost using this method; I had assigned multiple roles so
that's more like your extended fallback ...

    D> One option would be to extend Role-based fallback to merge PSML
    D> from all of the user's roles. This would require coding.

The composite role trick might work, but just so I'm clear on this, if
a user has only one role, no personal profile will be created, but
doesn't that also mean the person can never edit their configuration?
(or does it mean that, if they do any customizing, they edit the role
for everyone?)

    D> Yet another option: when you perform the maintenance functions:
    D> add role upon registration, or remove role upon expiration,
    D> programmatically remove the the portlets (or references) from
    D> their personal PSML page.

This is more or less the Action-based promote-demote process I had
envisaged, only I hadn't considered also modifying their psml; it will
probably come down to this approach since any dynamic role-merging
appears to preclude other personal customizations.

Thanks again for the clarifications.

-- 
Gary Lawrence Murphy - garym@teledyn.com - TeleDynamics Communications
   - blog: http://www.teledyn.com/mt/ - biz: http://teledyn.com/ -
  "Computers are useless. They can only give you answers." (Picasso)

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


Re: Generating Role-based Profiles? (was Re: Role of psml role pages)

Posted by David Sean Taylor <da...@bluesunrise.com>.
On Sunday, January 5, 2003, at 07:34  PM, Gary Lawrence Murphy wrote:

> oh oh ... within seconds I realize a severe flaw in my plan, and a
> flaw in the current Jetspeed role-based model: The whole /point/ of
> role-based access is because people change whereas roles remain the
> same, but in the current role-merging model, once a person is granted
> the structure of some role's portlets, if they are re-assigned to some
> other role, although the security model can prevent them from /seeing/
> particular portlets, the only way to actually remove them is to do it
> manually.
>
> Here's my exact problem, and maybe this will give someone a better
> idea for how I could accomplish this:
>
>      I have public members, paid members and internal staff members.
>
>      Everyone is anonymous until they register, at which point they
>      become a public member.
>
>      Paid members are promoted from the public members, and are
>      demoted if their subscription lapses.
>
>      Ideally, one supervisory role among the staff has exclusive
>      access to do this promotion, and that suggests an Action
>      within a VelocityPortlet instead of the normal user editor.
>
>      Members could go straight from public membership to staff;
>      staff is not a superset of paid, it is only partially
>      overlapping.
>
> Are there any magic bullets for doing what I need to do here?
>

 From what I understand, you have several role-PSML pages.
 From what I read, I gather you are using the Profiler's Role Merge 
feature.
If that is the case, then when you remove the role for a user, i.e. 
when their subscription expires, the portlets will still be available 
on the page.
Likewise, by adding a role to a user, it will not automatically gather 
new portlets.

If you were to add security permissions on the portlets, this would 
prevent the user from seeing the portlets in the subscription 
expiration case.
However, it doesn't grant the new set of portlets to the user upon 
granting of a role.

There is another Profiler feature, Role-based fallback. It could work 
for you, but only if your user has one role, and if your user doesn't 
have his or her own PSML resource.
One option would be to extend Role-based fallback to merge PSML from 
all of the user's roles. This would require coding.

Another option: provide a role for each combination: public, 
public+paid... and then use the role-based fallback algorithm as is.  
You could also use PSML references in the combined pages.

Yet another option: when you perform the maintenance functions: add 
role upon registration, or remove role upon expiration, 
programmatically remove the the portlets (or references) from their 
personal PSML page.

--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646




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


Re: Generating Role-based Profiles? (was Re: Role of psml role pages)

Posted by Gary Lawrence Murphy <ga...@canada.com>.
oh oh ... within seconds I realize a severe flaw in my plan, and a
flaw in the current Jetspeed role-based model: The whole /point/ of
role-based access is because people change whereas roles remain the
same, but in the current role-merging model, once a person is granted
the structure of some role's portlets, if they are re-assigned to some
other role, although the security model can prevent them from /seeing/
particular portlets, the only way to actually remove them is to do it
manually.

Here's my exact problem, and maybe this will give someone a better
idea for how I could accomplish this:  

     I have public members, paid members and internal staff members.

     Everyone is anonymous until they register, at which point they
     become a public member.

     Paid members are promoted from the public members, and are
     demoted if their subscription lapses.  

     Ideally, one supervisory role among the staff has exclusive
     access to do this promotion, and that suggests an Action
     within a VelocityPortlet instead of the normal user editor.

     Members could go straight from public membership to staff;
     staff is not a superset of paid, it is only partially 
     overlapping.

Are there any magic bullets for doing what I need to do here?

-- 
Gary Lawrence Murphy - garym@teledyn.com - TeleDynamics Communications
   - blog: http://www.teledyn.com/mt/ - biz: http://teledyn.com/ -
  "Computers are useless. They can only give you answers." (Picasso)

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


Generating Role-based Profiles? (was Re: Role of psml role pages)

Posted by Gary Lawrence Murphy <ga...@canada.com>.
Seems the role-based profiles are a good way toward what I need,
but I see a useability problem: Rules change.  When there are policy
changes for some organizational role, these could affect what can
and what must appear on the desktop for those members, but in the
current "generate at create" model, the only way to propagate those
changes to all current members in the affected role is to delete
the members and re-create the accounts, and this would lose any
of the member customizations.

Here's my proposed work-around, and please tell me if there is an
easier way ;) ... if the links are resolved at login time, then
role-merge templates should only include link references to other
psml files where the actual portlets for that role are set out.

I haven't tried it yet, but I'm expecting that this will work, only
this may mean that the members themselves will be unable to customize
any of the role-based portlet configurations (or will they be allowed
to make changes global across all members?)  That's a bit of a pain,
but if its the only way to let them keep personal configurations 
across role psml updates, then we'll have to live with it.

Is there a better way?

-- 
Gary Lawrence Murphy - garym@teledyn.com - TeleDynamics Communications
   - blog: http://www.teledyn.com/mt/ - biz: http://teledyn.com/ -
  "Computers are useless. They can only give you answers." (Picasso)

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


Re: Role of psml role pages

Posted by Gary Lawrence Murphy <ga...@canada.com>.
I think I may have found my answer, and it's a caveat about 
spending too much time with the tutorial's merge files instead
of referring to the core system property files.

The short answer is that the behaviour I wanted is configurable, but
turned off by default. I found the following in the archives:

http://www.mail-archive.com/jetspeed-user@jakarta.apache.org/msg06701.html

-- 
Gary Lawrence Murphy - garym@teledyn.com - TeleDynamics Communications
   - blog: http://www.teledyn.com/mt/ - biz: http://teledyn.com/ -
  "Computers are useless. They can only give you answers." (Picasso)

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