b_client_modify_own_description not working

[Isabaellchen]

Hi.

I am trying to have the clients on my server to be allowed to edit everyone elses description but not their own.
So i set (permname/value/skip/negate):
b_client_modify_description 1 1 0
b_client_modify_own_description 0 0 1

The channelgroup does not have any of those permissions.

Did i miss anything?

[SilentStorm]

If I can modify everyone's description by definition mine is included.
In other words what you are doing is to disallow them changing their own Description but then allow them to change everyones Description.

Cannot be done.

[Isabaellchen]

Can be done, just a matter of programming

[SilentStorm]

Sure it can be done and I know that, what I was saying was that it cannot be done right now with the way it works now.

Honestly though I don't think it should be done. For a multitude of Reasons, mainly the following:
- it makes no sense to be able to change other's Description but not ones own
- it is easily circumvented by just have my mate change mine for me or even just connecting a second time changing my Description on the first connection.
- Everyone would need to change their setup.
- Error prone (as in People will expect to be able to change their own Description when they can change everyones)
- The *_own* Permission were meant to be used for/by lesser admins / Users which should be able to do and revert stuff but not mess with Stuff done by others... You wouldn't want someone to be able to delete all but their own Bans or Complaints for example... it just makes no sense.
- The definition of all or everyone still includes oneself.

[Isabaellchen]

If b_client_modify_description = true and b_client_modify_description skip disabled (default)
b_client_modify_own_description = false would have no effect.

Oh and i speak on a TS3 server that succesfully manages to live on without a single admin reigning on the server, only a technician which is me. Which is why there is definetly a reason why you don't want people to be able to set their own description.
The further debate would include social effects which is why i'll stop arguing here.

[SilentStorm]

Setting a Permission to false (or 0) will never have any effect because it is simply the default Value and already present, unless you set it on a higher tier where it will overwrite the previously assigned Permission, since them both are different permissions it won't do anything.

I definitely agree that there are reasons for not allowing people to set Descriptions especially so on public Servers, but allowing people to modify others but not their own description is creating even more Problems than allowing people to set their own Descriptions and even more so on public servers without admins.

[Isabaellchen]

boolean values are either true or false, not true or nil. Which is why its just a matter of the order of conditional statements, as i said, rather a coding decision.
In this case, having two permissions changing the behavior of one attribute, while one permissions override behavior is hardcoded, id consider this a conceptual bug, especially because there are special flags for for overrideable/negation.

Edit: I think we both argue on different levels. My statement was posted from a programming point of view, while you argue in the world of permissions.

[SilentStorm]

I never said anything about any value being nil (or otherwise undefined) I just said that setting a Permission to such a value makes no sense since the Value defaults to false on bool Permissions and 0 in integer Permissions. And I am obviously talking about Permissions since this is what this is about.

From a programming pov what you are trying to achieve would require the setDescription Flag to explicitly imply the setOwnDescription Flag, with the setOwnDescription Flag to be set after the setDescription Flag to determine if it got revoked again from a Permission explicitly set to false. Afterwards the checks would need to be changed too, but this is all dependent on how things are done in the Source however discussing this is pointless as I am pretty sure none of us knows for sure how things are done in the TS3 Source.

[Isabaellchen]

You don't have to see the code of a program to undestand its logic... well at least i don't.

The way how this is done is a conceptual decision (i hope) which invokes the misbehavior i am talking about.
So this is a conceptual bug after all, no matter how many times you try to undermine my point.

[dante696]

No this is definitly no bug.

We don't think that the permission should be used to dissallow to modify your own description.
With permission b_channel_modify_description: You say that user can change descriptions and the target does not matter.
b_client_modify_own_description instead allows to modify the own description, when you are not allowed to modify descriptions at all. The permisison does not say, you can not change your own description.

The same behavior appears with more then this permission. You can't use this permissions to prohibit some actions.
You can use them for co-admins as an example.

b_virtualserver_modify_temporary_passwords_own
b_client_permissionoverview_own
b_client_complain_delete_own
b_client_ban_delete_own

Please create usefull groups. Groups that are not allowed to modify anything instead...


I mark this thread as resolved > the permissions works as intended.

[Isabaellchen]

Please create usefull groups. Groups that are not allowed to modify anything instead...

Well, no admins here, no grouping possible... Except for everyone to be allowed to join or leave any group... which is the current state concerning editing ones description.

I mark this thread as resolved > the permissions works as intended.

From your point of view.
I'd go for the "fits all" solution, but thats just me.