[sv1cec]

Originally Posted by Zero Tolerance

If anyone has more usergroup permission idea's they would like to have functional within the system then please reply saying so

- Zero Tolerance

Since I first saw this hack, I keep thinking that you should have used a separate table for the rooms.

Anyhow, what I like to see, as far as usergroups are concerned, is the ability for the admin, to define, which usergroups are allowed in a room. The password is an entrance restriction, but it has to be distributed to, say, the mods, to allow them to access a certain "Staff only" room. Not very convenient. If we could define "Allowed Usergroups" when a window is created, it would be much more convenient. The fact that we are working inside vB, with the usergroups being a standard feature, allows you to do tricks that non-vB chat systems cannot even imagine.

One issue I am facing with the way rooms are handled (as serialized fields, inside a column), is that I can't use a dedicated index number for the permanent rooms. A situation I can forsee, is this:

There is a permanent room, which is used to discuss staff-only issues which has the room number 4. Above that, there are only temporary rooms, which are deleted when no longer used. At some time, the admin decides to remove the staff-only room, and then a temp room is created. This gets room number 4 again. If the admin hasn't remember to prune the contents of room 4 before deleting it, then simple members who use the new room 4, will be able to see the last contents of the old room 4, which was a staff-only room. NOT GOOD. An Auto-increment field could solve this issue, as well, as the precaution to automatically prune the contents of 'store' when a room is erased.

One suggestion: when someone changes rooms in chat, you could take him directly in the room he selected to join instead of letting him stay in the "Change Room" screen. No point to let him stay there. Oh if you do apply this change, you have to remove the "User Joined room" from the bottom if the change room routine, if you do not the program will show two such messages, one from the change room routine, one from the main routine.

Another thing I would like to see, is the ability to create rooms from the AdminCP. Especially, the permanent rooms. Again, this is a convenience-only issue.

Another issue, something for you to consider. As I said, I am using the non-permanent rooms, as a ... well, non-permanent. When the last user of a non-permanent room logs out, the room is erased. If all users decide to "change" rooms, then the room remains (even though I could implement the same logic to erase it, even when they change rooms) and is erased (I hope) by the cron job. This reduces clatter, and makes admin life easier.

The behaviour of the non-permanent groups, could be adjustable from AdminCP.

Finally, a management issue. Would it be too much for you to release any future enhancements in the form of a change log, so that people who have customized this lovely hack, don't have to redo everything from scratch? I have practically changed every single item in this hack, templates and files, so this would be a great convenience for me.

I have to agree with the rest of the people's comments here. Your hacks are the greatest I've seen (immitation is the most sincere form of flattery, see my AWS). And given your age, I know for sure I have a lot of patching to do in my board, I am sure you will come up with many more nice additions for us. Congrats mate.