I've just had a three month baptism of open registration and user administration.
Registrations are driven by "backlinkers" in pursuit of page rank. Some registrants will comment or post with backlinks as well as pimping their sites in profiles.
Moderation is a must to prevent embarrassing content leaking to a sensitive audience. The burden of moderation can be mitigated by spam suppression like mollom and recaptcha.
Initially I "blocked" errant registrants but the profiles persist which is the primary goal of the backlinkers. I have since opted to "delete" rather than block. Advuser helps, "prune" is too crude.
In the medium run, I am honing an SQL query to separate the sheep from the goats preserving valued registrants meaning those who post relevant content. Hopefully that will lead to a "purge" module that can be "cron"-ed.
Jim
I just tested this and it does seem to be the case. I tried blocking a
test user by clearing the value in the password field and setting the
blocked toggle while monitoring the encrypted password value in _users
using mysql. The user record was saved correctly and the encrypted
password string remained the same. I should have suspected this.
Thanks.
On Sat, 2010-03-20 at 17:05 -0400, Adept wrote:
> On 3/20/2010 3:58 PM, Scott wrote:
> > I'm getting an error when I try to ignore the password fields. The
> > confirm password field is blank and the message I get is that the
> > passwords don't match. Therefore the user record is not updated.
> >
> >
>
> it's possible that if you have stored your own log-in password in your
> browser, that your browser is auto-filling the Password field wtih
> _your_ password. When making changes to another user's account, make
> sure *both* password fields are blank, unless you are in there to reset
> their password (in which case you will need to replace the contents of
> the Password field with _their_ password and then retype it in the
> Confirm Password field).
>
> make sense?
>
> kazar
--
[ Drupal support list | http://lists.drupal.org/ ]