Blocks permission

[NightOwl]

I found premission isn't working right with what it's expected to be.

The reason that cause the flaw is (post-base) included and Unregistered Guests, Ungrouped Members are not included in the permission choice.

post-base rank are for everyone(I can't delete it, so every group will be related to it.), so if I block post-base, every group is unable to see the block no matter the group is given permission. So the double grouping(post-base=denied, group=allow) doesn't over-ride the post-base denying permission.

Then here comes the logical problem. There is no way I can deny viewing on Guest. Only if both Unregistered Guests and Ungrouped Members can be included in the permission range.

There is always double groupings in SMF structure. The Newbie(post-base) and Group that the user assigned. So if post-base are not blockable(if blocked = no group able to access). I think we need to have group permission over-ride post-base.
BTW, the test-box of html/php always give this:
Notice: Undefined index: t in E:\linktoSMF\TPpreview.php on line 16

[NightOwl]

Humm... all blocks here is gone now. Only 5 is available for me. That is:
content
user
stats
online
search

[Bjørn]

Back again. It was just a test of a alternative bloczone theme. But it did not work quite right. 

- after thinking some on the permission system, it does cater for guests and ungrouped members really.To include ungrouped members, just tick the first post-group, all members will usually be in that, if you have the postcount low. if not, maybe you should create one entry post-based group.

What I mean:

- members only ( all members, ungrouped too) -->
   ON: newbie
    OFF: all else

- all guests + members -->
    OFF: everything(default)

- some membergroup ( either one of the postbased, then also showing ungrouped members the block if they have a cetain amount of posts, or one or more selected membergroup) -->
    ON: your preferred groups
    OFF: all else

[Bjørn]

I forgot..if you DO set SOME permission, guests will not be in regardless.Set all to off, and guests are allowed.

Kind of opposite logic, but it makes it easier to check every block fast.

So, if all permissions are OFF, the block is shown to all. As soon as you set a tick for someone, guests see nothing.

[NightOwl]

Yes, I've use that before. But now, I have to switch the board to manual accept application so I can assign them to the proper group. Because ungroup members are not included in the permission setting. I want to made a shortcut blocks for moderators and admins to access faster to the needed page. But I can't block ungrouped members from seeing it if I keep using email activation.

The point is, Guest can be blocked from viewing, but not un-grouped members. If they need to be blocked, that is only blocking post-base group can do the job. When post-base group are blocked, that's means everyone in that group are blocked as well(so do moderators). That's why I comment this as a logical problem. You can try this by disable all groups but giving Newbie(post-base) access. This give a result of no groups are blocked, even you didn't tick on any groups.

Scenario 1
Block guest by giving permission to all groups except Newbie(post-base)
Result: This blocks everyone except admins. (because each group member also is Newbie).

Scenario 2
Block certian group but let Newbie(post-base) have access.
Result: This let every one have access, include groups i want to blocked. (Same here, the blocked group are given access by the Newbie).

This problem is cause by the double grouping of SMF default, the assigned group (non-postbase) and the post-based which are counted together. But post-base override group permission. While forum permission works the other way, group(non-postbase) will override post-base.

BTW, Guest are blocked by disable "Allow guests to browse the forum". I've tried this cause now my settings of blocks are all permitted(no tick).

[Bjørn]

Hm, I see the problem now. Its pretty obvious really.

[NightOwl]

Bloc, any progress with this fixed?

Would it simply just reverse the permission code executing sequence of postbase and groups so the group permission can override the postbase?

[Bjørn]

No, its a bit more complicated than that. the way it is stored now, is that an array contains all groups the user is in, then all blocks just rapidly check if the current blocks permissions(which groups are allowed) is inbetween users groups. if not, don't show it.

It does not distinguish between postbased and real groups at this stage. Thats is only done in tpadmin, to see which is which. So my initial view of it was to either 1) use JUST add. groups, to be sure the postbased isn't "slipping some through" 2) use ONLY postbased to be just a regular member/non-member/posts type of permission.

As pointed out , if you need accces for ungrouped members, just use the postbased(all of them, or at least the ones with high enough postcount), an NO add.groups. And to allow guests, just untick everything.

its when there are mixes between these trouble arise, because as soon you use both groups, the add.groups no longer work.Because, as also pointed out,  all members aslo have some sort of post-based group.

So I am looking at either making add.groups ticked out when using post-based and viceversa, or simply having two lists. i am not sure yet.

[NightOwl]

Well, I just wonder how the forum permission can be done with blocking post-base but letting add.group access on the same user. IMO, post-base group usage is far more casual in security needs than custom groups. I think most admins don'tl want a post-base group user access things that they shouldn't with just increasing post counts. And for smf structural design, there should be an option to choose using post-base or not. Far better than what is now post-base is hardcoded without options to disable. So I have an un-used post-base group which makes everyone a double grouping if I need to work with a custom grouping system.

It would be nice if TP can have an option to choose which group-base to use for permission checking. So the Newbie(post-base) won't affect the whole custom groups. We can't take off  the Newbie(post-base) status from a new join user or from a board owner, so the only way is to ignore it.

[Bjørn]

Yes.. I am leaning towards this as well. Its the add.membergroups thats important in this, not so the post-based.