So, working on the whole nature of is_activated spawns a few ideas.
1) Purging users pending approval
One of the things that I hear regularly from other forum software is that users tend to delete users who haven't approved their email in a couple of days. To me, this makes a fair amount of sense, if a user hasn't activated their account within a day or so of signup, odds are they're not going to. So, it also makes sense to me, then, that after a day or so, we could automatically purge that for admins.
I don't see this causing significant extra load anywhere, nor do I see it causing any other problems at this time, but I'm opening the floor to discussions and thoughts on the subject.
2) User re-agreeing to agreement (required re-agreement)
This is something I've wanted to add for a while, and I mentioned it in my other topic. Mechanically all you'd do is take any user that already got approved (is_activated state 1) and update it to a new state (provisionally state 6) when the details change to force them to agree to it again, and since it's wired in at account level, they'd *have* to do it to continue.
The problem with this is the case of users who are not currently state 1, all the little fringe cases where their account is somewhere else:
* state 0 - user has signed up and in the time between signing up and approving their account, the terms changed
* state 2 - user is a current member but has changed their email address
* state 3 - user is waiting for admin approval, much like state 0, it's possible the terms changed between their registration and admin approval
* state 4 - user is waiting for account deletion, probably not a problem!
* state 5 - user is waiting for COPPA approval, this is probably the most likely problematic, a user subject to this is very likely going to have to wait some time to actually get their account approved as they would have to send the form through the post, and that makes it more likely to have changed
Actually now that I really think about it, all we really need to do is track their registration time against the time the agreement was last edited, and if they registered before the agreement changes, move their state to 6 rather than to 1. In fact, if we do it as a 'last change to status' column in general, that problem goes away in its entirety. Talking it through really does work!
3) We could drop the Location profile field and make it a custom profile field.
It's not a thing I've seen that much, dropping from the core and making it a CPF means it's not cluttering up the members table, and it's only in use if someone actually wants it on their forum, rather than being on by default and only able to softly disable it.
1) Purging users pending approval
One of the things that I hear regularly from other forum software is that users tend to delete users who haven't approved their email in a couple of days. To me, this makes a fair amount of sense, if a user hasn't activated their account within a day or so of signup, odds are they're not going to. So, it also makes sense to me, then, that after a day or so, we could automatically purge that for admins.
I don't see this causing significant extra load anywhere, nor do I see it causing any other problems at this time, but I'm opening the floor to discussions and thoughts on the subject.
2) User re-agreeing to agreement (required re-agreement)
This is something I've wanted to add for a while, and I mentioned it in my other topic. Mechanically all you'd do is take any user that already got approved (is_activated state 1) and update it to a new state (provisionally state 6) when the details change to force them to agree to it again, and since it's wired in at account level, they'd *have* to do it to continue.
The problem with this is the case of users who are not currently state 1, all the little fringe cases where their account is somewhere else:
* state 0 - user has signed up and in the time between signing up and approving their account, the terms changed
* state 2 - user is a current member but has changed their email address
* state 3 - user is waiting for admin approval, much like state 0, it's possible the terms changed between their registration and admin approval
* state 4 - user is waiting for account deletion, probably not a problem!
* state 5 - user is waiting for COPPA approval, this is probably the most likely problematic, a user subject to this is very likely going to have to wait some time to actually get their account approved as they would have to send the form through the post, and that makes it more likely to have changed
Actually now that I really think about it, all we really need to do is track their registration time against the time the agreement was last edited, and if they registered before the agreement changes, move their state to 6 rather than to 1. In fact, if we do it as a 'last change to status' column in general, that problem goes away in its entirety. Talking it through really does work!
3) We could drop the Location profile field and make it a custom profile field.
It's not a thing I've seen that much, dropping from the core and making it a CPF means it's not cluttering up the members table, and it's only in use if someone actually wants it on their forum, rather than being on by default and only able to softly disable it.