As a Roblox developer, it is currently too hard to distinguish between real-bans that were rightfully enforced and bans which were accidental / done to test out the implementation. As of currently, once you ban a user via either the Engine API or the OpenCloud API, the ban permanently gets pushed to the player’s ban-history; this occurs even if the player is later unbanned. While this is helpful for some use-cases it can be unwanted in certain cases:
For example; when testing-out whether you have properly implemented the API, you may wish to temporarily ban a user and ensure you receive the correct behaviour when listing their logs, etc. This unfortunately comes with the side effect of being unable to clear away these logs when you are done.
This also becomes a problem when you may accidentally ban the wrong user from your experience. In these cases, the player will have this log attached to their account forever, this means the developer will have to keep a log of this incident and can no longer rely on GetBanHistoryAsync to provide accurate results.
If Roblox is able to address this issue, it would improve my development experience because I would be better able to rely on the new ban system and test it out without having to worry about permanently polluting the ban-history of my experience.
Hey there, ban history items have a lot of properties including public/private reasons and whether it was a ban or an unban, what prevents you from using these properties to indicate the reason for a ban/unban or preprocess the list (remove accidental bans that were undone) before showing it to the user as you desire?
The goal of the API is to provide an immutable log of events. You can always decide to store the actual user-facing format on bans in a different medium (e.g. datastores) if that is important for your experience, if you can’t do that simply by preprocessing the data from the API call directly.
I don’t think that it is a good idea to prevent developer from being able to remove data. I don’t wanna end up one day with like 200 events that I cannot remove. Filtering it out seems like a bandage fix to me.
If someone is asking for a right to be forgotten, then what’s the point of storing a ban history for a completely wiped account that’s never coming back?
As for a right to access your data, it’d still be logged somewhere.
The entire point of ban history is to be immutable as @Hooksmith mentioned. I’d much prefer it to be this way as well.
Realistically speaking I don’t see a scenario where simply filtering out old data is more of a con then possibly losing that data all together. The scenarios you provided are all cases of the system being mis-used (aside from testing purposes I suppose)
If you’re worried about improper logs showing up, then that’s more-so user error, is it not?
In the case of an accidental ban, I won’t have the foresight to add any useful metadata to identify the ban as false and since the data cannot be edited, it would be impossible for me to edit that after-the-fact.
In the case of a test, it is less than ideal to constantly need to ignore items when running through the log history, while certainly possible it requires many extra steps and foresight of the possible situation. I’ve already test-banned users without this foresight and am now unable to differenciate between the bans.
I believe an extra ‘delete’ scope could work to prevent unauthorised removal of ban logs. Optionally a different solution to allow for filtering out of these ban logs would also work.
Accidents happen, or a moderator could get hacked. It’s impossible to filter out those logs since unbans can not have reasons attached to them, and hence, those simple accidents then become a permanent issue. I don’t believe this is ‘misusing the system’ as I personally don’t see a way of preventing such situations from arising.
i would also like to add to the fact that some games may have a penalty system, for example when someone leaves the game during combat, or during an ongoing team based match.
i don’t think i would really like to see my ban logs filled up with someone constantly receiving a penalty.
therefor i also think a new parameter in the config called “AddToBanHistory” would be pretty useful.
i generally don’t see the point why developers wouldn’t be allowed to remove their ban history from their experience. i see more negative things than positive things. it helps you organize the moderation functionality of your experience, it impacts the flexibility in reporting others as updating or modifying log entries can be essential for accurate and comprehensive reporting.
you would also maybe want to correct errors within your bans, and not being able to do so will just cause even more struggles.
and just forcing it to be stuck up there forever where it will just stack up problems over problems overtime is not a good thing at all. from my understanding people just want to use this api, because of the “alt detection”, a regular datastore based ban system gives developers more flexibility and is more preferred over the Ban API due to its current restrictions.
not to mention, you could realistically make something like an “AuditLog” datastore where you could log necessary moderator actions and remove them at any time.
If the system gave a ban by mistake I need to unban the player. I don’t want something to remain in the player’s history forever because of a misunderstanding. It makes no sense to prevent us from deleting history with a ban made by ourselves.
Is it really that hard to implement?
Players:RemoveBanRecordAsync(player.UserId, 1) -- would be great
Small flaws like this make it necessary to use your own ban system.
I’d also like to be able to freely test this API in studio, but it seems like too big of a request…
for this specific case, you can simply unban and reban the user. the OP was referring to removing a record from the user’s ban history - if the ban you placed was legitimate, there’s no problem with having a duplicate record in their history.