Topic: Shoutbox Ignores Permissions

[cloksin]

I have Simple POrtal 2.3.3 installed on SMF 2.0 RC3 (yes, I know, upgrade SMF... in the process, with all the mods I have that's going to require a complete rebuild then databse port, its in the process.) In the meantime, I'm having problems with permissions in Simple Portal.  I need to set permissions for my shoutbox so that everyone initially has permission to use it, but if the privilage is abused, that permission can be revoked.

In theory what I should be able to do is set the shoutbox permission to "One Membergroup" and select the membergroups I want to have permission to the shoutbox, then I would do the same for the block that the shoutbox is in.

When people join my forum they are automatically put into a membergroup called "Unclassified", after they make their first post they are automatically moved to a membergroup called "New Arrival".  After they've finished their arrival thread with a member of my staff, that member of staff moves them to a membergroup related to the department they will be in, and also adds them to a member group named "shoutbox".

I have all three of these groups selected for permissions in both the shoutbox and the block that it resides, yet when using my test member and removing that member from all groups except his primary department group, he is still able to see and post in the shoutbox.  If I change the permissions to "All Membergroups" then only admins are able to see the shoutbox.  Selecting "Ignore Permissions" defeats the purpose.  Is "One Membergroup" broken in 2.3.3?

What can I do to get this fixed.  I've had a problem with a couple of people using the shoutbox to verbally abuse my other members, banning this person works for a limited time as they keep using proxies to log in with new IP addresses and creating new characters, going after other members.

The way my site is set up I need to let new members use the shoutbox, as its a tool to get info and help on how to get started from more experienced players, and I can't block proxies because many of my members use them for various reasons (such as when using a computer in a public place such as a library and ned to circumvent the filters).

I really need to find a solution to this quickly.

Edit: Changed Topic Title and added more detail to describe the issue better 10/14/2011 3:06 PM Eastern US time

[AngelinaBelle]

With "one membergroup", then the member needs to belong to only one of those membergroups.
If you allow permission to
* Unclassified
* New Arrival
* shoutbox
Then anybody who belongs to even one of these groups will be able to see and use the shoutbox.

If you wish to restrict use of the shoutbox, you can change this list to only "shoutbox". This way, only approved users can shout.

[cloksin]

Yes, I understand that, and none of my members will ever be in more than one of those groups at a time.  The member I am testing with is in one group only, a group called "facilities".  Unclassified, New Arrival, and shoutbox are the only three groups that have permission to the shoutbox, yet this member can still see the shoutbox.

[AngelinaBelle]

What is the group ID for 'Unclassified'?

Have you made any customizations to any of your simpleportal files?

[cloksin]

"unclassified" is one of only two post based membergroups (with a post requirement of "0".  Its id is 4.  The other post based group is "new arrival", with a post requirement of "1", its id is 37.

While I have made some modifactions to some SMF php files, I have not modified any SP php files.

[ccbtimewiz]

post based membergroups are all classified under "regular members" (or whatever you renamed that)

[cloksin]

ok, but regular members is not one of the groups I gave permission to the shoutbox to, so when someone has been assigned a primary membergroup other than regular members, they should not be able to see the shoutbox unless they have been assigned to the shoutbox membergroup as an additional group.  However, I have my test member in a primary group (not regular members) and zero additional groups, so in theory this member should not be able to see the shoutbox, yet in practice he can.

[AngelinaBelle]

Anyone with 0 posts will be in "unclassified". Unclassified has permission to see the shoutbox.
Therefore, anyone who has never posted will have permission to see the shoutbox.

Is that correct?

[cloksin]

That is correct, and that is how I want it.

A new member who has just joined and not made any posts yet is in "unclassified", when they've made their first post they get reassigned out of "unclassified" into "new arrival" due to the post requirement of "1" for the "new arrival" group.  When they have completed their arrival process they get manually taken out of "new arrival" and manually reassigned to a primary group that reflects the direction their character has taken during the arrival.

These primary groups have NOT been given permission to the shoutbox, so they are also assigned to the "shoutbox" group which DOES give them permission to the shoutbox.  This is done so that if they end up abusing their shoutbox privilages I can remove them from the "shoutbox" group as a form of moderation/penalty, without affecting their primary "in character role play" group.

In theory this should allow them to continue playing unaffected while only having their shoutbox privilages revoked, but as I've said, even when they are not in the "shoutbox" group they are still able to see and use the shoutbox.

Essentially I want everyone to be able to use the shoutbox, so long as they've registered (guests shouldn't be able to use it, and that part IS working).  Removal of the shoutbox privilage from someone is only used when they break the rules.

(my shoutbox is used as an out-of-character social environment, not affecting the gameplay in any way, but I have had a few members who have used it to attack other members verbally - so to speak - and up till now my only recourse has been to issue a full ban.  I'd like to be able to just revoke the shoutbox permission without banning them.  We pride ourselves on being a site that makes it extremely difficult to get banned from, and we have a very detailed process in place for what actions will result in a ban, and many tiers of "cooling-off" periods before we finally issue a permanent ban, of which we have never issued a permanent ban in over 5 years.)

[AngelinaBelle]

I am sorry. I am completely lost.
Do you want the newly-registered members to be able to shout or not?

[cloksin]

yes

[modded matt]

I have this setup on acidmods.com, all members and guests see the shoutbox, but I can take te privlage away from specific members if needed.

I use "one permission group" when setting up the shoutbox, and I allow all groups access other than a new group I made titled "noshout" (this means that the member only needs to be in one group which has access to the shoutbox) As stated above postcount based groups will give access to the shoutbox, postcount groups on our forum have permissions inherited from regular members. In order to restrict access to the shoutbox, you must remove the troublesome member from any and all other groups, then place them in the "noshout" group.  That will effectively silence the troublesome member. YOU MUST PLACE THEM IN A GROUP THAT DOES NOT HAVE SHOUTBOX PERMISSIONS, IF THEY ARE NOT IN A GROUP, THEY DEFAULT BACK TO POSTCOUNT/REGULAR GROUPS.

It is hard to explain, and even harder to implement, but I have done it. none of my other admin team can get their head around it. I wish there would be better access control in the next version of simple portal.

Feel free to contact me at acidmods.com(modded matt) if you want my help as I am not on here much. I was here looking for info on editing specific pages. as I am making a mobile page for the forum, to only display the shoutbox in a large font whena mobile device is ditected using the movilladitect script.

[AngelinaBelle]

Clocksin,

If you use "one permission", and you allow users in the "0 post group" to post, then you are allowing everybody who has just signed up to post -- they have 0 posts, so they are in the 0 postcount group, and so they can post.
SimplePortal is doing exactly what you told it to do.

If you do not want 0 postcount members to post in the shoutbox, do not allow the 0 postcount group to shout.

[cloksin]

I DO want people in the "0" post group to be able to shout, I want to be able to take that permission away at a later time, from people who have 1 or more post.

modded matt, I understand what you're saying, but removing all the groups from someone I want to restrict shouting to won't work, it will take away all the other permissions assigned to them by those other groups, I might as well just ban them, and that is what I am trying to avoid.

Let me try to explain it again, when someone just registers they go into "unclassified", a zero post group.  these people ARE allowed to shout.  Once they've made a post one of my staff assigns them to a different group, their primary group.  Now they CANNOT shout.  In order to allow someone to shout after they've made a post they need to be placed in the "can shout" group, a secondary group.

This is not working though, they can shout even when they are ONLY assigned to a primary group, even if that group does NOT have permission to shout.

[AngelinaBelle]

Unclassified, New Arrival, and shoutbox are the only three groups that have permission to the shoutbox, yet this member can still see the shoutbox.

Earlier, you said the group New Arrival has permission to shout.
Does New Arrival have permission to shout?

[cloksin]

Yes it does, I left that group out of the last description of the issue to try and simplify the problem.  The point is, the post-based groups are only used for a brief period upon a new player's arrival.  After they are done with their first thread, the post-based groups (unclassified & New Arrival) don't play a part anymore.  After that the only way they should be able to have access to the shoutbox is to be assigned the additional group of shoutbox (or can-shout, same group, different names) 

[AngelinaBelle]

Unclassified, New Arrival, and shoutbox are the only three groups that have permission to the shoutbox, yet this member can still see the shoutbox.

* Unclassified (post count  = 0) has permission to see the shoutbox
* New Arrival (post count = 1) has permission to see the shoutbox
* shoutbox (admin-assigned group) has permission to see the shoutbox.

How many posts has the person made, who you don't want to see the shoutbox?

[cloksin]

My test person has three posts, and can still see the shoutbox and shout in it, this member is not in any of the above three groups, which are the only three groups selected to have shoutbox permission.

[AngelinaBelle]

Thanks for the clarification.  I was getting really confused.
I have not looked at this behavior.  Let me get back to you on that.

I would also like to find out if members of the higher-post-count groups are also members of every lower post-count group.

[cloksin]

Have you had time to look at this further?

Would the "deny" permissions in the new release work to solve my problem?

I like some of the features listed in the new release, but I'm not ready yet to implement it on my live site, and haven't had time to work it into a test site yet.

[AngelinaBelle]

I am hearing that allowing the lowest post-group, but denying the next one OUGHT to work, so the reason for your problem is a mystery.
I think the solution to your problem is going to come in 2.3.4. Sinan has reworked the permission system quite a bit, to make it more powerful, yet still simple.

[[SiNaN]]

Can you post a screenshot of the shoutbox edit page for that shoutbox with the permission option not collapsed?

But yeah, it should be a lot easier to do this with 2.3.4.

[cloksin]

Sorry for the late reply, life's been a bit hectic as of late.  As such, I don't have the time to try an upgrade to SP 2.3.4, and even if I did I would really like to wait until it gets out of RC stage and into a final release.

That being said, attached are the screenshots you asked for.  There are multiple images because I have a ton of membergroups on my forum because of the way we implement the forum.  With that, the images titles Shoutbox(x).png are images of the shoutbox properties.  Images titled ShoutboxBlock(x).png are images of the block that contains the shoutbox.  As you can see, there are only three membergroups checked in each one, and both are set to the "One Membergroup" option.

[cloksin]

Since I'm limited to 5 attachments per post, here are the remaining screen shots.

[[SiNaN]]

From what I see, you only have two post count based groups: Unclassified and New Arrival. Every member on your forum will belong to one of these groups, regardless of their post count and primary group. (although you may not see a clear indication of that) (if they have less than 1 post, they will be in Unclassified group and if they have more than 1 post, they will be in New Arrival group) From what I see looking at the screenshots, you have allowed both of those post count based groups for the shoutbox and block. So every member on your forum will be able to see the shoutbox and its block.

If you tell me exactly when a member should not be able to see the shoutbox, I may suggest something different.

[cloksin]

Basically what I am trying to do is create a "deny" permission.  Everyone on my forum should be able to view and use the shoutbox, but occassionally we have someone who abuses that privilage.  When that happens, I want to be able to revoke their shoutbox privilages.

Also, the shoutbox is used by newly registered members who may not have made any posts as a place to meet the other members of our community, as well as ask for help with getting started on our forum. 

Newly registered members who have not made a post are in the unclassified group.  Once they've made their first post they are moved to the new arrival group (as you correctly stated, these are both post based groups).  After they have completed their first thread they are manually added to one of the other membergroups. 

The shoutbox group was created so as to give members that have been manually added to a group permissions to the shoutbox, and when the shoutbox privilage was revoked, they could be temporarily removed from the shoutbox group, without affecting any of the other privilages afforded them by membership in any other group.

From what you are saying, I am assuming that a third post based group would need to be created without shoutbox permissions, one that members would be in after being in unclassified and new arrival.  The problem I see with that is the initial thread that when started moves them into the new arrival group, has no specific length requirement before the member is manually added to another group.  This thread could be as short as 5 posts between two members, and as long as 1000 posts between two members.

If you have another way of creating a "deny" permission I'm all ears.

[[SiNaN]]

What I still couldn't understand is, in which condition I should not be able to see the shoutbox? Which membergroups I should (exactly) have that I'm not allowed to see the shoutbox?

[cloksin]

The only membergroups that SHOULD be able to see the shoutbox are "unclassified", "new arrival", and "shoutbox".  None of the other groups should be able to see the shoutbox.

[Eliana Tamerin]

Actually, I'd recommend you simply create a No Shoutbox group, and use the Deny permissions in SP 2.3.4 RC1 (a final should be out soon if you aren't comfortable with RC versions) to block the shoutbox from those you don't want to see it.

You can do it the way you say, but since everyone is a member of at least one of your two post groups, they'll be able to see the shoutbox regardless.

[[SiNaN]]

The only membergroups that SHOULD be able to see the shoutbox are "unclassified", "new arrival", and "shoutbox".  None of the other groups should be able to see the shoutbox.

But the problem is Unclassied and New Arrival groups include all the members on your group. See, suppose that you have 4 members:

member1 - 0 posts
member2 - 1 post
member3 - 5 posts
member4 - 50 posts

Unclassified group minimum post count - 0
New arrival group minimum post count - 1

Members in Unclassified group: member1
Members in New Arrival group: member2, member3, member4

Basically, every member on the forum must belong to a post based member group. So all your members belong to either Unclassified or New Arrival group. So all the members on your forum will be able to see the shoutbox. Even if they have a primary group set, they'll still belong a to a post count based group according to their post count.

There should be a certain criteria that decides when a member should not see the shoutbox. And I still don't see what it is in your case.

[cloksin]

Actually, I'd recommend you simply create a No Shoutbox group, and use the Deny permissions in SP 2.3.4 RC1 (a final should be out soon if you aren't comfortable with RC versions) to block the shoutbox from those you don't want to see it.

You can do it the way you say, but since everyone is a member of at least one of your two post groups, they'll be able to see the shoutbox regardless.

That would be an ideal solution, but I've had this problem for much longer than 2.3.4 RC1 has been public, and there still isn't a definitive timeline for when the final will be released.  Until that happens I'd like to find a solution for 2.3.3.

There should be a certain criteria that decides when a member should not see the shoutbox. And I still don't see what it is in your case.

The criteria that determines when a member should NOT see the shoutbox is an abuse of the privilage, as determined by my moderators.  As Eliana stated, an ideal solution would be to have a "no shoutbox" group with "deny" permissions that can be added to the member when the moderators have decided that their shoutbox privilage should be revoked, but this is not an option in 2.3.3.  So what I have attempted to do is give shoutbox permissions to only a select couple of membergroups, which are assigned to all members, and if the shoutbox privilage is determined to necessitate a revocation, then that group would be removed from the member in question.

Unfortunately, since the way my forum works, it is necessary to have the two post based membergroups setup as they are.

Is it possible to automatically assign someone to a non-post based membergroup upon registration, while at the same time utilizing the two post based membergroups as their primary groups?

My thinking is this, upon registration a new member automatically becomes a member of the "unclassified" group as their primary group, and the "shoutbox" group as an additional group.  When they make their first post they move from "unclassified" to "new arrival" as primary, and remain in the "shoutbox" group as an additional group.  I would then remove the two post based groups from the shoutbox and shoutbox block permissions, leaving only one membergroup with permission to see the shoutbox, the "shoutbox" group.  In doing so, this would eliminate the problem of post based groups having permissions for the shoutbox, in which case I could then remove the "shoutbox" group from a member who has lost their privilage to use the shoutbox.

Because of the number of members and new registrants on my forum, it would be preferable if this could be done automatically.  If not, then I could institute a new policy on my forum for my admins that they would need to monitor all new registrants, leave shoutbox permissions for the "unclassified" group and the "shoutbox" group, but remove it from the "new arrival" group.  My admins would then have to be diligent to assign all new members to the "shoutbox" group so that when the new members make their first post and are removed from "unclassified" and moved into "new arrival" they will still have access to the shoutbox due to the "shoutbox" group.

This would add a lot of work to my admins, but I believe would be doable if an automatic solution is not possible.

[Eliana Tamerin]

There's this: http://custom.simplemachines.org/mods/index.php?mod=1804

Depending on the depth of code changes, I would imagine it would still work with SMF 2 RC5 or even 2.0.1.

Otherwise, as I said, 2.3.4 final should be out soon. You might be better off waiting a bit for that than implementing a workaround solution like this.

[[SiNaN]]

I'm pretty sure you can do whatever you want with the new permission system in 2.3.4 and as Eliana said, it'll be released very soon. I would suggest waiting too.