Re: [Phpwebsite-developers] Banning of users

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

Thanks for the response Shaun,

> I was hoping there would be a 'guest only' group so that I could put 
> blocks on the page that only non-registered users could see so that I 
> could put adverts on the page if they weren't registered and the 
> adverts would disappear if they registered.

I hadn't thought of that however it shouldn't be too hard to do that:

if (!Current_User::isRegistered()) {
  bombardWithAds();
} else {
  showEmJustTheGoodStuff();
}

So then in your item form:

() Allow everyone to see this
() ONLY allow unregistered to see this
() Only let registered see this
() Only let registered groups I pick see this

0, 1, 2, 3. You decide how to tag the item. Then the permissioning
system will help you with the rest.

Since this is a good test, I will implement this in blocks. I could
definitely see this need in that module.


> So the admin interface is ...
> 
> ( ) Everybody
> ( ) Registered users
> ( ) Specified group of users
>      [Pick group(s)]

Yes. The group interface is supplied by the Users module. You create the
radio list.

> That's better than I thought but still more complicated than it needs 
> to be IMHO and I'd still like to see a 'Guest Only' level.

Then you can make a Guest Only level (see above)


> I didn't understand the above at all but I'll proceed nonetheless ;-)

Hehe :) It is complicated and I am a poor writer. Let me try and give
some examples:

Steven comes to the site for the first time - he is an unregistered user
Matt comes to the site and logs in - he is a registered user

Shaun is member of the writing team (a registered user). Matt is the
editor. They both have permissions in the Article module.

Matt can create, edit, and delete any and every article in the module. -
He has unrestricted Article module permissions.

Shaun's submissions must be approved and he can only access articles
assigned to (or created by) him. - He has restricted permissions.

Shaun has permission to create and edit but not delete. If he did have
delete permission, he could only delete the items assigned to him
because he is a restricted user.

Shaun creates an article. Since he is restricted, it goes into the
approval queue.

Matt is unrestricted, therefore in this module he can approve and edit
Shaun's article.

Matt writes an article and posts it. Matt gives Shaun's group permission
to edit his article. Shaun can edit the article BUT the edits have to be
approved by an unrestricted person so they don't go live until someone
does so.

Yes it is complicated but item permissions do this. 

> So, from a module developers point of view, all they do is ask the 
> permission system if it's authorised content, the permission system 
> checks if there is specific item info, failing that goes with the group 
> permissions.

The module developer checks the general permissions (guest, registered,
permitted, deity) they have set for the item. They then ask the users
module if the current user fits those criteria. Is this a guest? Have
they logged in? Were they assigned the permission to alter or view this
item?

>  From an admins point of view they see a box with a list of groups, some 
> of which are real, some are predefined psuedo-groups. If they choose a 
> group an item specific entry is set, if not the system picks the module 
> defaults.

You would have to store each items permission on the pseudo groups.
Still seems simpler to just check their log in status instead of
creating another system requiring extra db space to do the same thing.

>From a logistics view, the group box is a multiple select box. You can
assign more than one group to an item. If the pseudo groups were
included, this could cause problems (user picks 'everyone' and another
group to view). I think the radio button solution still works best in
this situation.


> See above. I don't think we need a second table unless there are item 
> specific permissions just as fatcat doesn't have categories for 
> everything but has the psuedo-category of 'uncategorized'.

Look at the programming for how this is done. The faq module for example
pulls the data, finds out what is NOT in a category, and lists it as
uncategorized. This is, in my eyes, inefficient (not the fault of
Darren, more my fault for how I programmed the Fatcat). What I am having
to do in the new category module is actually have 0 as the id of the
category 'Uncategorized'. This way I can pull only those items from the
database. It creates more data but ultimately is more efficient.

For permissions however, it was far more efficient to just not have
these 0 or -1 ids.


> Hope so. I just wasn't sure you'd not missed something.

I hope I haven't either but (so far) I haven't run into an unsolvable
situation.

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