should be a way to delete/disconnect a mailing list

Bug #237210 reported by Barry Warsaw
Affects Status Importance Assigned to Milestone
Launchpad itself
Barry Warsaw

Bug Description

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.

Barry Warsaw (barry)
Changed in launchpad:
assignee: nobody → barry
importance: Undecided → High
milestone: none → 1.2.6
status: New → Confirmed
Revision history for this message
Francis J. Lacoste (flacoste) wrote :

Will be fixed post-1.2.6

Changed in launchpad:
milestone: 1.2.6 → none
Revision history for this message
Barry Warsaw (barry) wrote :

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.

Revision history for this message
Barry Warsaw (barry) wrote :

REGISTERED state is probably safe as well.

Revision history for this message
Barry Warsaw (barry) wrote :

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

- 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)
Changed in launchpad:
milestone: none → 2.1.9
status: Confirmed → In Progress
Revision history for this message
Barry Warsaw (barry) wrote :

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.

Barry Warsaw (barry)
Changed in launchpad-foundations:
status: In Progress → Fix Committed
Barry Warsaw (barry)
Changed in launchpad-foundations:
status: Fix Committed → Fix Released
Revision history for this message
Steve McInerney (spm) wrote :

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?

Revision history for this message
Barry Warsaw (barry) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions