TShock icon indicating copy to clipboard operation
TShock copied to clipboard

Suggestion: Make ban system more user friendly

Open moisterrific opened this issue 4 years ago • 0 comments

intro

new ban system/features are great but it's a step backwards in usability if you're trying to do anything with it besides banning an online player. the old system was dumber but also a lot more intuitive to use. here i will highlight some of the issues and propose what can be done to fix them. initially, i tried to make it more easy to understand by adding extended usage examples (https://github.com/Pryaxis/TShock/pull/2412), but tbh i don't think this solves the root of the problem (see also: https://github.com/Pryaxis/TShock/issues/2382)

issue 1: confusing offline banning

assuming you're banning an offline registered account, the old system was very straightforward. you simply do /ban add <username> <duration> [reason] and it will automatically ban the account along with its associated IP and UUID. with this new system there's a lot more steps the user needs to go thru to get the same results as before, first you have to do /ai <username> to find their offline acc details and the last known IP tied to that acc, then you have to do /ban add <acc:username> [reason] [duration] -e to ban the offline acc, then /ban add <ip:255.255.255.255> [reason] [duration] -e to ban the offline IP. Banning offline by UUID is now impossible w/ this new system.

potential fix: if the name is not found online, instead of returning some error, make it automatically check the DB for the matching account name and its related identifiers, then ban the acc along w/ those identifiers, this would make it a lot easier to use and just like how the classic ban system worked

issue 2: messy ban tickets

now let's talk about online bans, previously, if you needed to delete a ban, you just do /ban del <username>, now bans are sorted by tickets and with each ticket representing a different identifier (-a, -ip, -u, etc.), so now if you're trying to unban someone you'd have to unban each of those tickets separately, and could run into issues where you can't tell which UUID ticket is tied to which account. also you'd have to delete each ticket separately

potential fix: instead of the identifiers being registered by tickets 1 (acc), 2 (ip), 3 (uuid), and so on, have them as something like 1a, 1b, and 1c, this way it makes it easier to tell which identifiers are tied to each other. should make it so you can do /ban del 1* to delete all the connected identifiers if the user wants to do that. i guess this could also make /ban list slightly easier to navigate too, by listing only the number it would slim down the amount of pages, then users can maybe use /ban details to check the abc "sub-tickets"

issue 3: poor handling of ban overwrites

im actually not entirely sure on how the old one compared, but iirc if you banned an acc for 1d, and you add that again but under a longer duration, it will use the longer duration. now if you tried to do that it doesn't work and you get a vague error msg that doesn't even tell you which ticket already has the ban

potential fix: either add the matching existing ban ticket number to the error msg or just make it automatically overwrite the existing one with whatever new duration the user specifies

other minor issues

the old system broadcasted the ban msg to everyone, now it only shows it to the ban command user. i think it should by default still send a general msg of who banned who for what reason if you use the default command specifier (obviously w/o disclosing the banned user's IP and UUID), and if you use the silent specifier it should work like it does right now

conclusion

these are just some of the issues that caught my eye while learning to use this new ban system, whoever improved it did a great job functionality wise, but there's still a lot of room for improvement when it comes to usability and i think it's very important to make it powerful AND easy to use

moisterrific avatar Aug 15 '21 20:08 moisterrific