Re: [Phpwebsite-developers] Banning of users

[Matthew M. <ma...@tu...>]

> For instance, you might want to make some blog entries readable 
> for guests and some for registered users only.

Entries readable by anybody would be marked as "Anyone". Entries
readable for registered users are marked as "Registered only". What you
are suggesting already works.

>  Also if you had a level 
> of user above registered, how do you specify that they can read the 
> special articles for them only, without also opening them up to normal 
> registered users? eg. for paid content.

You set the entry with the third permission option, then choose the
group that is allowed to view it.

>  I really think it should be 
> item based permissions not module level.

It is.

> Couldn't it be at a more core level like the level fatcat is at with a 
> similar kind of interface so that you could pick a permission level 
> from predefined groups?

Should work like that.
1) Make a group with viewing permissions for your module. Give them
restricted viewing access (ie they can only view specific items)
2) put the people you want to be able to view something in that group
3) make the entry
4) assign it to registered users with permission (the third option)
5) pick the group you want to view the entry.

The above group would be able to view 1) entries set to anyone, 2)
entries set to registered users, and 3) the entry you designated as
readable by ONLY them. Anyone NOT in this group would not be able to see
the entry.

>  That was my reasoning behind the dropdown with 
> a list of groups on any module's edit interface or even on say a block 
> in layout mode.

The CVS version of blog 1.x has this coded. I haven't put it in block
yet. I was going to post some screen shots but 1.x is busted right now
:(

As for the module developer having to keep track of permissions, they
only have to keep track of viewing rights. Even then, checking is
simple.

// access_code is 0,1,2
// 0 = everyone , 1 = registered only, 2 = certain registered users

switch ($entry->access_code){

case 1:
if (!Current_User::isRegistered())
	return;
break;

case 2:
if (!Current_User::authorized('blog', 'view', $entry_id))
	return;
break;
}

Layout::add($entry->get());
--------------------------------------------------------------------
If I made the permission system handle viewing permissions, I would have
to:

1) create a default anonymous user
I was going to do this. But why? We know who this is. It's a user that
isn't logged in.

2) create a default registered user
Again, why? We know who this it as well. It is someone that it logged
in.

3) store view information on every item
We can't give the default anonymous or registered user unrestricted view
permissions.

An unrestricted group or user is permitted to edit, delete, etc. any
item in the module. They are still confined to the permissions given to
them however (just like the current system).

A restricted group or user has permissions assigned to them as well, but
they can ONLY use them on items assigned by an unrestricted user.

So, we do not want to give a group unrestricted view permissions. They
would be able to view every item in the module. So we have to give them
restricted view permissions so they could only view specific items.

Herein lies the problem. Since they are restricted, they can only access
items assigned to them. Thus, we would have to assign view permissions
to every group and user we wanted to see an item. This is bloated and
unnecessary in my opinion. Permissions work best when exclusive not
inclusive.

Yes, I know it works in unix, but this ain't unix.

4) create a special table duplicating the system above
So every item would have a duplicate table that just stored the viewing
access codes. Why? Sure it may be more convenient but all I ask is to
store the information WITH the item table itself. I don't think it is
too much to ask. Each item table already has a sequence table and (if
they are using it) a version table. I think another is too much for too
little benefit.

This is a long winded explanation but let me just conclude by saying:
you should be able to control group and user permissions however you
wish in 1.x. Although users does 99% of the permission work, a module
developer can add the other 1% to get viewing functionality as well.


-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu