Re: [Phpslash-devel] Notes on users and groups in PSL0.7

[Joe S. <joe...@us...>]

On Sat, Feb 22, 2003 at 03:43:50PM +0000, Peter Cruickshank wrote:
> Hi
> 
> Thought it would be worth posting some notes/queries from my experience with using the new users & groups (which I really like, now I'm beginning to get my head round the approach).
>

Yeah it was hard to explain so I implemented the code to get more input 
and testing.
 
> - As far as I can see, groups can only contain permissions and groups that only contain permissions. ie They are not fully recursive
> 

Probably true.  The perm class "have_perm" function should be recursive I 
believe.  The implementation in phpslash to gather the permissions and 
groups from sql into an array is not.  It was kind of a bear to have 
freedom and flexibility and still reduce the possibility of circular 
references.  Which I believe you can still have if you try.

The perm class also allows for permissions outside of the groups too.  In 
other words the user can have a set of permissions assigned instead of 
groups.  The interface in phpSlash would be pretty cluttered though if you had a choice 
of permssions as well as groups.  It could be done but is not as clean of 
interface.

> - Why is user 'nobody' given uid of '20'? In several places, the code expects a uid of 'nobody'
> 

That needs to be cleaned up and has been on my mind too.  Some places have 
a lookup like:

	$aid = Author::getId($uid);

where uid is "nobody".

What happens is that phplib's "nobody" uid gets identified and changed to 
phpslash's 'nobody' user.  Which has been hardcoded and should be queried 
instead.  This is done to allow or remove permissions to anonymous users 
such as the ability to comment without logging in or choose the name used 
to post comments.

> - Groups 20 (nobody) and 21 (user) are hardcoded. Maybe they should be replaced by constants (eg PSL_AUTHOR_NOBODY, PSL_AUTHOR_USER) or settings in config.ini.php?
> 

Or make the constants 'nobody' and 'user'.

> - is there a note anywhere on what the groups are for? As far as I can work out, the key ones are
>   - root (obviously)
>   - user (required by user-only blocks etc) - or should PublicUserAccount be used? PublicUserAccount contains 'user' and 'nobody' which is confusing.
>   - nobody
>   The module-specific groups seem pretty self-explanatory.
> 

Only the short description in the Author and Groups documentation so far.

nobody is the as yet logged out user.  You can assign or take away a few 
permissions from the 'nobody' group.  PublicUserAccount was a test and I 
guess could be deleted or used when registering instead of the two above.

user is checked for login status.  Any logged in user probably should have 
this group/permission.  

> - This group seems to be empty or not used: siteeditor
>

Looks to be true.
 
> I dont think there's any show-stoppers here though.
> 

good deal.

thanks,

Joe

> Peter
> 
>