[Mailman-Users] *UN*subscribing in bulk

[Barry A. Warsaw]

>>>>> "CK" == Craig Kelley <ink at inconnu.isu.edu> writes:

    CK> We used to use SmartList which would keep e-mail addresses in
    CK> a plain text file and when any user was deleted it was simple
    CK> to grep for them and unsubscribe them.

    CK> I have adapted the user deletion scripts to use `list_members`
    CK> to enummerate the users in a group and then `remove_members`
    CK> to take them out.  This takes *forever*; every time we remove
    CK> a user (and we have hundreds to do in bulk plus the occasional
    CK> dozen which are done by hand) it must perform `list_members`
    CK> on every list (we have close to 40).

    CK> Is there another way to do this?

A couple of thoughts.  For the PSA list, we actually have an external
database of email address, and we use bin/sync_members to keep the
Mailman database up to date.  Also, I recently added a bin/find_member 
script to CVS which might help some, although it does a linear search
through every member on every list, so it also may not be that fast.

Another thing that's not clear: is it the list_members part that's
slow or the remove_members part?  A while back Harald improved the
performance of bin/add_members by adding MailList.ApprovedAddMembers()
which avoids the costly save-to-disk operation for the addition of
each address.  We might need a parallel for bulk deletions.

    CK> Can I count on grep <email> listpath/config.db to work in
    CK> future versions, or is list_members the only guaranteed way?

I definitely want to leave the option open to change the underlying
database model at some point, but I think you're probably safe for a
few revs :)

Remember that if you don't mind hacking a little Python, you can write 
your own Python scripts that access the underlying MailList objects in 
any way you want.  Very powerful concept.

-Barry