I have a list on my server whose admin has neglected her duties for the past 14 months, and who now longer exists. The admin queue has some uncertain, but large, number of messages in it. I'd like to reject them all with the same explanation, and the web interface will want me to type/paste it in to all the little boxes, which I don't really want to do.
Can someone suggest the correct code to handle this with withlist? I don't know enough Python to make it up myself.
Other approaches to the problem are welcome, too. Thanks.
I'm using Mailman 1.0. Yes, I know what's current. :)
On a tangent: does it not make sense to store queued admin requests in separate files, so that they can be handled arbitrarily and without instantial Python code? Something like a .../lists/listname/adminq/%05d.txt file containing the message, I'm thinking.
-- -D. dgc@uchicago.edu NSIT University of Chicago
At 4:55 PM -0600 11/29/00, David Champion wrote:
I'd like to reject them all with the same explanation, and the web interface will want me to type/paste it in to all the little boxes, which I don't really want to do.
I know this doesn't help your problem, but it's something I noticed -- mailman attaches the default admin message at the time the message comes in, not at the time the admin looks at it. It means you basically can't update those messages, which is not much of a problem, until you have to.
In general, I think it's a good idea to design stuff so that it doesn't assign values until it has to, just in case. this is a great example why.
On a tangent: does it not make sense to store queued admin requests in separate files, so that they can be handled arbitrarily and without instantial Python code? Something like a .../lists/listname/adminq/%05d.txt file containing the message, I'm thinking.
I'm not sure separate files are the answer, but cleaner handling of the admin queue is.
At the worst, you can use python to read the requests.db file and manually rewrite all fo the messages, then use the admin page to reject them. That might require reading the mailman code for the requests.db data structure, but it's doable.
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
The vet said it was behavioral, but I prefer to think of it as genetic. It cuts down on the liability -- Get Fuzzy
On 2000.11.29, in
I know this doesn't help your problem, but it's something I noticed -- mailman attaches the default admin message at the time the message comes in, not at the time the admin looks at it. It means you basically can't update those messages, which is not much of a problem, until you have to.
In general, I think it's a good idea to design stuff so that it doesn't assign values until it has to, just in case. this is a great example why.
Agreed - especially since the URL embedded in the rejection text is subject to change. It sounds as though what gets sent out in the rejection letter can actually be invalid when it's received.
I'm not sure separate files are the answer, but cleaner handling of the admin queue is.
Separate files or no, this seems like another instance where the data is dependent on Python itself, and not for any apprent (to me) reason. But it's especially awkward here, since the data in question did not come from within Python - it comes from the MTA/MDA.
At the worst, you can use python to read the requests.db file and manually rewrite all fo the messages, then use the admin page to reject them. That might require reading the mailman code for the requests.db data structure, but it's doable.
I can do that, but it will take me a big chunk o' time to turn what I glean from reading into code that parses and works. :) Much easier to read than to write, as always.
-- -D. dgc@uchicago.edu NSIT University of Chicago
At 5:48 PM -0600 11/29/00, David Champion wrote:
Agreed - especially since the URL embedded in the rejection text is subject to change. It sounds as though what gets sent out in the rejection letter can actually be invalid when it's received.
well, I think there's an assumption being made that admins process queues on a regular basis. If that's true, it's no significant problem. But these error conditions are such fun, even in real life.
Separate files or no, this seems like another instance where the data is dependent on Python itself, and not for any apprent (to me) reason.
it's because these data files are basically disk-resident versions of internal data structures. It makes perfect sense from a python point of view, similar to perl using TIE to store structures on disk.
I can do that, but it will take me a big chunk o' time to turn what I glean from reading into code that parses and works. :) Much easier to read than to write, as always.
yeah, I know (wince). but it's better than nothing, and I don't know a better way.
What I might do, frankly, depending on just how many there are, is the old past and click tango on the web site... It's grunt work, but it could well be faster than doing it "right".
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
The vet said it was behavioral, but I prefer to think of it as genetic. It cuts down on the liability -- Get Fuzzy
participants (2)
-
Chuq Von Rospach
-
David Champion