Mihai Moldovan writes:
# mailman-wrapper shell Welcome to the GNU Mailman shell
from mailman.testing.documentation import dump_json from mailman.interfaces.mailinglist import IMailingList from zope.component import getUtility list_manager = getUtility(IListManager) mlist = list_manager.get('x2go-commits@lists.x2go.org') bans = IBanManager(mlist) new_bans = ["really", "long", "list", "with", "addresses", "I'd", "like", "to", "ban"] for new_ban in new_bans: ... bans.ban(new_ban) ... for ban in bans: ... print('{0}: {1}'.format(ban.list_id,ban.email)) ... [long list of bans] exit()
You appear to have missed this line from 'mailman shell's banner:
Exit with ctrl+D does an implicit commit() but exit() does not.> I don't even see any calls to the REST API for each bans.ban()
call. Should I see those?
No. Mailman core does not call the REST API for anything that I know of. It implements the API so that processes on a different node can access Mailman's resources, but the 'mailman' utility is intentionally restricted to the same node.
Or is bans.ban() directly modifying the database?
Yes, but inside a transaction that must be committed.
If that is the case (I'm using sqlite3, nothing fancy), why doesn't it stick? Do I have to commit changes somehow?
Of course somebody has to commit the transaction, and Ctrl-D to exit will do that for you. But there also has to be a way to back out without committing, and we use the more verbose exit() (without preceding commit()) for that.
You might think it should require more effort to do possibly destructive changes than to abort safely, but we've found by experience that the majority of usage of 'shell' and 'withlist' is quite simple, and reports of problems with undesired commits are just about nonexistent.
-- GNU Mailman consultant (installation, migration, customization) Sirus Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan