At present, the ShoutBox configuration has an option to choose which membergroups will be able to see this block - a nice feature.
However, I'm more concerned with "who" can shout than "who" can see the box.
I'd like to put the shoutbox on the homepage available for all to see (the default) - but I don't want to give all registered users the ability to shout.
I'm very concerned about the real-time integrity of the home page (the "Recent Topics" block concerns me as well - but that is a different topic).
I might add a feature to allow only memebrgroups to shout - even if its allowed to be seen by others.
Could you use the SMF permissions system?
A restriction to SMF membergroups would be a good start.
As far as I know, it takes pro-active human intervention to add someone to a SMF membergroup - that would limit shouting to handing someone a megaphone.
The shoutbox is a great feature to a dynamic home page - but it's wide open for abuse.
Did I say it was a great feature to a dynamic home page?
I will probably add this. It can be abused yes.
And no, I won't use the permission system of SMF, rather use the same as used in blocks. It makes it easier to keep existing things if they are in TP data tables when upgrading etc. SMF can theoretically erase the permission table in a upgrade..or "clean out" things that don't shouldn't be there..anyway, better to have it outside.
That makes me sad. I very much dislike the idea of TP having a separate permissions system.
I can see what you mean about SMF clearing TP permissions - that would be a catastrophy. But could a compromise be made? Could the TP permissions be in a separate table but still managed through the admin permissions system?
I don't think so...many of the permissions will be small ones..it will be a nightmare to sort out everything if you have many articles, blocks and even module permissions in one place.
Better then to let SMF deal with the actual groups, and TP just use those for its simpler system. Its easy to get to permissions where they apply -> blocks etc.
In addition...permissions in SMF requires a separate mysql call to collect all groups that have that permission, while TP just collects one field with all group ID at the same time as getting the actual block etc. 1 call instead of 2 means a lot when its many of them for each page refresh. I could collect just all perm in one swoop and comapre to the blocks ID, but thats insufficent when maybe just half of the blocks and even less for articles - is fetched.
Hmok.
How you're doing it now is there still the option of allow and deny for blocks?
Not as the SMF interprets it, no. It will not give a warning of "not allowed" in the blocks, simply because they are just show/no show routines.
But articles and modules will have error messages, in case direct links is used for example.
Okay. I'll stop making a fuss.