Replace the "activated" state toggle with a "locked" toggle

[KairuByte]

Is your feature request related to a problem? Please describe.
The closest we have to locking an account is to deactivate it, which has further implications than a user just not being able to log into the system, such as the account being removed from the community tab. If I want to temporarily lock down an account for whatever reason, I should be able to specify it as locked instead of deactivated.

The only way to "deactivate" an account should be a full account deletion, or some sort of ban. It does not make sense from a flow perspective to deactivate an account.

Describe the solution you'd like
Remove "activated" as a toggle. This should be a one and done state. You activate someone, and after they are activated your only option to "deactivate" is account deletion, or a ban if/when that becomes an option.

In place of the "activated" toggle, allow for account locking/banning.

Describe alternatives you've considered
An account level lock/ban/suspension/timeout/kick/etc are all options, all meaning the same thing. "This account is no longer authorized to access the server."

Additional context
If this does get implemented, it should be optional if locked accounts are visible within the community tab.

[Alfagun74]

It looks like you might be dealing with an XY Problem.
Regarding the activation state, you can see it as either locked/unlocked or banned/suspended/timeouted/kicked. Use it according to your needs as an admin. We won't introduce multiple fields that do the same thing.

I sense that your concern is that unactivated users are not listed. If that's what you're looking for, I can add another configuration variable to determine whether unactivated users should be visible to others. Is that what you're essentially looking for?

This would introduce the problem that unallowed registrations would spam the community tab so I don't like that setting either. I feel like it's totally fine to hide banned/locked/whatever users. Could you tell me what's wrong with that?

[KairuByte]

Definitely not an XY problem, but I may not be expressing myself properly.

Activation, to me, and admittedly in most cases I can think of, is a one time process. Your phone gets activated once, your discord account gets activated once, your github account gets activated once. It's a process where information is verified, and the back end is saying "okay, yep, all info looks good, you've proven to me that I should let you in, here you go!"

There are other states however. Your phone may be activated, but if you stop paying your phone bill it doesnt deactivate, the account gets locked. If you break discords ToS, your account is still activated, however it is also banned. Github, Reddit, Microsoft, Google, etc. All of these have alternative states which mean "yes the account exists, and yes it has been activated, but no you are no longer allowed to access it."

While I can understand the perspective that an account that is deactivated is an account that is locked, and for the most part at the moment it is... I'd argue that "this account wants access" and "this account had access" are different states. The first implies that there is no other data in the system, they've not interacted with anything, their information is safe to purge. The second implies that the person has had access, touched things, and that there is likely data within the system associated with them.

In my mind, it should be impossible to deactivate an account.

[Alfagun74]

I understand your perspective now. However, the current approach of maintaining a single "activated" state with the ability to activate and deactivate a user at any time is already effective. It serves its purpose, prioritizes simplicity and user-friendliness, ensuring that admins clearly understand their users account status while avoiding unnecessary complexity.

In the end, the decision on how to manage account states should be based on the specific needs and goals of our system and users. I appreciate your input in this ongoing discussion.

So, I'd like to propose a poll to the council to determine if the current system suffices or if we should allocate additional resources to this matter, even though a practical solution already exists, particularly for the use case of "revoking user access."

[Alfagun74]

To be clear i would still like to remain the function to revoke activation (removed from list)

[Alfagun74]

Todo:

• Implement a "Locked" Toggle in the server and client that locks the user out but still shows them in the list.

[Alfagun74]

Due to a significant backlog of tasks, a closely contested poll outcome, and thorough team discussion, we have made the decision not to proceed with the implementation of this feature. We apologize for any inconvenience this may cause.