[On Todo / solved / fixed?] multiple bugs regarding permissions

[willy_sunny]

Yeah, since I'm translating the permissions, I ended up decided to play around with individual permissions and see if they work as they should, then I realized the following bugs ... fun

1. Changing the default group does not update properly.

Reproduction:

Say you have group A as your default server group and group b as your new server group.

Set group A with the permission to modify server's default group.

Now, since you are in group A (the default group), you have the ability to change to the server's default group to B. Change it, and hit ok.

You should see a notice saying "successfully changed server settings".

Now, take a look at your own group without re-logging.

You should still see that you are in group A. Thus, you think you can change the default group again, so you ended up trying to change the default group from B back to A, and at this point, you'll realized that you do not have this power anymore, as if you are in group B!

So I'm assuming when you are changing default groups, all the group member that belongs to this group is not refreshed, and in fact that they have already been switched to the new group (bug!)

2. Client info view does not block the user to be able to view connection info.

As stated. If this permission is removed, the client is still able to view other's connection info as if they "bypass" this permission.

3. b_channel_group_inheritance_end should be set on "sub-channels"

In the permission description, it stated that:

If this permission is set to a channel, sub-channels will not inherit any permissions or channel group memberships from their parent.

Where in fact, according to the description, if you have this permission set on "Channel 1", with a user having the "voiced" permission, and when this user joined "Channel 1-1", which is a sub channel of "Channel 1", this user would still have "voiced" permission with it. However, it does remove this permission if b_channel_group_inheritance_end was set on the sub-channel

4. Sub Channel Creation bug

As we've all known, to create a channel, one must have at least one of these permissions

- b_channel_create_permanent
- b_channel_create_semi_permanent
- b_channel_create_temporary

and at least one of the following

- b_channel_create_modify_with_codec_speex8
- b_channel_create_modify_with_codec_speex16
- b_channel_create_modify_with_codec_speex32
- b_channel_create_modify_with_codec_celtmono48

or else a channel will not be able to be created. Thus, the devs disables the creation of the channel if either of the 2 requirements are missing.

However, when creating sub channels, it only checks if b_channel_create_child is checked or not.

5. client ignores b_virtualserver_servergroup_list

The user can still view the virtualserver's servergroup list regardless if it's checked, unchecked, or undefined.

6. client ignores b_virtualserver_channelgroup_list

Similiar, the user can view the virtualserver's channelgroup list regardless if it's checked, unchecked, or undefined.

7. i_client_max_bantime is not defined = not able to ban

Simliar to the channel creation limitation, if i_client_max_bantime is not defined or is set to 0, shouldn't this be disabled by default?

that's all.

[Alcazar]

As Staff / Devs said, 2,5 and 6 are only for ServerQuery and TS viewer, not for clients in Teamspeak.

[willy_sunny]

well, shouldn't they put a better "sign" letting their user know? just so that it doesn't confuse the user

[dante696]

well, shouldn't they put a better "sign" letting their user know? just so that it doesn't confuse the user

The descriptions will be updated with client beta 27.

[willy_sunny]

Well, how about the rest?

do they qualify?

[dante696]

Threads with multi reports arn't that easy and should be avoided :-/
Bug 1 & 3(both sounds like server) & 4 will be checked today.

Bug 7 is no bug > Setting a Max Ban time of 0 is something else, then removing the permission from client/group. It's no power, that get's compared with any needed power. This permission just defines the ban time.


Update
Bug 3&4 need another check next week
Bug 4 has been fixed here

[willy_sunny]

Threads with multi reports arn't that easy and should be avoided :-/

Right, but if I were to make multiple threads, I get yapped by you too anyways XD (j/k)

Bug 7 is no bug > Setting a Max Ban time of 0 is something else, then removing the permission from client/group. It's no power, that get's compared with any needed power. This permission just defines the ban time.

What I'm saying is

If ban time is "defined" -> allow user to be able to create a ban
If ban time is "not defined" -> disable the ban function (similiar to the channel creation check, if one of the needed permissions is missing, then disable the function at all)

[dante696]

Bug 3
The description for that permission will be changed with our next client.

[dante696]

Bug 1
This will be fixed with server beta30 (Build 12862 or higher)