Re: How to create a custom profiling rule?

2005-01-07 Thread Randy Watler
Marina,
*.link files are only displayed if addressable in the "/" request 
directory as rootLinks, or as elements of a document set. This explains 
why they are not visible if located in the "/dce-portal" directory. 
Security limitations apply to link visibility, so perhaps that might 
explain why you do not see them when placed in the "/" directory?

We still need to discuss use of the "/dce-portal" directory with your 
custom profiling rule, but I do not think it is messing up the display 
of rootLinks... of course, I might be missing something that should be 
obvious.

Randy
Marina wrote:
Sorry to bother you all with this again...
Ok, after I've done all these changes, I found a new
problem as well:
no links (*.link files) are displayed on either of the
pages, for neither of the users. 

I tried placing them in the "/" and /dce-portal
directory, but still nothing is displayed.
Is this a problem with my new profiling rule?
What determines whether links are displayed or not?
Thanks!
Marina
--- Marina <[EMAIL PROTECTED]> wrote:
 

Randy,
thanks for your help. You are probably right and I
made it more complicated than what it should be.
Basically, what I would like to have in my portal
is:
1. all application-specific portal pages/ docsets/
links should be in a separate directory, say,
.../pages/dce-portal/
2. users ('dce-user', 'dce-admin') with the
'dce-user-role' should be able to see one main page,
dce-main-page.psml, and one additional page as a
tab,
dce-users-page.psml. Both .psml pages are in the
.../pages/dce-portal/ directory
3. a generic (non-logged in, 'guest') user should
see
the ../pages/dce-portal/dce-main-page.psml, and
nothing else
So, to accomplish this, I have created this custom
profiling rule:
insert into PROFILING_RULE values ('dce-generic',
   

'org.apache.jetspeed.profiler.rules.impl.StandardProfilingRule',
 

'rule for non-logged in DCE portal users')
insert into RULE_CRITERION values ('100',
'dce-generic', 0, 'path', 'path', '/dce-portal', 0)
and assigned it to the 'guest', 'dce-user' and
'dce-admin' users.
This made all pages visible to these three users. To
restrict access to the user-specific page to the
users
with the 'dce-user-role' role, I've added the
following security constraints to the
dce-users-page.psml:
 
dce-user-role
view
  
Well, that did work. With the exception of those
problems I mentioned in my previous post (one of
them
was fixed by using #if($site.rootLinks.isEmpty()) as
David suggested)
So, the only problem that is still left is inclusion
of the .ds sets from the '/' directory. I would
rather
like to use the ../pages/dce-portal/ as the root
directory, but my profiling rule does not seem to
accomplish this.
I hope I'm being clear :)
And thanks a lot for looking into this!
Marina  

--- Randy Watler <[EMAIL PROTECTED]> wrote:
   

Marina,
Using the Profiler effectively is more in my
 

court,
   

so let's see if I can
help here.
I think there are three subjects here that need
individual attention:
1. you probably do not need to define a new
profiling rule... there are some
predefined rules that you can use to achieve
role-based profiling,
2. the demo site is just that and you should start
with a clean
WEB-INF/pages directory only adding in what you
 

need
   

from the demo site, and
3. the tigris sample decorator is a good starting
place, but most everyone
ends up customizing and deploying their own
 

flavor.
   

So, rather than trying to figure out what you have
now, I would like to know
what your objective is. I'll then tell you how I'd
solve it using the M1
release version. We can then compare notes and
 

take
   

it from there... ok?
Randy
-Original Message-
From: Marina
To: Jetspeed Users List
Sent: 12/30/04 1:26 PM
Subject: Re: How to create a custom profiling
 

rule?
   

David, 
Thanks for the clarification. I did find a way to
 

do
   

role-based profiling, basically, by restricting
access
to specific PSML pages by roles.
I still have a few problems I was not able to
 

solve
   

so
far. The main one is that I still get some
 

elements
   

from the '/' directory included into my pages,
 

even
   

though I explicitly specified in my profiling rule
that only elements from a specific directory
 

should
   

be
used. I think I made some stupid mistakes while
creating custom profiling rules...
Here is how I setup my portal's content and
 

created
   

a
new profiling rule using direct SQL (I don't think
it
is possible to that through the Admin portlets
 

yet):
   

1. create new directory for my Portal content:
pages/dce-portal
place into this directory:
dce-main-page.psml
dce-user-p

RE: How to create a custom profiling rule?

2005-01-07 Thread Marina
Sorry to bother you all with this again...

Ok, after I've done all these changes, I found a new
problem as well:
no links (*.link files) are displayed on either of the
pages, for neither of the users. 

I tried placing them in the "/" and /dce-portal
directory, but still nothing is displayed.

Is this a problem with my new profiling rule?
What determines whether links are displayed or not?

Thanks!
Marina

--- Marina <[EMAIL PROTECTED]> wrote:

> Randy,
> thanks for your help. You are probably right and I
> made it more complicated than what it should be.
> 
> Basically, what I would like to have in my portal
> is:
> 
> 1. all application-specific portal pages/ docsets/
> links should be in a separate directory, say,
> .../pages/dce-portal/
> 
> 2. users ('dce-user', 'dce-admin') with the
> 'dce-user-role' should be able to see one main page,
> dce-main-page.psml, and one additional page as a
> tab,
> dce-users-page.psml. Both .psml pages are in the
> .../pages/dce-portal/ directory
> 
> 3. a generic (non-logged in, 'guest') user should
> see
> the ../pages/dce-portal/dce-main-page.psml, and
> nothing else
> 
> So, to accomplish this, I have created this custom
> profiling rule:
> insert into PROFILING_RULE values ('dce-generic',
>
'org.apache.jetspeed.profiler.rules.impl.StandardProfilingRule',
> 'rule for non-logged in DCE portal users')
> 
> insert into RULE_CRITERION values ('100',
> 'dce-generic', 0, 'path', 'path', '/dce-portal', 0)
> 
> and assigned it to the 'guest', 'dce-user' and
> 'dce-admin' users.
> This made all pages visible to these three users. To
> restrict access to the user-specific page to the
> users
> with the 'dce-user-role' role, I've added the
> following security constraints to the
> dce-users-page.psml:
>   
>  dce-user-role
>  view
>
> 
> 
> Well, that did work. With the exception of those
> problems I mentioned in my previous post (one of
> them
> was fixed by using #if($site.rootLinks.isEmpty()) as
> David suggested)
> 
> So, the only problem that is still left is inclusion
> of the .ds sets from the '/' directory. I would
> rather
> like to use the ../pages/dce-portal/ as the root
> directory, but my profiling rule does not seem to
> accomplish this.
> 
> I hope I'm being clear :)
> 
> And thanks a lot for looking into this!
> 
> Marina  
> 
> --- Randy Watler <[EMAIL PROTECTED]> wrote:
> 
> > Marina,
> > 
> > Using the Profiler effectively is more in my
> court,
> > so let's see if I can
> > help here.
> > 
> > I think there are three subjects here that need
> > individual attention:
> > 
> > 1. you probably do not need to define a new
> > profiling rule... there are some
> > predefined rules that you can use to achieve
> > role-based profiling,
> > 2. the demo site is just that and you should start
> > with a clean
> > WEB-INF/pages directory only adding in what you
> need
> > from the demo site, and
> > 3. the tigris sample decorator is a good starting
> > place, but most everyone
> > ends up customizing and deploying their own
> flavor.
> > 
> > So, rather than trying to figure out what you have
> > now, I would like to know
> > what your objective is. I'll then tell you how I'd
> > solve it using the M1
> > release version. We can then compare notes and
> take
> > it from there... ok?
> > 
> > Randy
> > 
> > -Original Message-
> > From: Marina
> > To: Jetspeed Users List
> > Sent: 12/30/04 1:26 PM
> > Subject: Re: How to create a custom profiling
> rule?
> > 
> > David, 
> > Thanks for the clarification. I did find a way to
> do
> > role-based profiling, basically, by restricting
> > access
> > to specific PSML pages by roles.
> > 
> > I still have a few problems I was not able to
> solve
> > so
> > far. The main one is that I still get some
> elements
> > from the '/' directory included into my pages,
> even
> > though I explicitly specified in my profiling rule
> > that only elements from a specific directory
> should
> > be
> > used. I think I made some stupid mistakes while
> > creating custom profiling rules...
> > 
> > Here is how I setup my portal's content and
> created
> > a
> > new profiling rule using direct SQL (I don't think
>

RE: How to create a custom profiling rule?

2005-01-03 Thread Marina
Randy,
thanks for your help. You are probably right and I
made it more complicated than what it should be.

Basically, what I would like to have in my portal is:

1. all application-specific portal pages/ docsets/
links should be in a separate directory, say,
.../pages/dce-portal/

2. users ('dce-user', 'dce-admin') with the
'dce-user-role' should be able to see one main page,
dce-main-page.psml, and one additional page as a tab,
dce-users-page.psml. Both .psml pages are in the
.../pages/dce-portal/ directory

3. a generic (non-logged in, 'guest') user should see
the ../pages/dce-portal/dce-main-page.psml, and
nothing else

So, to accomplish this, I have created this custom
profiling rule:
insert into PROFILING_RULE values ('dce-generic',
'org.apache.jetspeed.profiler.rules.impl.StandardProfilingRule',
'rule for non-logged in DCE portal users')

insert into RULE_CRITERION values ('100',
'dce-generic', 0, 'path', 'path', '/dce-portal', 0)

and assigned it to the 'guest', 'dce-user' and
'dce-admin' users.
This made all pages visible to these three users. To
restrict access to the user-specific page to the users
with the 'dce-user-role' role, I've added the
following security constraints to the
dce-users-page.psml:
  
 dce-user-role
 view
   


Well, that did work. With the exception of those
problems I mentioned in my previous post (one of them
was fixed by using #if($site.rootLinks.isEmpty()) as
David suggested)

So, the only problem that is still left is inclusion
of the .ds sets from the '/' directory. I would rather
like to use the ../pages/dce-portal/ as the root
directory, but my profiling rule does not seem to
accomplish this.

I hope I'm being clear :)

And thanks a lot for looking into this!

Marina  

--- Randy Watler <[EMAIL PROTECTED]> wrote:

> Marina,
> 
> Using the Profiler effectively is more in my court,
> so let's see if I can
> help here.
> 
> I think there are three subjects here that need
> individual attention:
> 
> 1. you probably do not need to define a new
> profiling rule... there are some
> predefined rules that you can use to achieve
> role-based profiling,
> 2. the demo site is just that and you should start
> with a clean
> WEB-INF/pages directory only adding in what you need
> from the demo site, and
> 3. the tigris sample decorator is a good starting
> place, but most everyone
> ends up customizing and deploying their own flavor.
> 
> So, rather than trying to figure out what you have
> now, I would like to know
> what your objective is. I'll then tell you how I'd
> solve it using the M1
> release version. We can then compare notes and take
> it from there... ok?
> 
> Randy
> 
> -Original Message-
> From: Marina
> To: Jetspeed Users List
> Sent: 12/30/04 1:26 PM
> Subject: Re: How to create a custom profiling rule?
> 
> David, 
> Thanks for the clarification. I did find a way to do
> role-based profiling, basically, by restricting
> access
> to specific PSML pages by roles.
> 
> I still have a few problems I was not able to solve
> so
> far. The main one is that I still get some elements
> from the '/' directory included into my pages, even
> though I explicitly specified in my profiling rule
> that only elements from a specific directory should
> be
> used. I think I made some stupid mistakes while
> creating custom profiling rules...
> 
> Here is how I setup my portal's content and created
> a
> new profiling rule using direct SQL (I don't think
> it
> is possible to that through the Admin portlets yet):
> 
> 1. create new directory for my Portal content:
> pages/dce-portal
> place into this directory:
> dce-main-page.psml
> dce-user-page.psml
> folder.metadata
> 
> 2. define new role, 'dce-user-role', and assign it
> to
> the 'dce-user' user
> 
> 3. define security constraints in the
> folder.metadata:
> 'guest' users can view all pages;
> users with 'dce-user-role' role can view all pages
> 
>   
> 
>   guest
>   view
> 
> 
>   dce-user-role
>   view
> 
> 
> 
> 4. define security constraints in the
> dce-main-page.psml:
>   
>   
> 
>   *
>   view
> 
>   
> 
> 5. define security constraints in the
> dce-user-page.psml:
>
> 
>   
> dce-user-role
> view
>   
> 
> 
> 6. create new J2 profiling rule: 'dce-generic' rule:
> rule for non-logged in DCE Portal users (by default,
&

Re: How to create a custom profiling rule?

2005-01-03 Thread Marina
David,

(#if($site.rootLinks.isEmpty())
worked just fine. 
I'm not sure how to submit a patch - but if you let me
know I would be happy to do that.

As to the docsets. Yes, removing them does solve the
problem. However, I wanted to be able to have some
default .ds in the root directory for generic users
and use non-root .ds files from role-specific
directories when users login. I was hoping that my
custom profiling rule would do just that. I guess it
does not, but that's Ok, I can work around that.

Thanks for your help,
Marina


--- David Sean Taylor <[EMAIL PROTECTED]> wrote:

> 
> Marina wrote:
> >  However, there are a few problems:
> > 1. Empty ‘Additional Links’ area is shown - even
> > though there are no *.link files in the
> > pages/dce-portal/ dir
> 
> 
> If there are no links available then the collection
> should be empty
> I think what is happening is that there is a
> collection on 
> $site.rootLinks however the collection is empty
> 
> Instead of checking for null
> 
> (#if($site.rootLinks)  ). My guess (without
> 
> try
> 
> (#if($site.rootLinks.isEmpty())
> 
> if that works for you please send a patch
> 
> > 2. Empty ‘Top Pages’ area is shown 
> 
> same as above
> 
> > 3. Docsets from the ‘/’ root directory (*.ds
> files)
> > are included
> >
> 
> Recommend removing any docsets that you are not
> using
> As part of the build process for the J2 sites I work
> on, I will either
> replace the the psml directory in the spring
> configuration with a new 
> location, or just delete out all the demo psml, ds,
> etc...
> 
> 
> -- 
> David Sean Taylor
> Bluesunrise Software
> [EMAIL PROTECTED]
> [office] +01 707 773-4646
> [mobile] +01 707 529 9194
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



__ 
Do you Yahoo!? 
Jazz up your holiday email with celebrity designs. Learn more. 
http://celebrity.mail.yahoo.com

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



Re: How to create a custom profiling rule?

2004-12-31 Thread David Sean Taylor
Marina wrote:
 However, there are a few problems:
1. Empty ‘Additional Links’ area is shown - even
though there are no *.link files in the
pages/dce-portal/ dir

If there are no links available then the collection should be empty
I think what is happening is that there is a collection on 
$site.rootLinks however the collection is empty

Instead of checking for null
(#if($site.rootLinks)  ). My guess (without
try
(#if($site.rootLinks.isEmpty())
if that works for you please send a patch
2. Empty ‘Top Pages’ area is shown 
same as above
3. Docsets from the ‘/’ root directory (*.ds files)
are included
Recommend removing any docsets that you are not using
As part of the build process for the J2 sites I work on, I will either
replace the the psml directory in the spring configuration with a new 
location, or just delete out all the demo psml, ds, etc...

--
David Sean Taylor
Bluesunrise Software
[EMAIL PROTECTED]
[office] +01 707 773-4646
[mobile] +01 707 529 9194
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: How to create a custom profiling rule?

2004-12-30 Thread Randy Watler
Marina,

Using the Profiler effectively is more in my court, so let's see if I can
help here.

I think there are three subjects here that need individual attention:

1. you probably do not need to define a new profiling rule... there are some
predefined rules that you can use to achieve role-based profiling,
2. the demo site is just that and you should start with a clean
WEB-INF/pages directory only adding in what you need from the demo site, and
3. the tigris sample decorator is a good starting place, but most everyone
ends up customizing and deploying their own flavor.

So, rather than trying to figure out what you have now, I would like to know
what your objective is. I'll then tell you how I'd solve it using the M1
release version. We can then compare notes and take it from there... ok?

Randy

-Original Message-
From: Marina
To: Jetspeed Users List
Sent: 12/30/04 1:26 PM
Subject: Re: How to create a custom profiling rule?

David, 
Thanks for the clarification. I did find a way to do
role-based profiling, basically, by restricting access
to specific PSML pages by roles.

I still have a few problems I was not able to solve so
far. The main one is that I still get some elements
from the '/' directory included into my pages, even
though I explicitly specified in my profiling rule
that only elements from a specific directory should be
used. I think I made some stupid mistakes while
creating custom profiling rules...

Here is how I setup my portal's content and created a
new profiling rule using direct SQL (I don't think it
is possible to that through the Admin portlets yet):

1. create new directory for my Portal content:
pages/dce-portal
place into this directory:
dce-main-page.psml
dce-user-page.psml
folder.metadata

2. define new role, 'dce-user-role', and assign it to
the 'dce-user' user

3. define security constraints in the folder.metadata:
'guest' users can view all pages;
users with 'dce-user-role' role can view all pages

  

  guest
  view


  dce-user-role
  view



4. define security constraints in the
dce-main-page.psml:
  
  

  *
  view

  

5. define security constraints in the
dce-user-page.psml:
   

  
dce-user-role
view
  


6. create new J2 profiling rule: 'dce-generic' rule:
rule for non-logged in DCE Portal users (by default,
they are all 'guest' users)

insert into PROFILING_RULE values ('dce-generic',
'org.apache.jetspeed.profiler.rules.impl.StandardProfilingRule',
'rule for non-logged in DCE portal users')

insert into RULE_CRITERION values ('100',
'dce-generic', 0, 'hard.coded', 'page',
'/dce-portal/dce-main-page.psml', 0)

7. assign new rule to the 'guest' user 
delete from PRINCIPAL_RULE_ASSOC where principal_name
= 'guest'
insert into PRINCIPAL_RULE_ASSOC values ('guest',
'page', 'dce-generic')
insert into PRINCIPAL_RULE_ASSOC values ('guest',
'docset', 'dce-generic')

8. do the same for the 'dce-user' user

The results of all that:
in general , it worked as intended. The
pages/dce-portal/dce-main-page.psml is shown whenever
a 'guest' user accesses it. When a user logs in with a
'dce-user-role' - he also sees the second page (tab),
dce-ser-page.psml.
 However, there are a few problems:
1. Empty 'Additional Links' area is shown - even
though there are no *.link files in the
pages/dce-portal/ dir
2. Empty 'Top Pages' area is shown 
3. Docsets from the '/' root directory (*.ds files)
are included

I also tried to modify the profiling rule this way:
insert into RULE_CRITERION values ('100',
'dce-generic', 0, 'path', 'path', '/dce-portal', 0)
 but it produced the same results. 

Any idea how to avoid showing root-level elements and
empty docsets in the portal page?

I checked
decorations\layout\html\tigris\decorator-top.vm and it
seems like it does try not to show, say, 'Additional
Links' label when there are no links
(#if($site.rootLinks)  ). My guess (without
checking the actual code) would be that it is checking
the links in the '/' directory, always, and then tries
to display links from the real working directory (in
my case - there are none). 

Any insight will be greatly appreciated :-)

Marina



--- David Sean Taylor <[EMAIL PROTECTED]> wrote:

> 
> On Dec 29, 2004, at 9:25 AM, Marina wrote:
> 
> > Randy, thanks a lot for your answer!
> >
> > Do you know if there are plans to implement
> role-based
> > (and group-based) profiling in the future J2
> releases?
> > I would think that role-based profiling is very
> > critical for real application

Re: How to create a custom profiling rule?

2004-12-30 Thread Marina
David, 
Thanks for the clarification. I did find a way to do
role-based profiling, basically, by restricting access
to specific PSML pages by roles.

I still have a few problems I was not able to solve so
far. The main one is that I still get some elements
from the '/' directory included into my pages, even
though I explicitly specified in my profiling rule
that only elements from a specific directory should be
used. I think I made some stupid mistakes while
creating custom profiling rules...

Here is how I setup my portal's content and created a
new profiling rule using direct SQL (I don't think it
is possible to that through the Admin portlets yet):

1. create new directory for my Portal content:
pages/dce-portal
place into this directory:
dce-main-page.psml
dce-user-page.psml
folder.metadata

2. define new role, 'dce-user-role', and assign it to
the 'dce-user' user

3. define security constraints in the folder.metadata:
‘guest’ users can view all pages;
users with ‘dce-user-role’ role can view all pages

  

  guest
  view


  dce-user-role
  view



4. define security constraints in the
dce-main-page.psml:
  
  

  *
  view

  

5. define security constraints in the
dce-user-page.psml:
   

  
dce-user-role
view
  


6. create new J2 profiling rule: ‘dce-generic’ rule:
rule for non-logged in DCE Portal users (by default,
they are all ‘guest’ users)

insert into PROFILING_RULE values ('dce-generic',
'org.apache.jetspeed.profiler.rules.impl.StandardProfilingRule',
'rule for non-logged in DCE portal users')

insert into RULE_CRITERION values ('100',
'dce-generic', 0, 'hard.coded', 'page',
'/dce-portal/dce-main-page.psml', 0)

7. assign new rule to the 'guest' user 
delete from PRINCIPAL_RULE_ASSOC where principal_name
= 'guest'
insert into PRINCIPAL_RULE_ASSOC values ('guest',
'page', 'dce-generic')
insert into PRINCIPAL_RULE_ASSOC values ('guest',
'docset', 'dce-generic')

8. do the same for the 'dce-user' user

The results of all that:
in general , it worked as intended. The
pages/dce-portal/dce-main-page.psml is shown whenever
a 'guest' user accesses it. When a user logs in with a
'dce-user-role' - he also sees the second page (tab),
dce-ser-page.psml.
 However, there are a few problems:
1. Empty ‘Additional Links’ area is shown - even
though there are no *.link files in the
pages/dce-portal/ dir
2. Empty ‘Top Pages’ area is shown 
3. Docsets from the ‘/’ root directory (*.ds files)
are included

I also tried to modify the profiling rule this way:
insert into RULE_CRITERION values ('100',
'dce-generic', 0, 'path', 'path', '/dce-portal', 0)
 but it produced the same results. 

Any idea how to avoid showing root-level elements and
empty docsets in the portal page?

I checked
decorations\layout\html\tigris\decorator-top.vm and it
seems like it does try not to show, say, 'Additional
Links' label when there are no links
(#if($site.rootLinks)  ). My guess (without
checking the actual code) would be that it is checking
the links in the '/' directory, always, and then tries
to display links from the real working directory (in
my case - there are none). 

Any insight will be greatly appreciated :-)

Marina



--- David Sean Taylor <[EMAIL PROTECTED]> wrote:

> 
> On Dec 29, 2004, at 9:25 AM, Marina wrote:
> 
> > Randy, thanks a lot for your answer!
> >
> > Do you know if there are plans to implement
> role-based
> > (and group-based) profiling in the future J2
> releases?
> > I would think that role-based profiling is very
> > critical for real applications.
> >
> 
> You can setup the default rule to use a role-based
> algorithm, or you 
> can assigned users to use a specific role algorithm
> So its not like there isn't role-based profiling in
> the system -- its 
> pretty well supported, but not in the manner you are
> suggesting.
> 
> 
> > With the default global profiling, does it mean
> that
> > the profiling rule assigned to '*' users is used
> > UNLESS a different rule is assigned to specific
> users?
> >
> yes
> take a look at the admin profiling portlet, and the
> user admin portlet
> you can configure all profiling  (no need to edit
> the tables) via the 
> admin portlets although I admit its a bit difficult
> without any 
> documentation
> 
> > Or does  it apply to all users regardless of other
> > assignments?
> >
> > Thanks,
> > Marina
> >
> > --- Randy Watler <[EMAIL PROTECTED]> wrote:
> >
> >> Marina,
> >>
> >> David is the Profiler Master, so he is much more
> >> qualified to explain its
> >> configuration and inner workings. The source is
> in
> >> components/profiler.
> >>
> >> See comments below...
> >>
> >>>  It seems that profiling rules are assigned to
> the
> >>> users based on the user names.
> >>
> >> Yes.
> >>
> >>> At least this is what I
> >>> see in the PRINCIPAL_RULE_ASSOC table - I
> created a
> >>> new user, 'dce_admin', and assigned a 'security'
> >>> profiling rule to it, and the ("dce_admin"

Re: How to create a custom profiling rule?

2004-12-29 Thread David Sean Taylor
On Dec 29, 2004, at 9:25 AM, Marina wrote:
Randy, thanks a lot for your answer!
Do you know if there are plans to implement role-based
(and group-based) profiling in the future J2 releases?
I would think that role-based profiling is very
critical for real applications.
You can setup the default rule to use a role-based algorithm, or you 
can assigned users to use a specific role algorithm
So its not like there isn't role-based profiling in the system -- its 
pretty well supported, but not in the manner you are suggesting.


With the default global profiling, does it mean that
the profiling rule assigned to '*' users is used
UNLESS a different rule is assigned to specific users?
yes
take a look at the admin profiling portlet, and the user admin portlet
you can configure all profiling  (no need to edit the tables) via the 
admin portlets although I admit its a bit difficult without any 
documentation

Or does  it apply to all users regardless of other
assignments?
Thanks,
Marina
--- Randy Watler <[EMAIL PROTECTED]> wrote:
Marina,
David is the Profiler Master, so he is much more
qualified to explain its
configuration and inner workings. The source is in
components/profiler.
See comments below...
 It seems that profiling rules are assigned to the
users based on the user names.
Yes.
At least this is what I
see in the PRINCIPAL_RULE_ASSOC table - I created a
new user, 'dce_admin', and assigned a 'security'
profiling rule to it, and the ("dce_admin", "page",
"security") values got inserted into the
PRINCIPAL_RULE_ASSOC table.
Just FYI, the locator/rule name "security" has
special meaning in J2... you
might want to pick another name for your custom rule
to avoid confusion. The
"security" locator/rule is used when a user has an
expired password and must
select a new one. See details in the archives of the
dev list.
 Now my question: how could I assign a profiling
rule
to a rolename, not a username?
For example, I might want all users with the
'dce_admin_role'  role to use the 'security' rule.
We have discussed this, but it is not been
implemented yet. There is a
global default mechanism in place: if you specify a
PRINCIPAL_RULE_ASSOC
entry with a username of '*", it will be used for
all users. This feature
may not be implemented in this way in the future,
but there certainly will
be some other way to do the same thing.
Randy


__
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
David Sean Taylor
Bluesunrise Software
[EMAIL PROTECTED]
[office]   +01 707 773-4646
[mobile] +01 707 529 9194

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


RE: How to create a custom profiling rule?

2004-12-29 Thread Marina
Randy, thanks a lot for your answer!

Do you know if there are plans to implement role-based
(and group-based) profiling in the future J2 releases?
I would think that role-based profiling is very
critical for real applications. 

With the default global profiling, does it mean that
the profiling rule assigned to '*' users is used
UNLESS a different rule is assigned to specific users?
Or does  it apply to all users regardless of other
assignments?

Thanks,
Marina

--- Randy Watler <[EMAIL PROTECTED]> wrote:

> Marina,
> 
> David is the Profiler Master, so he is much more
> qualified to explain its
> configuration and inner workings. The source is in
> components/profiler.
> 
> See comments below... 
> 
> >  It seems that profiling rules are assigned to the
> >users based on the user names.
> 
> Yes.
> 
> > At least this is what I
> >see in the PRINCIPAL_RULE_ASSOC table - I created a
> >new user, 'dce_admin', and assigned a 'security'
> >profiling rule to it, and the ("dce_admin", "page",
> >"security") values got inserted into the
> >PRINCIPAL_RULE_ASSOC table.
> 
> Just FYI, the locator/rule name "security" has
> special meaning in J2... you
> might want to pick another name for your custom rule
> to avoid confusion. The
> "security" locator/rule is used when a user has an
> expired password and must
> select a new one. See details in the archives of the
> dev list.
>   
> >  Now my question: how could I assign a profiling
> rule
> >to a rolename, not a username? 
> >For example, I might want all users with the
> >'dce_admin_role'  role to use the 'security' rule.
> 
> We have discussed this, but it is not been
> implemented yet. There is a
> global default mechanism in place: if you specify a
> PRINCIPAL_RULE_ASSOC
> entry with a username of '*", it will be used for
> all users. This feature
> may not be implemented in this way in the future,
> but there certainly will
> be some other way to do the same thing.
> 
> Randy
> 



__ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 

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



RE: How to create a custom profiling rule?

2004-12-28 Thread Randy Watler
Marina,

David is the Profiler Master, so he is much more qualified to explain its
configuration and inner workings. The source is in components/profiler.

See comments below... 

>  It seems that profiling rules are assigned to the
>users based on the user names.

Yes.

> At least this is what I
>see in the PRINCIPAL_RULE_ASSOC table - I created a
>new user, 'dce_admin', and assigned a 'security'
>profiling rule to it, and the ("dce_admin", "page",
>"security") values got inserted into the
>PRINCIPAL_RULE_ASSOC table.

Just FYI, the locator/rule name "security" has special meaning in J2... you
might want to pick another name for your custom rule to avoid confusion. The
"security" locator/rule is used when a user has an expired password and must
select a new one. See details in the archives of the dev list.
  
>  Now my question: how could I assign a profiling rule
>to a rolename, not a username? 
>For example, I might want all users with the
>'dce_admin_role'  role to use the 'security' rule.

We have discussed this, but it is not been implemented yet. There is a
global default mechanism in place: if you specify a PRINCIPAL_RULE_ASSOC
entry with a username of '*", it will be used for all users. This feature
may not be implemented in this way in the future, but there certainly will
be some other way to do the same thing.

Randy


Re: How to create a custom profiling rule?

2004-12-28 Thread Marina
 One more related question:

  It seems that profiling rules are assigned to the
users based on the user names. At least this is what I
see in the PRINCIPAL_RULE_ASSOC table - I created a
new user, 'dce_admin', and assigned a 'security'
profiling rule to it, and the ("dce_admin", "page",
"security") values got inserted into the
PRINCIPAL_RULE_ASSOC table. So, I assumed that the
'PRINCIPAL_NAME' in this table is in fact a username.

  Now my question: how could I assign a profiling rule
to a rolename, not a username? 
For example, I might want all users with the
'dce_admin_role'  role to use the 'security' rule.

Thanks!
Marina

--- Marina <[EMAIL PROTECTED]> wrote:

> Hi!
> 
> I'm trying to create a new profiling rule for a
> user.
> From looking at the examples and the DB tables it
> seems that all I need to do is to add new entries to
> the PRINCIPAL_RULE_ASSOC and RULE_CRITERION tables.
> The first table's structure and purpose are quite
> clear. If I want to create a new 'dce_rule'(for both
> pages and docsets) for the 'dce_admin' user I think
> I
> should do the following:
> 
> insert into PRINCIPAL_RULE_ASSOC values
> ('dce_admin',
> page, 'dce_rule');
> insert into PRINCIPAL_RULE_ASSOC values
> ('dce_admin',
> docset, 'dce_rule');
> 
> Then, I need to add new rule criteria for the new
> rule
> into the RULE_CRITERION table. I looked at the
> current
> values there and I am not sure how they are used to
> define profiling rules. More specifically, I see,
> for
> example, the following entries for the 'role-group'
> rule:
> 
>   
>   11
>   role-group
>   0
>   role
>   role
>   
>   2
>   
>   
>   12
>   role-group
>   1
>   navigation
>   navigation
>   /
>   2
>   
>   
>   13
>   role-group
>   2
>   group
>   group
>   
>   2
>   
> 
> I aslo know (thanks to Randy's explanation) that the
> search paths returned by this rule are:
> /_role/rolename
> /_group/groupname
> /
> 
> However, I am not sure how and what fields from the
> RULE_CRITERION table are used to construct these
> paths. Are 'Name' or 'Value' fields used ? They are
> null's for group and role  request_type , but '/'
> for
> the navigation one. What are the 'path.session',
> 'navigation', and other REQUEST_TYPEs? And where
> does
> FALLBACK_TYPE come into play?
>  
> Basically, my question is: what is the meaning of
> the
> fields of this table and how are they used?
> 
> Thanks!
> Marina
> 
> P.S. I think I sent this e-mail to the development
> list as well - sorry about that, it was done my
> mistake
> 
> 
>   
> __ 
> Do you Yahoo!? 
> Send holiday email and support a worthy cause. Do
> good. 
> http://celebrity.mail.yahoo.com
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 





__ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

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



How to create a custom profiling rule?

2004-12-28 Thread Marina
Hi!

I'm trying to create a new profiling rule for a user.
>From looking at the examples and the DB tables it
seems that all I need to do is to add new entries to
the PRINCIPAL_RULE_ASSOC and RULE_CRITERION tables.
The first table's structure and purpose are quite
clear. If I want to create a new 'dce_rule'(for both
pages and docsets) for the 'dce_admin' user I think I
should do the following:

insert into PRINCIPAL_RULE_ASSOC values ('dce_admin',
page, 'dce_rule');
insert into PRINCIPAL_RULE_ASSOC values ('dce_admin',
docset, 'dce_rule');

Then, I need to add new rule criteria for the new rule
into the RULE_CRITERION table. I looked at the current
values there and I am not sure how they are used to
define profiling rules. More specifically, I see, for
example, the following entries for the 'role-group'
rule:


11
role-group
0
role
role

2


12
role-group
1
navigation
navigation
/
2


13
role-group
2
group
group

2


I aslo know (thanks to Randy's explanation) that the
search paths returned by this rule are:
/_role/rolename
/_group/groupname
/

However, I am not sure how and what fields from the
RULE_CRITERION table are used to construct these
paths. Are 'Name' or 'Value' fields used ? They are
null's for group and role  request_type , but '/' for
the navigation one. What are the 'path.session',
'navigation', and other REQUEST_TYPEs? And where does
FALLBACK_TYPE come into play?
 
Basically, my question is: what is the meaning of the
fields of this table and how are they used?

Thanks!
Marina

P.S. I think I sent this e-mail to the development
list as well - sorry about that, it was done my mistake



__ 
Do you Yahoo!? 
Send holiday email and support a worthy cause. Do good. 
http://celebrity.mail.yahoo.com

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