This will be a complete explanation on what I believe should have been a standard feature of TS3 since the beginning. While most of the actions described within the following wall of text can be performed to specification already, certain changes would be appreciated.

Teamspeak server with four Channels, including the Lobby, named:

  • Channel A
  • Channel B
  • Channel C

5 Users:

  • Alice
  • Bob
  • Sue
  • Debra
  • Charlie

These are the Channel Groups:

  • Channel Admin
  • Operator (OP or Oper)
  • Voice
  • Guest

For the purposes of the following examples, assume that Alice is a Server Admin, Bob is Channel Admin of Channel A, Sue is Channel Admin of Channel B, Debra and Charlie are just guests. Bob, Sue, Debra, and Charlie are Server Group Guests. No one excepting the SA has permissions in Channel C.

These are the Channels that each user is residing in:

  • Lobby
    • Alice
    • Bob
  • Channel A
    • Charlie
  • Channel B
    • Sue
    • Debra
  • Channel C

Now, onward with the Scenarios and explanations.

Quote Originally Posted by Scenario 1
Alice and Bob are discussing making Charlie the Lonesome Cougar in Channel A an Operator of Channel A because he is always in that channel for whatever reason. They come to a decision and Bob wishes to add Charlie to the operator group in Channel A. For Charlie to execute this action, He has to leave the Lobby, Join Channel A, Assign Bob as an operator, and then Join the lobby again to keep chatting with Alice.
What is wrong with this picture? Simple really. Bob has to join Channel A to be able to utilize his Channel Admin Permissions and affect users in Channel A. I would say I can't believe that I have to even bring this up as a suggestion for TeamSpeak 3, but Here I am.

Why on earth does Bob have to leave the Lobby to work his VooDoo In Channel A? Simple. A patch administered by the TeamSpeak Devs more than a year ago affected this change. As such, threads like these(clicky) began popping up all over the place.

Let us refresh why this patch was put into place. Let us return to the hypothetical server that was setup.

Quote Originally Posted by Scenario 2
Sue and Debra are in Channel B chatting. They decide to play a prank on Charlie. Sue proceeds to use her Channel Admin Powers to kick bob from Channel A. Now, Charlie moves to Channel C after being Kicked from Channel A into the lobby. Sue and Debra giggling like the girls they are, proceed to pull the same prank on Charlie again.
What is wrong with the above? Sue is able to use her Channel Admin powers server wide on other channels she is not an admin of! Recall from the setup that Sue is only a Channel Admin in Channel B. Not Channel A or C. Now the TeamSpeak 3 Devs responded wonderfully to this situation and patched. But in my honest opinion, they patched it wrong.

Instead of checking to see if Sue has the ability to use her admin powers in a certain channel (context), they simply ensure that she isn't even assigned the powers period, unless she is in the channel.

Congratulations! Problem solved! Time to go home!


Yes, As a quick fix patch this completely solved the problems the TS server was facing. Charlie, being the introvert he is, can no longer be pranked by Sue and Debra. Alice also no longer has to run around like a chicken with its head cut off trying to fix problems created by Sue.

What should we really be seeing here? Why context of course. Context is the basis of any GUI. When I right click on a File, I expect to see information in relation to that File. When I right click on a window, I do not want to see information relating to a file.

The same applies here. When Sue is in Channel B, she should not have the ability to affect other channels with her Channel Admin powers, like kicking Charlie from Channel A or Channel C. This of course was fixed, but in a quick fix way. However, If Sue were to move out of Channel B into Channel C, she should still be able to kick Debra from Channel B if she so choose. The same goes for Bob in the Lobby in Reference to Scenario 1. Bob should be able to add Charlie to the Operator group in Channel A, without having to leave the Lobby.

So this is basically the flow of what should occur when a user attempts to execute an action in a certain channel:

Quote Originally Posted by Flow
  1. Is the user in a Server Group that allows the action? If yes, Skip to step 4.
  2. Is the user in a channel group for that channel, that allows that action? If yes skip to step 4.
  3. Does the user have a client permission, to execute that action in that channel? If yes skip to 4. If no, Skip to step 5.
  4. Execute the given action. Skip step 5.
  5. Do not execute the given action.
If this flow of execution is run properly, the following scenario would be possible, and you would no longer have threads like referenced above pop up.

Quote Originally Posted by Scenario 3
Alice and Bob have concluded that Charlie needs OP in Channel A. Bob, from the Lobby, Right clicks on Charlie in Channel A, and Assigns Charlie to OP in Channel A. It goes through because that is the channel where Charlie is residing, and that is also where bob has Channel Admin Permissions.

Now, Bob wants to give Debra Voice in Channel A. Now, unless he executes some ServerQuery Voodoo, this will not be possible because Debra is currently residing in Channel B with Sue. If however Debra were to move into Channel A, or Bob uses Server query, then it would be possible.

Sue wants to play a prank on bob in Channel A. However, since she is only Channel Admin in Channel B, she can not kick bob from Channel A. However, if Sue were to leave Channel B for Channel C, she would still be able to kick Debra from Channel B, because that is where Debra is currently residing, and Sue is Channel Admin of Channel B.
I hope the above examples illustrate what I am trying to say here. If not, I guess I'm SOL. If the above system were to be finally implemented, The option to "Ignore Channel passwords" for Channel Groups would be able to be used since permissions checking will be done outside of a channel for various actions, as it should be.

I'd like to thank the Devs for TS3. It is a great product. It just needs some polish, some more fine grained permissions and a little more love. I use TeamSpeak 3 because It is an excellent product and I have always preferred TS over Ventrilo or other voice software. However, TS3 has yet to achieve a matured state and this change would be an excellent addition to an already great product.

Now, while I would be severely disappointed if this doesn't make it into TS3, It wouldn't change whether I wanted to use the product or not. And again, most of the functionality already exists. It just isn't context sensitive enough. That's all I'm asking for here, is context sensitivity.

Now that your eyes are bleeding from this wall of text, does anyone of any questions, comments, or concerns about what I have presented?