Changes between Initial Version and Version 1 of Ticket #19844, comment 6


Ignore:
Timestamp:
Jan 6, 2014, 12:31:40 PM (10 years ago)
Author:
Chris Jerdonek

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #19844, comment 6

    initial v1  
    11I also think the limitation should be lifted.
    22
    3 In my use case, email address is the username field, and I would like a user account to be considered active only after the signup has been validated via email.  To handle this use case, it is natural to add the account info to the user table when someone tries to sign up, and then activate that row only when the user clicks the validation link in the corresponding email.  This is essentially what [https://django- registration.readthedocs.org django-registration] does in its two-phase registration workflow, with minor variations.
     3In my use case, email address is the username field, and I would like a user account to be considered active only after the signup has been validated via email.  To handle this use case, it is natural to add the account info to the user table when someone tries to sign up, and then activate that row only when the user clicks the validation link in the corresponding email.  This is essentially what [https://django-registration.readthedocs.org django-registration] does in its two-phase registration workflow, with minor variations.
    44
    55However, with this use case, there are edge cases where the same email address can exist unregistered in the database more than once.  With the above process, the unique index should enforce the fact that each email address should be in the database only once, but when restricted to __active__ user accounts.  This can be done, for example, by having a unique index on the pair of columns username and activation key (where the activation key is set to the empty string when the user is activated).
Back to Top