[BALUG-Admin] List migrations and preserving options as feasible - another approach ... WWW::Mechanize to load!
Michael Paoli
Michael.Paoli@cal.berkeley.edu
Sun Jul 30 12:22:18 PDT 2017
Not sure why I didn't think of it earlier (perhaps it wasn't quite as
obvious earlier),
but another approach which may be highly feasible ...
use WWW::Mechanize to load options!
So, ... presuming it's fully workable (list admin can load? - need
to test that), if that bit is doable - notably list admin can load/edit
member's options on the individual members' options page,
then that ought be fairly straight forward (moderate extension of what
I've already coded to gather the options) - would also have
key verification advantage - can (reload and) inspect target page
after to ensure options match as expected (programmatically* of course).
But I notice list admin can't make *some* member changes (e.g. disallows
list admin to change member's password ... at least one Mailman version
I looked at) - but setting that isn't an issue/concern - it's all the
other options.
Anyway, in theory (presuming the relevant tests work), could go
quite something like this:
"disable" old list (set "emergency" moderation, update description
regarding migration - effectively leave old location read-only)
scrape source data
stop exim (so that member settings will be suitably adjusted before
they're notified of subscription having been migrated)
subscribe members - preserving email case (as user subscribed**)
tweak user's options (using the scraped data, and also verifying results),
restart exim
*dang, I have to resort to american-english-huge before programmatically
passes the spell(1) check.
**I also notice Mailman (at least one version I checked) doesn't let
user's change their email address to another version of same email
address but only with changes in case - it complains that they're
already subscribed/member - or something to that effect. Now, I
could see requiring email verification if case of localpart changes
(as they *could* be distinct addresses/recipients), but seems
Mailman ought handle that same way it does for user making any
other change to their email address.
Anyway, presuming it works, may well get me to the needed load
functionality more quickly than the Python pickle (.pck) route
or the like - plus has the verification advantage.
> From: "Michael Paoli" <Michael.Paoli@cal.berkeley.edu>
> Subject: Re: lot of really nice command-line tools to use in dumping
> and editing various pck databases
> Date: Sun, 30 Jul 2017 11:55:20 -0700
> Thanks, slick, noted.
>
> I also noticed there's package (mailman-api)for a REST API for Mailman.
> I also found a very promising mmclient (which uses Mailman's REST API),
> but alas, don't see a corresponding package by Debian.
>
> Also thought of something else highly practical ... but, topic drift,
> will post that separately.
More information about the BALUG-Admin
mailing list