[Suggestion] Remote Channel Administration by Channel Group Users

[sniperfodder]

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.

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.

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!

Wrong.

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:

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.

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?

[dante696]

It's hard to get, your how to with all this "girls a giggling etc"

You have to know, what happens in the background of our permissions system including the client ui.
A Quickfix is not possible at all. The whole permission system would need an overhaul.

We will discuss about your feedback, but the soloutoin is not that easy.

Scenario 1
The client just don't knows if he is allowed to assign a group.
The gui stays greyed -out as long the current group or channel tells him, that he has no i_group_member_add_power.

Scenario 2
We canot follow you. The client can kick the user from target channel, when he owns kick power.

Scenario 3
ServerQuery Voodoo?

Just assign the permission b_virtualserver_channelgroup_client_list to your Channel Admin and he can add his members per client ui. Over Permisssions > Channel Groups > Clients in Channel Group


Ignore Channel passwords
The thread, you have send here explained already, that it is not possible.

[sniperfodder]

You know what, Never mind. The problem I was thinking of was already fixed. It must have been fixed way after I originally posted in that one thread.

But this? This right here ↓ should be possible now.

Ignore Channel passwords
I don't want to repeat myserlf! This is not possible and will never be fixed.

↑ Is completely, and UTTERLY POSSIBLE. Furthermore, you say 'fixed' implying that it is a bug, that you are refusing to fix. I can not fathom why you would not implement it, since the mechanics needed for it to work are in place already in the server code.

I accept the rejection of this suggestion based upon self testing I recently completed on a hunch.

I however, can not, and will not, accept a rejection of the above feature, because you don't want to implement it properly. The above feature wasn't even the intended content of this suggestion post. It would merely have been a side feature that would have had an easy way of being implemented after the suggested changes.

I'm going to rephrase what I originally had said so you can understand the differences I'm pointing out about the side feature of ignoring channel passwords, and what I was asking originally.

Remember, the following is a paraphrase of what I wanted before I had done testing to see if it would actually work.

---------------------------------------------------------------------------------------------

Bob is channel admin of a Channel A. He is currently sitting inside of the lobby. He doesn't like Charlie sitting in Channel A. He kicks Charlie, from Channel A, without leaving the Lobby. Bob is not a channel admin of Lobby.

This is currently not possible. It should be possible. That is why I'm suggesting it as a feature.


Bug Report Format:

What steps will reproduce the problem?

1. Join a TeamSpeak server.
2. Be made Channel Admin of a single channel. Ensure that is the only server or channel group, or client permissions you have.
3. Join a different channel.
4. Try to kick/ban or do whatever a channel admin can do, to a user in the channel you were made channel admin of, from a different channel.

What is the expected output? What do you see instead?

I expect to be able to use my Channel Admin Powers on the Channel I am a Channel Admin of, from a different channel.

Instead, I am not even given the options.

What version of the product are you using?

The latest client and server.

Do you have an error log of what happened?

No. There was no error. This is a feature request.

Please provide any additional information below.

The way permissions are currently checked does not allow a channel admin to act upon a channel he is admin of from a different channel. This was intentionally done when doing permissions checking for an unknown reason.

Reason dictates that a user should be able to affect a channel he his channel admin of from whatever channel he is in, while on the server. This is not the case.

------------------------------------------------------------------------------------------

Do you understand what I am now trying to say? I've already verified that the above works after testing it.

Which means you do permissions checking properly for actions against a user in a channel, when the user performing the action has rights, but is not in the actual channel itself.

Furthermore we can conclude, that a Channel Admin can ignore his own channels password because permissions have been loaded and checked correctly before the Channel Admin even attempts to join the channel. The only reason why it is not possible is because the dev team refuses to implement it.

This means that there are a whole host of other features that can also be implemented but have not. I'm not going to go into details here because I'm way too tired to continue on with this post, especially since you couldn't even grasp the basics of what I was trying to say the first time around.

[dante696]

I'ts definitly no bug
Sure he can kick Charlie out of Channel A, because Bob is CA in that channel.
The user "Bob" is allowed to kick her out of channel A and this will be compared from the server and his kick power and her needed kick power.
His kick power is given in target "Channel A".

This has nothing to do with the lobby. The lobby stands for the place, where she gets kicked automatically.

The same thing happens with Kick/Ban from Server. You could allow your channel group to do Ban or kick from the server and there are able to do that in their target channel as long they own that group.

[MathK1ll]

The thing with the "b_channel_join_ignore_password" bug is that, in my situation at least, I have a channel group that is special and only myself and one other person is able to assign that group on a channel - and we only assign it on the one channel I allow it. The said channel has a private sub-channel that is passworded, however, it's intended for this group. I wanted to assign "b_channel_join_ignore_password" to that group so the few people who were in that group could jump down into the private channel to escape the insane people on the rest of my server. I thought, "no problem - this SHOULD cascade permissions down since they have inherited channel power already." But I'm left with a grayed out permission nonetheless.

Also, I don't want to use a Server Group because I don't want them to have global power over users not in the channel they have.

[sniperfodder]

I'ts definitly no bug
Sure he can kick Charlie out of Channel A, because Bob is CA in that channel.
The user "Bob" is allowed to kick her out of channel A and this will be compared from the server and his kick power and her needed kick power.
His kick power is given in target "Channel A".

Exactly. Originally this wasn't possible, but Like I said it was "fixed" later after I had originally done the testing. I haven't had a chance to test it since then until this morning when attempting to reply to your post.

This has nothing to do with the lobby. The lobby stands for the place, where she gets kicked automatically.

The same thing happens with Kick/Ban from Server. You could allow your channel group to do Ban or kick from the server and there are able to do that in their target channel as long they own that group.

You obsession over tiny little things like my constant use of the lobby as the example channel proves you can't move beyond details to grasp what I've been trying to say. Honestly, I'm never ever going to attempt feature suggestion (or bug reporting) again to this development team when you have members that can not grasp what I have been trying to say sufficiently.

With the amount of threads I saw with a recent time stamp in the suggestion forum, I feel sorry for all the users trying to make their point on a daily basis.

The thing with the "b_channel_join_ignore_password" bug is that, in my situation at least, I have a channel group that is special and only myself and one other person is able to assign that group on a channel - and we only assign it on the one channel I allow it. The said channel has a private sub-channel that is passworded, however, it's intended for this group. I wanted to assign "b_channel_join_ignore_password" to that group so the few people who were in that group could jump down into the private channel to escape the insane people on the rest of my server. I thought, "no problem - this SHOULD cascade permissions down since they have inherited channel power already." But I'm left with a grayed out permission nonetheless.

Also, I don't want to use a Server Group because I don't want them to have global power over users not in the channel they have.

All discussion on this point is moot. TS3 Devs are standing by their decision to not implement what is clearly a wanted feature.

I've wasted too much time on this thread already, time that I could spend on projects that need finishing. I should have done some testing to see if they had fixed the problem before I even posted. This thread was never meant to be another TS3 Dev bashing session on their refusal to implement ignore channel password for channel groups.

Dante, If you would, please lock this thread. Further discussion is irrelevant to the original topic.