[Mailman-Developers] Another take at MysqlMemberAdaptor + a migration utility

[Fil]

> else feels like testing it, I have fairly silently uploaded the latest
> version (1.69) of it to the oRe Net Opensource pages, although that has
> only been tested to the point of a python syntax check pass.

Thanks! I have upgraded my version (which is still very different from
yours, as you notice), with those patches @
http://trac.rezo.net/trac/rezo/changeset/17


> * Figure out how to make passwords work. Currently using "!" as the default
>   password, so that things don't barf, but that is probably not the right
>   way to go about it. What is the Mailman equivalent of "No password", etc?

I guess you have to add a new random password. That is, something like
        self.setMemberPassword(user, Utils.MakeRandomPassword())


> * PRIORITY: Database escaping, need to work out how to to this with the
>   Python MYSQLdb module, after all it would only take a well-crafted email
>   to raise merry hell as things are at the moment.

I'm not sure what your're referring to. The MemberAdaptor is only called
when the list exists, isn't it? So the only way to hack into the database
would be to have weird chars in either the address (which is properly
escaped, from what I saw), or the bi_cookie (which isn't, but I guess
Mailman is crafting this one, isn't it?)

> * MYSQL_MEMBER_DB_WHERE so you can specify a "WHERE x = y" on all the
>   queries in the database. ???

Like in "WHERE home_made_delivery_status = 'enabled'"? It could be useful in
some situations, but probably on a list-per-list basis, not a global setting
like this (well of course you can always set MYSQL_MEMBER_DB_WHERE from
extend.py)

There was another suggestion recently (on irc) to allow for lists of
subscribers taken on the fly from a SQL query on any table; but then no
subscriptions, no bounce processing and so on... This would add a lot of
complexity.

-- Fil