+participation oops because membership and teamparticipation disagree

[Curtis Hovey]

OOPS-1897H1320 https://launchpad.net/~sinzui/+participation
    Module lp.registry.browser.person, line 3315, in active_participations
        paths, memberships = self.context.getPathsToTeams()
    Module lp.registry.model.person, line 2359, in getPathsToTeams
        step = graph[step]

KeyError: <Person at 0x145e5650 ubuntu-translations-coordinators (Ubuntu Translations Coordinators)
OOPS-1897M1166 https://launchpad.net/~ubuntu-translations-coordinators
    Module lp.registry.model.person, line 977, in _getDirectMemberIParticipateIn
        % dict(person=self.name, team=team.name))
        AssertionError: sinzui is an indirect member of ubuntu-translations-coordinators but sinzui is not a participant in any direct member of ubuntu-translations-coordinators

I may be able to fix this by joining or leaving teams which will update TP.

[Curtis Hovey (sinzui)]

A few days ago, I noticed that ~rosetta-admins owned (or was an admin of) many translation teams. It was showing up in my +participation page and they were listed in the teams I can subscribe to bugs. I asked Henning about this and he agreed that was wrong. I was going to remove them when I saw most were already removed. All except these 3:
    https://launchpad.net/~launchpad-translators Launchpad Translators
    https://launchpad.net/~translation-standards-devel Translation Standards Developers
    https://launchpad.net/~ubuntu-l10n-shn Ubuntu Shah Translators

How was ~rosetta-admins removed from owner, admin, or member of those teams? The retractTeamMembership() call over the API and the self-removal action for a teams +membership page are the only two ways I know to do this.

[Curtis Hovey (sinzui)]

Hi Henning.

Can you provide more information about what happened to ~rosetta-admins memberships, admins, and ownerships?

[Curtis Hovey (sinzui)]

I think fixing the membership in https://launchpad.net/~rosetta-admins/+participation will fix the data, but I still want to know how the data became corrupt.

[Curtis Hovey (sinzui)]

I think this data error was introduced on 2011-03-12 because staging is not broken. I can see from
https://launchpad.net/~ubuntu-translations-coordinators how I was a member.
    Curtis Hovey → Canonical Launchpad Engineering → Launchpad Translations Administrators → Ubuntu Translations Coordinators
which translates too
   ~sinzui -> ~launchpad -> ~rosetta-admins -> ~ubuntu-translations-coordinators

I can see that ~rosetta-admins are still admins of ~ubuntu-translations-coordinators
    https://launchpad.net/~ubuntu-translations-coordinators/+members
but
    https://staging.launchpad.net/~ubuntu-translations-coordinators/+members
shows that all the former members are gone! We do not delete TeamMembership records, so this looks like an impossibility. I could imaging an issue with a team merger, but these former members are users, and they are quite famous in Lp...we would know if they went missing.

Compare
    https://staging.launchpad.net/~rosetta-admins/+members
with
    https://launchpad.net/~rosetta-admins/+members
I see that Launchpad Community Help Rotation team (~launchpad-chr) was removed. Oh, it was deleted.

Team delete is actually merge into ~registry. ~launchpad was a direct member of both teams. I think the merge rules did more reassignment that it should have. All members are removed first, so there should not have been an TP entries for the users before the actual merge. If there was entries left behind, I think merge certainly would corrupt TP.

[Curtis Hovey (sinzui)]

I think the issue is Person.deactivateAllMembers() This method was called many steps before merge was called to ensure there were no TP entries for the team. This method does a simple delete of TP based on the active membership. It does not recursively check if the user has an other path to participation in a team via another team membership.

TeamMembership._cleanTeamParticipation does does build a exclude list of participation entries. The fix might be to replace the custom query with a call to TM._cleanTeamParticipation(child, parent). I see store.invalidate() is called twice; I think once will suffice. The final storm call to remove the direct participants may not be needed either.

[Curtis Hovey (sinzui)]

Deactivating ~launchpad from ~rosetta-admin, then re-inviting it fixed the members of the ~launchpad team. Three previous members were added back to ~launchpad then removed to correct their TP entries. Now the code can be fixed.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r12620 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12620>.