On 6/26/23 11:53 AM, Ken Alker wrote:
Is the var/messages hierarchy also where all the archived emails are stored for future viewing via the web interface?
No. They are stored in the hyperkitty_email and hyperkitty_attachment tables in the database.
Also, there is a long thread at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/threa d/UWCUQYU7Q5X5LWNII57ZZ4DDXE4DEFX7/ and maybe others that might be relevant.
I have never used the mailman shell before, but based on the referenced thread I learned to do this (note that the thread also taught me how to rewrite it to narrow down to just the list with issues so I didn't delete held messages in other lists, if my case):
for verification:
venv) mailman@speedy:~/web/logs$ mailman shell -l sbarc-list@lists.netlojix.com Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the sbarc-list@lists.netlojix.com mailing list >>> requests = IListRequests(m) >>> first = True >>> for request in requests.held_requests: ... key, data = requests.get_request(request.id) ... if first: ... first = False ... print(m.list_id) ... print (f"""
... Sender: {data['_mod_sender']} ... Subject: {data['_mod_subject']} ... Date: {data['_mod_hold_date']} ... Reason: {data['_mod_reason']} ... """) ...
and then to delete the two messages:
(venv) mailman@speedy:~/web/logs$ mailman shell -l sbarc-list@lists.netlojix.com Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the sbarc-list@lists.netlojix.com mailing list >>> requests = IListRequests(m) >>> first = True >>> for request in requests.held_requests: ... key, data = requests.get_request(request.id) ... if first: ... first = False ... print(m.list_id) ... print(f'request id: {request.id}, deleting') ... requests.delete_request(request.id) ... sbarc-list.lists.netlojix.com request id: 27, deleting request id: 28, deleting >>>
The result of this, however, was that the web interface still claimed I had two held messages. I wasn't sure if there was some cron-type "sweeper" process I had to wait to auto-run or if I had to manually do something to create an update. I then realized that the sample script had a ' >>> commit ()" ' at the end, which I'd missed. So, I re-entered the script (but it didn't spit out that it deleted anything this time) and got an error when I did the commit.
Was this in the same mailman shell interaction or a new one? What was
the error?
So, I figured the messages HAD been delete and the commit wasn't really necessary. When I went back to the web interface, the number of held messages was at 0 and I no longer get the original error when clicking on "Held messages", so my issue is solved. But this does leave me with some educational questions:
- Did I affect something somehow with my "commit", or was there a job that cleaned things up (if so, what job)?
I'm not sure of the sequence of events, but I think you probably looked
in Postorius before you quit mailman shell and then you quit mailman shell with ctrl-D which did an implicit commit.
- Is the "commit" even necessary (I saw it in someone else's script in the thread)?
It is necessary to explicitly commit() or quit with ctrl-D to actually update the database.
- Is there a way to save a script and then execute it via shell rather than typing it in every time (it appears from the examples that people are typing them in every time, which is super tedious; I didn't paste for fear of doing something damaging, but maybe that would work)?
Yes, you can save a script in the bin/ directory in your venv and run it
with mailman shell -r. See mailman shell --details.
- Are the request.id's of the messages dynamic/changing, or are they fixed for life? I thought I'd delete based on exact request.id without looping but I was afraid maybe they were changing over time and that this wouldn't be a good idea. Might be nice to know for the future.
The request.id is constant for that request object. The request object is fixed for a specific held message request. I.e., a specific held message's request object and its request.id and other attributes are fixed until that request is handled.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan