Add ability to set email confirmation state to false - #2997

I see that User::activate fires an event, would it make sense to have a similar event (and perhaps method on User) for deactivation?

Other than that this PR looks fine.

Implemented both. We now have User::deactivate and a Deactivated event.

I am not convinced of the use case for this. As mentioned over chat, I would be in favor of a general activation / deactivation mechanism where email confirmation is one factor, but until then, what's the use case for marking an email as not confirmed?

I was reading through the changes and got confused by the fact that activation and deactivation relies on a column about email verification. To that extend I agree, for now we might keep this logic and extend or modify it later? Imo this logic almost warrants it's own database column activated_at?

I think we should add this for now, and then change the activation logic later.

Very well, I think we can do this, but could we rename the methods to confirmEmail and unconfirmEmail (and deprecate activate)? Then the API would be consistent with the behavior we want to work towards in the future.

Hello, thank you for your pull request! In order to speed up future development, keep all work in one place, and take advantage of CI tools that can help us avoid breaking changes, we have moved all Flarum code to a single monorepo at flarum/framework. You can read more about this process in our dev diary. Unfortunately, pull requests can't be carried over to the monorepo, so we have to close all open pull requests. If this pull request is still relevant, please feel free to reopen it over on the monorepo. We apologize for the inconvenience, and hope you will consider contributing to Flarum again in the future.