Re: [Phpwebsite-developers] Banning of users

[Shaun M. <sh...@ae...>]

On 23 Feb 2005, at 15:55, Matthew McNaney wrote:

>> 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.


Not the same. What works currently is that you can set blog entries as 
being BOTH registered and guest so that registered users see their 
stuff AND also they get guest stuff.

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.

>
>>  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.
>

So the admin interface is ...

( ) Everybody
( ) Registered users
( ) Specified group of users
     [Pick group(s)]

??

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.



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

OK, I misunderstood what you meant originally.


>
>> 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.
>

OK, I never thought they'd be actual users or groups, more a psuedo 
group that appears in the interface just as if it was an actual user 
group.


> 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.

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

I was guessing it would work on the basis of the permission system 
looking up the default permissions for the module as set in the user 
control panel interface for the group the user was in and using those 
if it found no specific settings for the item. That's why I was 
simplifying guests and registered users as a pseudo group so that 
setting permissions for guests was as simple as it is now for groups. 
That way, you could dissallow viewing all content in a module from 
guests.

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.

 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.

>
> 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.
>

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'.


> 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.
>

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


Shaun
aegis design - http://www.aegisdesign.co.uk