v0.26.0 introduced a change when email confirmations were not stored in the database anymore by default, however this was not reflected in the code. Because the command for checking whether user have confirmed their email address relied on EmailConfirmation model instance to be present - the command was working no more.
Solution
Modified base settings to continue storing email confirmation instances to be able to reference to them when command is run.
To cover a case when during some period of time users were not confirming their email addresses but were also not deactivated, that is when EmailConfirmation instances were not created - users are being deactivated straight away, however next time they try to sign in an email will be sent where users can reactivate their account.
Note
Superusers will now be completely excluded from the command execution, and will not require their email address to be confirmed within 24 hours.
Coverage increased (+0.02%) to 90.578% when pulling a3efe2e6514ff9072388a6908d3ab239348f3723 on bugfix/make-sure-users-are-deactivated-when-not-confirmed into c70be3f50db4ede0f4dbf340b9b7409f0aeeb95e on master.
Root cause
v0.26.0 introduced a change when email confirmations were not stored in the database anymore by default, however this was not reflected in the code. Because the command for checking whether user have confirmed their email address relied on
EmailConfirmation
model instance to be present - the command was working no more.Solution
EmailConfirmation
instances were not created - users are being deactivated straight away, however next time they try to sign in an email will be sent where users can reactivate their account.Note
Superusers will now be completely excluded from the command execution, and will not require their email address to be confirmed within 24 hours.