Re: OG User Roles: user_access / node add / $user->roles

I created two watchdog notices: One in user_access (showing
$string and 
result: true/false) and one in the hook_user
"load" (showing roles 
returned) operation.

I logged in as user in question, went to groups, clicked on
"create 
link", got "Access denied".

One of the roles that is returned by the og modified
$user->roles gives 
this user the permission to "create link".  The
watchdog entries verify 
that for the url in question: /node/add/link?gids[]=29,  the
correct 
roles are returned in $user->roles and the correct access
in 
user_access.  Yet access is denied.

Does the following bit of information provide a clue?:

When I load the "devel" module, and give this user
access to it (through 
access control), the user does not receive "Access
denied" message when 
clicking on "create link".  If I go into access
control, and remove 
permissions for "devel" module, the user still
continues to be able to 
"create link".  However, if as admin I delete the
cache, run cron.php, 
logout and log back in as user, the "Access
denied" message returns.

It seems that if this is a cache problem, clearing the cache
doesn't 
appear to resolve it.

I really appreciate any insight.  I've been working on
cracking this for 
8 months now.  It's driving me nuts because there must be
something 
somewhere, either in user_access or node_access or some
other hook 
that's if I only knew I could correct the problem.

Thanks so much!

David Metzler wrote:

> Thinking about this maybe the problem is user_access,
not the roles  
> themselves.  Check out the user_access function in
user.module.  Note  
> that is uses a static variable caching mechanism, so it
may have  
> already determined the results of
"user_access" before you've  
> modified the roles.  (It would need to in order to
route the request  
> and check access permissions).
>
> One way to check would be to call user_access
immediately after you  
> set the roles, and see if it gives you the proper
result, (in your  
> watchdog or debug files).
>
> The bad news is that I don't really know of a good way
to solve this  
> if that's the case. I'm afraid that we need a
hook_user_access in  
> core in order to implement this.  Either that or an
added parameter  
> to force user_access to ignore the cache.
>
> Here's hoping I'm wrong .
>
> Dave
>
>
> On May 21, 2007, at 3:39 PM, Ron Parker wrote:
>
>> Thanks so much for the reply.  Here's what I tried
in hook_init:
>>
>> function og_user_roles_init ()
>> {
>>    global $user;
>>    $roles = og_user_roles_all_roles($user); // This
returns normal  
>> $user->roles and includes OG roles if any
>>    $user->roles = $roles;
>>    $displayRoles = implode(",", $roles);
>>    if ($user->uid) watchdog('og_user_roles',
'user roles = ' .  
>> $displayRoles); // Show this in log if it hits.
>> }
>>
>> Here's what I tried in hook_user:
>>
>>    // Add the group roles to $user->roles if
this is a group
>>    // This should only be effective until the next
global $user call
>>    if ($op == "load") {
>>        $roles = og_user_roles_all_roles($user); //
This returns  
>> normal $user->roles and includes OG roles if
any
>>        $user->roles = $roles;
>>    } // end $op load
>>
>> I looked at the watchdog and my own debug file, and
the correct  
>> roles are being returned each and every time.
>> My guess is that $user->roles is doing what it
should, but there is  
>> something else happening in the node/add
>> (http://www.mysite.com/
node/add/link?gids[]=29) process that  
>> doesn't depend upon $user->roles that is causing
the access denied  
>> error.
>>
>> Again, any clues would be much appreciated.
>>
>> -ron
>>
>> David Metzler wrote:
>>
>>> I've run into similar problems with using
user_load to alter   
>>> user_data.  User_load doesn't fire as often as
you might think it   
>>> does due to some caching strategies.   To prove
this, place a   
>>> drupal_set_message call in your user_load trap
and see when it   
>>> fires.  It may not be firing on the page where
you're getting the   
>>> access denied errors.
>>>
>>> To solve my problem I had to move user
alteration into the init hook.
>>>
>>> It may be that there's core bug here, but I
haven't yet tracked  it  
>>> down since the init hook solved my problem.
>>>
>>> I never did find out why user_load wasn't
firing.
>>> On May 15, 2007, at 11:56 AM, Ron Parker
wrote:
>>>
>>>> A few weeks back I floated my og user roles
module  idea on this   
>>>> list as instructed by CVS Admin.  This
module (http://drupal.org/ 

>>>> node/87679) is designed to assign roles to
OG group members that   
>>>> are specific to the groups they are in. 
The problem was that I  
>>>> had  to patch the core user.module in order
to get it to work.
>>>>
>>>> After a couple of suggestions, I decided to
formulate a proposal   
>>>> for a Drupal hook.  What I thought made the
most sense was either  
>>>> a  user_access hook or a $user->roles
hook because what I wanted  
>>>> to do  was add roles to the site wide roles
returned by $user- 
>>>> >roles.   user_access (which returns
permissions allowed  according 
>>>> to roles)  is called by node_access which
is what  determines 
>>>> access on a node/ add.
>>>>
>>>> I recently proposed a $user->roles hook
(http://drupal.org/node/ 

>>>> 143393), and someone pointed out that I
could accomplish the  same  
>>>> thing by using the existing hook_user
"load" operation.   They 
>>>> were  right.  I modified my module to add
the appropriate  roles to 
>>>> the  user object using hook_user
"load" and in testing,  it appears 
>>>> that  $user->roles now returns the OG
group as well as  the site 
>>>> wide  roles when a user is in a group.
>>>>
>>>> However, on a group node add, for example,
http://www.mysite.com/ 

>>>> node/add/link?gids[]=29, my user gets an
"Access denied" error.   
>>>> I  wrote a little debug program that writes
out the values  
>>>> returned by  my hook_user "load"
addition, and every time it's  
>>>> called it returns  the correct values.
>>>>
>>>> node_access would be the access control for
a group node add.  I   
>>>> have examined the code closely, and this is
the only code that   
>>>> would be executed on a node
"create":
>>>>
>>>>  // Can't use node_invoke(), because the
access hook takes the  
>>>> $op  parameter
>>>>  // before the $node parameter.
>>>>  $module = node_get_types('module',
$node);
>>>>  if ($module == 'node') {
>>>>    $module = 'node_content'; // Avoid
function name collisions.
>>>>  }
>>>>  $access = module_invoke($module, 'access',
$op, $node);
>>>>  if (!is_null($access)) {
>>>>    return $access;
>>>>  }
>>>>
>>>> This code would then call
"node_content_access" (hook_access for   
>>>> node), which would use
"user_access" (thus calling global $user,   
>>>> thus invoking my modification) to determine
access.
>>>>
>>>> So, I'm at a complete loss as to why I
would get an "Access  
>>>> denied"  error for a group role.  I
need some help!
>>>>
>>>> The only thing I have noticed which seems
to give me a clue is  
>>>> that  when I load the "devel"
module and give users access,  
>>>> everything  works.  But, I can't figure out
what the devel module  
>>>> is doing that  would cause this.
>>>>
>>>> Any hint, clue or anything would be
appreciated.  Thanks!
>>>>
>>>> -ron
>>>>
>>>> -- 
>>>> Ron Parker
>>>> Software Creations               http://www.scbbs.com
>>>> Self-Administration Web Site     http://saw.scbbs.com
>>>> SDSS Subscription Mgmt Service   http://sdss.scbbs.com
>>>> Central Ave Dance Ensemble       http://www.centralaved
ance.com
>>>> R & B Salsa                      http://www.randbsalsa.com
>>>>
>>>
>>>
>>> __________ NOD32 2277 (20070518) Information
__________
>>>
>>> This message was checked by NOD32 antivirus
system.
>>> http://www.eset.com
>>>
>>>
>>>
>>
>>
>> -- 
>> Ron Parker
>> Software Creations               http://www.scbbs.com
>> Self-Administration Web Site     http://saw.scbbs.com
>> SDSS Subscription Mgmt Service   http://sdss.scbbs.com
>> Central Ave Dance Ensemble       http://www.centralaved
ance.com
>> R & B Salsa                      http://www.randbsalsa.com
>>
>
>
> __________ NOD32 2285 (20070522) Information
__________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
>


-- 
Ron Parker
Software Creations               http://www.scbbs.com
Self-Administration Web Site     http://saw.scbbs.com
SDSS Subscription Mgmt Service   http://sdss.scbbs.com
Central Ave Dance Ensemble       http://www.centralaved
ance.com
R & B Salsa                      http://www.randbsalsa.com

Ron,

I have to ask.  Would this be easier for you if this patch
went in: http://drupal.org/node/
143075

Your task sounds like exactly the sort of thing that patch
would simplify.  Please correct me if I'm wrong, though.

On Tue, 22 May 2007 12:24:38 -0700, Ron Parker <sysopscbbs.com> wrote:
> I created two watchdog notices: One in user_access
(showing $string and
> result: true/false) and one in the hook_user
"load" (showing roles
> returned) operation.
> 
> I logged in as user in question, went to groups,
clicked on "create
> link", got "Access denied".
> 
> One of the roles that is returned by the og modified
$user->roles gives
> this user the permission to "create link". 
The watchdog entries verify
> that for the url in question: /node/add/link?gids[]=29,
 the correct
> roles are returned in $user->roles and the correct
access in
> user_access.  Yet access is denied.
> 
> Does the following bit of information provide a clue?:
> 
> When I load the "devel" module, and give this
user access to it (through
> access control), the user does not receive "Access
denied" message when
> clicking on "create link".  If I go into
access control, and remove
> permissions for "devel" module, the user
still continues to be able to
> "create link".  However, if as admin I delete
the cache, run cron.php,
> logout and log back in as user, the "Access
denied" message returns.
> 
> It seems that if this is a cache problem, clearing the
cache doesn't
> appear to resolve it.
> 
> I really appreciate any insight.  I've been working on
cracking this for
> 8 months now.  It's driving me nuts because there must
be something
> somewhere, either in user_access or node_access or some
other hook
> that's if I only knew I could correct the problem.
> 
> Thanks so much!
> 
> David Metzler wrote:
> 
>> Thinking about this maybe the problem is
user_access, not the roles
>> themselves.  Check out the user_access function in
user.module.  Note
>> that is uses a static variable caching mechanism,
so it may have
>> already determined the results of
"user_access" before you've
>> modified the roles.  (It would need to in order to
route the request
>> and check access permissions).
>>
>> One way to check would be to call user_access
immediately after you
>> set the roles, and see if it gives you the proper
result, (in your
>> watchdog or debug files).
>>
>> The bad news is that I don't really know of a good
way to solve this
>> if that's the case. I'm afraid that we need a
hook_user_access in
>> core in order to implement this.  Either that or an
added parameter
>> to force user_access to ignore the cache.
>>
>> Here's hoping I'm wrong .
>>
>> Dave
>>
>>
>> On May 21, 2007, at 3:39 PM, Ron Parker wrote:
>>
>>> Thanks so much for the reply.  Here's what I
tried in hook_init:
>>>
>>> function og_user_roles_init ()
>>> {
>>>    global $user;
>>>    $roles = og_user_roles_all_roles($user); //
This returns normal
>>> $user->roles and includes OG roles if any
>>>    $user->roles = $roles;
>>>    $displayRoles = implode(",",
$roles);
>>>    if ($user->uid) watchdog('og_user_roles',
'user roles = ' .
>>> $displayRoles); // Show this in log if it
hits.
>>> }
>>>
>>> Here's what I tried in hook_user:
>>>
>>>    // Add the group roles to $user->roles if
this is a group
>>>    // This should only be effective until the
next global $user call
>>>    if ($op == "load") {
>>>        $roles = og_user_roles_all_roles($user);
// This returns
>>> normal $user->roles and includes OG roles if
any
>>>        $user->roles = $roles;
>>>    } // end $op load
>>>
>>> I looked at the watchdog and my own debug file,
and the correct
>>> roles are being returned each and every time.
>>> My guess is that $user->roles is doing what
it should, but there is
>>> something else happening in the node/add
>>> (http://www.mysite.com/
node/add/link?gids[]=29) process that
>>> doesn't depend upon $user->roles that is
causing the access denied
>>> error.
>>>
>>> Again, any clues would be much appreciated.
>>>
>>> -ron
>>>
>>> David Metzler wrote:
>>>
>>>> I've run into similar problems with using
user_load to alter
>>>> user_data.  User_load doesn't fire as often
as you might think it
>>>> does due to some caching strategies.   To
prove this, place a
>>>> drupal_set_message call in your user_load
trap and see when it
>>>> fires.  It may not be firing on the page
where you're getting the
>>>> access denied errors.
>>>>
>>>> To solve my problem I had to move user
alteration into the init hook.
>>>>
>>>> It may be that there's core bug here, but I
haven't yet tracked  it
>>>> down since the init hook solved my
problem.
>>>>
>>>> I never did find out why user_load wasn't
firing.
>>>> On May 15, 2007, at 11:56 AM, Ron Parker
wrote:
>>>>
>>>>> A few weeks back I floated my og user
roles module  idea on this
>>>>> list as instructed by CVS Admin.  This
module (http://drupal.org/
>>>>> node/87679) is designed to assign roles
to OG group members that
>>>>> are specific to the groups they are in.
 The problem was that I
>>>>> had  to patch the core user.module in
order to get it to work.
>>>>>
>>>>> After a couple of suggestions, I
decided to formulate a proposal
>>>>> for a Drupal hook.  What I thought made
the most sense was either
>>>>> a  user_access hook or a
$user->roles hook because what I wanted
>>>>> to do  was add roles to the site wide
roles returned by $user-
>>>>> >roles.   user_access (which returns
permissions allowed  according
>>>>> to roles)  is called by node_access
which is what  determines
>>>>> access on a node/ add.
>>>>>
>>>>> I recently proposed a $user->roles
hook (http://drupal.org/node/
>>>>> 143393), and someone pointed out that I
could accomplish the  same
>>>>> thing by using the existing hook_user
"load" operation.   They
>>>>> were  right.  I modified my module to
add the appropriate  roles to
>>>>> the  user object using hook_user
"load" and in testing,  it appears
>>>>> that  $user->roles now returns the
OG group as well as  the site
>>>>> wide  roles when a user is in a group.
>>>>>
>>>>> However, on a group node add, for
example, http://www.mysite.com/
>>>>> node/add/link?gids[]=29, my user gets
an "Access denied" error.
>>>>> I  wrote a little debug program that
writes out the values
>>>>> returned by  my hook_user
"load" addition, and every time it's
>>>>> called it returns  the correct values.
>>>>>
>>>>> node_access would be the access control
for a group node add.  I
>>>>> have examined the code closely, and
this is the only code that
>>>>> would be executed on a node
"create":
>>>>>
>>>>>  // Can't use node_invoke(), because
the access hook takes the
>>>>> $op  parameter
>>>>>  // before the $node parameter.
>>>>>  $module = node_get_types('module',
$node);
>>>>>  if ($module == 'node') {
>>>>>    $module = 'node_content'; // Avoid
function name collisions.
>>>>>  }
>>>>>  $access = module_invoke($module,
'access', $op, $node);
>>>>>  if (!is_null($access)) {
>>>>>    return $access;
>>>>>  }
>>>>>
>>>>> This code would then call
"node_content_access" (hook_access for
>>>>> node), which would use
"user_access" (thus calling global $user,
>>>>> thus invoking my modification) to
determine access.
>>>>>
>>>>> So, I'm at a complete loss as to why I
would get an "Access
>>>>> denied"  error for a group role. 
I need some help!
>>>>>
>>>>> The only thing I have noticed which
seems to give me a clue is
>>>>> that  when I load the "devel"
module and give users access,
>>>>> everything  works.  But, I can't figure
out what the devel module
>>>>> is doing that  would cause this.
>>>>>
>>>>> Any hint, clue or anything would be
appreciated.  Thanks!
>>>>>
>>>>> -ron
>>>>>
>>>>> --
>>>>> Ron Parker
>>>>> Software Creations               http://www.scbbs.com
>>>>> Self-Administration Web Site     http://saw.scbbs.com
>>>>> SDSS Subscription Mgmt Service   http://sdss.scbbs.com
>>>>> Central Ave Dance Ensemble       http://www.centralaved
ance.com
>>>>> R & B Salsa                      http://www.randbsalsa.com
>>>>>
>>>>
>>>>
>>>> __________ NOD32 2277 (20070518)
Information __________
>>>>
>>>> This message was checked by NOD32 antivirus
system.
>>>> http://www.eset.com
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Ron Parker
>>> Software Creations               http://www.scbbs.com
>>> Self-Administration Web Site     http://saw.scbbs.com
>>> SDSS Subscription Mgmt Service   http://sdss.scbbs.com
>>> Central Ave Dance Ensemble       http://www.centralaved
ance.com
>>> R & B Salsa                      http://www.randbsalsa.com
>>>
>>
>>
>> __________ NOD32 2285 (20070522) Information
__________
>>
>> This message was checked by NOD32 antivirus
system.
>> http://www.eset.com
>>
>>
>>
> 
> 
> --
> Ron Parker
> Software Creations               http://www.scbbs.com
> Self-Administration Web Site     http://saw.scbbs.com
> SDSS Subscription Mgmt Service   http://sdss.scbbs.com
> Central Ave Dance Ensemble       http://www.centralaved
ance.com
> R & B Salsa                      http://www.randbsalsa.com

Ron,

We've been looking into similar issues here as well -- see
this topic  
http://drupal.org/node/4
9385 which sheds a little bit of light on the 
fact that user_load() isn't called early on every page view
-- Moshe 
confirmed in an email to the group a while ago:  
http://lists.drupal.org/pipermail/develop
ment/2006-February/013851.html

I never entered an issue, but this might be the time.  It
certainly 
seems logical to me to expect a fully-loaded global user
object on every 
page load.

Bill

Ron Parker wrote:
> I created two watchdog notices: One in user_access
(showing $string 
> and result: true/false) and one in the hook_user
"load" (showing roles 
> returned) operation.
>
> I logged in as user in question, went to groups,
clicked on "create 
> link", got "Access denied".
>
> One of the roles that is returned by the og modified
$user->roles 
> gives this user the permission to "create
link".  The watchdog entries 
> verify that for the url in question:
/node/add/link?gids[]=29,  the 
> correct roles are returned in $user->roles and the
correct access in 
> user_access.  Yet access is denied.
>
> Does the following bit of information provide a clue?:
>
> When I load the "devel" module, and give this
user access to it 
> (through access control), the user does not receive
"Access denied" 
> message when clicking on "create link".  If I
go into access control, 
> and remove permissions for "devel" module,
the user still continues to 
> be able to "create link".  However, if as
admin I delete the cache, 
> run cron.php, logout and log back in as user, the
"Access denied" 
> message returns.
>
> It seems that if this is a cache problem, clearing the
cache doesn't 
> appear to resolve it.
>
> I really appreciate any insight.  I've been working on
cracking this 
> for 8 months now.  It's driving me nuts because there
must be 
> something somewhere, either in user_access or
node_access or some 
> other hook that's if I only knew I could correct the
problem.
>
> Thanks so much!
>
> David Metzler wrote:
>
>> Thinking about this maybe the problem is
user_access, not the roles  
>> themselves.  Check out the user_access function in
user.module.  
>> Note  that is uses a static variable caching
mechanism, so it may 
>> have  already determined the results of
"user_access" before you've  
>> modified the roles.  (It would need to in order to
route the request  
>> and check access permissions).
>>
>> One way to check would be to call user_access
immediately after you  
>> set the roles, and see if it gives you the proper
result, (in your  
>> watchdog or debug files).
>>
>> The bad news is that I don't really know of a good
way to solve this  
>> if that's the case. I'm afraid that we need a
hook_user_access in  
>> core in order to implement this.  Either that or an
added parameter  
>> to force user_access to ignore the cache.
>>
>> Here's hoping I'm wrong .
>>
>> Dave
>>
>>
>> On May 21, 2007, at 3:39 PM, Ron Parker wrote:
>>
>>> Thanks so much for the reply.  Here's what I
tried in hook_init:
>>>
>>> function og_user_roles_init ()
>>> {
>>>    global $user;
>>>    $roles = og_user_roles_all_roles($user); //
This returns normal  
>>> $user->roles and includes OG roles if any
>>>    $user->roles = $roles;
>>>    $displayRoles = implode(",",
$roles);
>>>    if ($user->uid) watchdog('og_user_roles',
'user roles = ' .  
>>> $displayRoles); // Show this in log if it
hits.
>>> }
>>>
>>> Here's what I tried in hook_user:
>>>
>>>    // Add the group roles to $user->roles if
this is a group
>>>    // This should only be effective until the
next global $user call
>>>    if ($op == "load") {
>>>        $roles = og_user_roles_all_roles($user);
// This returns  
>>> normal $user->roles and includes OG roles if
any
>>>        $user->roles = $roles;
>>>    } // end $op load
>>>
>>> I looked at the watchdog and my own debug file,
and the correct  
>>> roles are being returned each and every time.
>>> My guess is that $user->roles is doing what
it should, but there is  
>>> something else happening in the node/add
>>> (http://www.mysite.com/
node/add/link?gids[]=29) process that  
>>> doesn't depend upon $user->roles that is
causing the access denied  
>>> error.
>>>
>>> Again, any clues would be much appreciated.
>>>
>>> -ron
>>>
>>> David Metzler wrote:
>>>
>>>> I've run into similar problems with using
user_load to alter   
>>>> user_data.  User_load doesn't fire as often
as you might think it   
>>>> does due to some caching strategies.   To
prove this, place a   
>>>> drupal_set_message call in your user_load
trap and see when it   
>>>> fires.  It may not be firing on the page
where you're getting the   
>>>> access denied errors.
>>>>
>>>> To solve my problem I had to move user
alteration into the init hook.
>>>>
>>>> It may be that there's core bug here, but I
haven't yet tracked  
>>>> it  down since the init hook solved my
problem.
>>>>
>>>> I never did find out why user_load wasn't
firing.
>>>> On May 15, 2007, at 11:56 AM, Ron Parker
wrote:
>>>>
>>>>> A few weeks back I floated my og user
roles module  idea on this   
>>>>> list as instructed by CVS Admin.  This
module (http://drupal.org/ 

>>>>> node/87679) is designed to assign roles
to OG group members that   
>>>>> are specific to the groups they are in.
 The problem was that I  
>>>>> had  to patch the core user.module in
order to get it to work.
>>>>>
>>>>> After a couple of suggestions, I
decided to formulate a proposal   
>>>>> for a Drupal hook.  What I thought made
the most sense was either  
>>>>> a  user_access hook or a
$user->roles hook because what I wanted  
>>>>> to do  was add roles to the site wide
roles returned by $user- 
>>>>> >roles.   user_access (which returns
permissions allowed  
>>>>> according to roles)  is called by
node_access which is what  
>>>>> determines access on a node/ add.
>>>>>
>>>>> I recently proposed a $user->roles
hook (http://drupal.org/node/ 

>>>>> 143393), and someone pointed out that I
could accomplish the  
>>>>> same  thing by using the existing
hook_user "load" operation.   
>>>>> They were  right.  I modified my module
to add the appropriate  
>>>>> roles to the  user object using
hook_user "load" and in testing,  
>>>>> it appears that  $user->roles now
returns the OG group as well as  
>>>>> the site wide  roles when a user is in
a group.
>>>>>
>>>>> However, on a group node add, for
example, http://www.mysite.com/  
>>>>> node/add/link?gids[]=29, my user gets
an "Access denied" error.   
>>>>> I  wrote a little debug program that
writes out the values  
>>>>> returned by  my hook_user
"load" addition, and every time it's  
>>>>> called it returns  the correct values.
>>>>>
>>>>> node_access would be the access control
for a group node add.  I   
>>>>> have examined the code closely, and
this is the only code that   
>>>>> would be executed on a node
"create":
>>>>>
>>>>>  // Can't use node_invoke(), because
the access hook takes the  
>>>>> $op  parameter
>>>>>  // before the $node parameter.
>>>>>  $module = node_get_types('module',
$node);
>>>>>  if ($module == 'node') {
>>>>>    $module = 'node_content'; // Avoid
function name collisions.
>>>>>  }
>>>>>  $access = module_invoke($module,
'access', $op, $node);
>>>>>  if (!is_null($access)) {
>>>>>    return $access;
>>>>>  }
>>>>>
>>>>> This code would then call
"node_content_access" (hook_access for   
>>>>> node), which would use
"user_access" (thus calling global $user,   
>>>>> thus invoking my modification) to
determine access.
>>>>>
>>>>> So, I'm at a complete loss as to why I
would get an "Access  
>>>>> denied"  error for a group role. 
I need some help!
>>>>>
>>>>> The only thing I have noticed which
seems to give me a clue is  
>>>>> that  when I load the "devel"
module and give users access,  
>>>>> everything  works.  But, I can't figure
out what the devel module  
>>>>> is doing that  would cause this.
>>>>>
>>>>> Any hint, clue or anything would be
appreciated.  Thanks!
>>>>>
>>>>> -ron
>>>>>
>>>>> -- 
>>>>> Ron Parker
>>>>> Software Creations               http://www.scbbs.com
>>>>> Self-Administration Web Site     http://saw.scbbs.com
>>>>> SDSS Subscription Mgmt Service   http://sdss.scbbs.com
>>>>> Central Ave Dance Ensemble       http://www.centralaved
ance.com
>>>>> R & B Salsa                      http://www.randbsalsa.com
>>>>>
>>>>
>>>>
>>>> __________ NOD32 2277 (20070518)
Information __________
>>>>
>>>> This message was checked by NOD32 antivirus
system.
>>>> http://www.eset.com
>>>>
>>>>
>>>>
>>>
>>>
>>> -- 
>>> Ron Parker
>>> Software Creations               http://www.scbbs.com
>>> Self-Administration Web Site     http://saw.scbbs.com
>>> SDSS Subscription Mgmt Service   http://sdss.scbbs.com
>>> Central Ave Dance Ensemble       http://www.centralaved
ance.com
>>> R & B Salsa                      http://www.randbsalsa.com
>>>
>>
>>
>> __________ NOD32 2285 (20070522) Information
__________
>>
>> This message was checked by NOD32 antivirus
system.
>> http://www.eset.com
>>
>>
>>
>
>


-- 
Bill Fitzgerald
http://www.funnymonkey.com

Tools for Teachers
503.897.7160