Bug reporting this as it is a design oversight, or in any case is not expected behavior from a developer point of view.
Currently, if the public reason provided to the new ban API is filtered, the ban will fail and a warning will be logged. I can see how this could have been settled on as a matter of principle - banned users “should” always know why.
However, this neuters automated ban systems such as honeypot remotes to bait exploiters, voting systems, etc. because now you need to have a fallback ban reason such as an empty string. This undermines any potential UX angle of failing the request in the first place, because developers now have to make automated ban reasons uselessly short or even downright empty just so that the chance of them being unexpectedly rejected is mitigated.
I would prefer my players see a partial ban reason or a fully censored ban reason, rather than have all of my automated bans fail because the filter is having a bad day. Better yet, I’d prefer to be able to choose whether or not the ban will fail when the reason is filtered, so my moderators can react appropriately, but I don’t have to let bad actors run amok because the filter morphed one day and started filtering my automated reason.
We are encouraged to store the unfiltered ban reason and filter it every time it is shown, Roblox should be doing the same thing. The filter should and will adapt to show the reason if it is appropriate, not the other way around.
This current requirement for an unfiltered public reason is putting way too much faith in the text filter being reliable to the point where it renders this API unusable in automated contexts.
To add: the filter requirement is especially hard with Open Cloud. In a live game, you could use the filter API and hope for the best (which might either over-filter and lose important information, or under-filter and reject the ban), but there is no way to do this from an Open Cloud application. I’m nervous about integrating a current system to use the Open Cloud version because of this. Custom ban messages would be a non-option, and pre-made ones would require serious testing and occasional re-testing to work.
Thank you for the feedback. We are actively reading all of the comments here and in the announcement post. We are discussing a better solution and hope to share our thoughts soon.
Personally, I don’t understand why it has to be filtered at all; seems like an arbitrary random limitation when game developers are the ones deciding ban messages. Imagine I ban someone for pedophilic behavior; how am I supposed to word that to get around the filter? Why do I even have to think about getting it around the filter?
Or what if the filter arbitrarily misbehaves and decides a specific reason of ours (that is worded completely innocuously) is now filtered?
Kicking the player or using a custom ban screen doesn’t have these limitations, which sucks because we really want to move over to the new ban system. The filter requirement should be thought out a bit better.
What does a bad actor stand to gain from an unfiltered ban screen? Nothing, from how I see it, given they could already do way worse by just not using it.
You wouldn’t? Report them on the platform, and phrase your personal ban reason as “Inappropriate behavior”. You have an internal ban reason for these details, it remains unacceptable to say such things even in your ban reasons. The exclusive issue here is the filter blocking the ban entirely.
I think the main concern is not bad actors who are getting banned, and instead, the developers themselves and their conduct. It seems awfully bizarre considering how much trust is placed in developers anyway. You are right in your point, but I think it could also be concerning if a person is banned from a game with an inappropriate ban reason. This could make an uneducated user panic and would not necessarily be good.
On the other hand: Why not just filter it like how Player:Kick() works? I think the topic is entirely right in that rejecting your reason on the basis of filtering creates a large hole in the practicality of an otherwise amazing appearing ban system. It mainly comes down to the fact that this system should be as functional as possible and that developers should be given the benefit of the doubt here, as long as there are reasonable safeguards in place.