should be a way to delete/disconnect a mailing list

[Barry Warsaw]

There are certain situations where the blockers on a team having a mailing list need to be overridden. For example, to merge the obsolete team ~infinity.developers into registry, Person.merge() needs to bypass the check for the from_person having a mailing list.

I think the way to do this is to either delete the MailingList database row (and all the constraints that will trigger), or to add a status to MailingList, something like RETIRED, which will allow those checks to be bypassed. The check should use a method on IMailingListSet, or an argument to .get(). instead of a direct check.

[Francis J. Lacoste (flacoste)]

Will be fixed post-1.2.6

[Barry Warsaw (barry)]

Some of the existing MailingListStatus values should indicate that it's safe to do renaming and merging operations. For exmaple, DECLINED pretty much guarantees that there's no mailing list on the MM side. INACTIVE does too, though there will be a tarball artifact. FAILED very likely means there is no list on the MM side (though part of the creation could have failed).

For a list in at least these three states, it should be fine to perform the rename or merge operation. The checks in the code should be changed to both check to see if the MailingList for the team does not exist, or if it's in one of those three states. On a rename in one of these states, it's probably fine to just delete the MailingList row, though there may have to be other tables to update (MessageApproval) comes to mind. For INACTIVE and FAILED, a XMLRPC command probably needs to be issued: PURGE to ensure that no lingering artifacts exists. Does the PURGE need to be acknowledged? (What if it fails?)

Adding the basic infrastructure for this would allow us to possibly also address question 41393 by exposing a different u/i for the LP admin. The LP admin should be able to go to a team with a list in DECLINED state, and remove the MailingList row, thus allowing for it to be reapplied for. We don't want to do this automatically, because presumably if a list has been declined, it was for a good reason and we don't want to allow team admins to just annoy the LP admins with repeated requests.

[Barry Warsaw (barry)]

REGISTERED state is probably safe as well.

[Barry Warsaw (barry)]

Pre-impl with Curtis, who brought up an excellent point. We can greatly
simplify things, and kill two birds with one stone, if we don't try to
automate the purging on the Mailman side. Thus the implementation proceeds
like so:

- provide a script that the LOSAs can run on Mailman to purge the mailing list
  artifacts

- provide a button on the team's Manage mailing list page (accessible to LP
  admins and mailing list experts) that allows them to Purge the mailing
  list. This latter button deletes[*] all traces of the list on the LP side,
  but doesn't care at all about coordinating with Mailman. Thus, as far as LP
  is concerned, the merge operation can occur.

[*] I think we may want to add a new PURGED state instead of deleting the
row. The reason is that there may be MessageApproval entries pointing to this
mailing list. A person's standing depends on these, so we'd like not to
affect standing when a list is purged.

The other bird this kills is bug 255845, by allowing a re-request for any
mailing list in the PURGED state.

[Barry Warsaw (barry)]

One other note: a deactivated list has an archive, so this should be considered an artifact that needs to be cleaned up before the list can be purged.

[Steve McInerney (spm)]

Barry, is this now fixed?
In that we still get blocked on "deleting" old and unwanted teams by existing lists.
I assume this is the 'artifact that needs to be cleaned up' bit you mention above? If so, can we have some magic juju to outline howto do such a clean-up?

[Barry Warsaw (barry)]

Yep, this is fixed now. I'm not sure where the best place to capture this howto is but here are the steps:

1. If the team in question has a mailing list, go to the Configure mailing list link and deactivate the list. All ~mailing-list-experts have this permission and ~launchpad is a member of ~mailing-list-experts.

2. Once the mailing list is fully deactivated, go back to Configure mailing list and click on Purge. This breaks the link between the team and the mailing list.

3. You're now free to nuke the team.