Hi Sonika
I am cross-posting and setting Reply-To to mailman-developers. People who want to discuss the user experience for this feature are welcome to override and continue here, but the primary purpose of this thread seems to be implementation, so mailman-developers seems more appropriate.
You're welcome to post here, but most implementation discussions are taking place on mailman-developers@python.org. The advantage to posting here is primarily when you are hoping for information about how popular a feature is, or what users (mostly admins) think about a design choice that affects the user experience.
sonika gutha via Mailman-users writes:
I am exploring the possibility of implementing a *per-list backup and restore feature* for Mailman.
This has been recently requested and seems plausible in general.
I plan to implement this feature in two parts. The main backup and restore logic should live in *Mailman Core*, since that is where the actual list configuration and membership data are stored.
Besides marshaling the information and serializing it to JSON, I think that the initial UI implementation should be done in the mailman utility. The issue is that some of the use cases involve security or reliability issues. For example, consider cloning a list configuration to a new list. This should be restricted to the superuser or domain owners, as others are not allowed to create new lists. Another example, if a list is backed up, and then accidentally deleted, it's possible that the member lists contain addresses that have been deleted. Cleaning that up may require superuser privileges.
My idea is to define a *versioned JSON format* that captures the important per-list data such as list settings, members, owners, moderators, and relevant subscription preferences.
Subscription preferences need care, because they are the property of the subscriber, not the list administrator.
while leaving more complex areas such as archives or other external components out of scope unless they are explicitly expected.
Backing up archives is definitely out of scope. I'm not sure what other "external components" you have in mind.
*Questions:*
- For the first version, what exactly should be included in the per-list backup: only settings and memberships, or also items like templates, ban lists, and member preferences?
Everything accessible from the REST API, as much as possible. Web templates are usually customized in files in the /etc/mailman3 hierarchy, and are site-wide, so those are not in scope.
- Should the main export and restore implementation live in Mailman Core, with Postorius mainly responsible for the UI and workflow?
Yes. These functions need to be accessible from the mailman utility, as there is no guarantee that Postorius is available.
- Is a *versioned JSON format* the preferred choice for the backup file?
By "versioned", do you mean the *format* is versioned, or the *backup* is versioned? In general, I think formats should be versioned because it's cheap to do so and may help in debugging. The backup should be versioned with the SQLAlchemy database schema, and also timestamped. For most use cases, the timestamp is most relevant, but for an old enough backup the database schema could change and should be checked.
- Should restore only support creating or recreating a list from backup, or should it also support restoring into an already existing list?
It should be possible to overwrite settings in an existing list, for example in case of accidental changes, or to share ban lists and templates. Note that this implies partial restores, but that's not in scope for the moment.
The specific use case recently requested was an organization that wants to implement a policy of being able to restore a deleted list for a certain period of time in case there are regrets.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan