On 3/23/07, sedat ciftci <[EMAIL PROTECTED]> wrote:
If you prefer that design, I can change it and re-submit the patch. Sedat Çiftçi
Yes, please. I think the consensus is that we'd rather avoid new table creation in this enhancement. - Dave
--- Dave <[EMAIL PROTECTED]> wrote: > On 3/21/07, sedat ciftci <[EMAIL PROTECTED]> > wrote: > > Yes, it can also be done with this design. Note > that, > > in this design you have to clear the > activationCode > > (or make something else, to mark that it is used) > > after the account is activated (Also in my design, > I > > delete the related record from useractivate > table). > > The reason behind this requirement can be > explained as > > follows: > > Let's assume that a user registers with e-mail > > activation and assume that the related > activationCode > > is not deleted. After a while, admin user wants to > > disable the account of this user from the "User > Admin" > > menu of the Server Administration and disables it. > > Then, if the user clicks the activation link in > the > > sent activation mail (assume user stores it; did > not > > delete it), his/her account is enabled again. > Because > > of this simple scenario, do not forget to mark the > > activated accounts so that the link in the sent > > activation mail will not be used again once it is > > used. > > Sedat, > > Are you willing to change the design to remove the > new table and then > re-submit the patch? > > - Dave > ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
