Suggestion: Improve granularity of Kick/Ban permissions

[ChrisLenga]

Separate kick and kick all, as well as ban temporarily and ban permanently. In some instances, you are okay with someone kicking individual players, but not the entire server, for example.

Also perhaps separate ban, and unban, so that gives server owners the flexibility to set a specific rank that can ban, but not unban users.

[TasoOneAsia]

@ChrisLenga Thanks for the suggestion. @tabarra and I have thought of separating certain permissions in the past. But one concern of ours was the number of permissions. We didn’t want it to be of a number that started to intimidate the user.

But if you believe that these are essential, it might be good to start looking into that.

@tabarra any input?

[tabarra]

Yeah, just as taso said.
Firthermore, kicking 1 and kicking everyone one-by-one is the same.
Banning permanently or banning for 9999999 days is also the same.

What makes sense, and I will take into consideration, is making ban revocation a separate permission, but probably not.

[ChrisLenga]

Yeah, just as taso said.
Firthermore, kicking 1 and kicking everyone one-by-one is the same.
Banning permanently or banning for 9999999 days is also the same.

What makes sense, and I will take into consideration, is making ban revocation a separate permission, but probably not.

Not true though, at least entirely. Let me explain.

Kicking everyone, vs one by one. One action to kick everyone, vs sixty actions to kick sixty players. By the 5th kick a higher up would identify potential abuse and be able to remove the permissions of the user abusing.

Banning would be in the same fashion. You'd essentially remove "Permanent" and "Custom" from those who can't ban permanently, and then they're forced to use the drop-downs for bans. Likewise, separating ban and unban works well to avoid admins unbanning their friends. It removes one potential abuse aspect that could be massively toxic and troubling for a community, especially if they're a large community. We have nearly 15,000 members for example, and we can't watch everything across all of our servers. We rely on gating permissions so we don't have to.

I do see your points though, but I think these examples paint a slightly different picture.

[TasoOneAsia]

@tabarra Thoughts about this? So I can adjust tracking as needed.

[tabarra]

I think more discussion is needed, both as user input, and technical discussion.
For instance, what would the new permissions look like? Would we need to do ace-like hierarchical permission evaluation? What that would look like in the Admin Manager UI? How do we migrate old users?

Either ways, this MUST be decided in the next 30 days or so, because after we do the FiveM permissions sync thing, it will more or less be set in stone not to break compatibility with upcoming resources.

[tabarra]

If we decide to go for a full hierarchical permission list editor, this could really help for the Admin Manager to also set non-txadmin related permissions like vmenu.
Imagine maybe a button for "add schema" which will import a permission list via JSON and that could be edited via the admin manager? Would be really sick!

But Honestly, this is not something I could do alone (🤢 frontend).
@TasoOneAsia do you think this is the kind of thing we could maybe do embed react inside the web ui? Virtually no external state and complicated dependencies like the menu, just the admin manager.

[TasoOneAsia]

If we decide to go for a full hierarchical permission list editor, this could really help for the Admin Manager to also set non-txadmin related permissions like vmenu.

Are you thinking an ace editor UI essentially? This is definitely possible, we should discuss what you are thinking over voice so I can get on the same page.

@TasoOneAsia do you think this is the kind of thing we could maybe do embed react inside the web ui? Virtually no external state and complicated dependencies like the menu, just the admin manager.

We could have a React implementation embedded standalone in the page but the increases in bundles sizes for a relatively small feature may be a concern.

We can discuss this further over voice whenever we get a chance.