Run cronscripts/check-teamparticipation.py on production and make its output more visible
Bug #597208 reported by
Guilherme Salgado
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Fix Released
|
Low
|
Unassigned | ||
Bug Description
That script checks for inconsistencies between the TeamParticipation and TeamMembership tables but currently we only run it as part of the staging_restore.sh cronjob. We should run it on production and make its output more visible by sending it as a separate email to launchpad-
If we don't do that, one has to dig through the (huge) email report from staging_restore.sh to find the teamparticipation checks, which look like this:
Tue Jun 22 04:32:03 BST 2010 Check team participation
2010-06-22 03:32:30 WARNING Some people/teams are not members of themselves: [(1043028, u'removed1043028')]
BTW, before we set it up on production, it's probably a good idea to delete the Person entry with ID 1043028.
| Changed in launchpad-foundations: | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
Revision history for this message
| Guilherme Salgado (salgado) wrote | #1 |
| affects: | launchpad-foundations → launchpad-registry |
Revision history for this message
| Curtis Hovey (sinzui) wrote | #2 |
| Changed in launchpad-registry: | |
| importance: | Medium → Low |
| tags: | added: teams |
| Changed in launchpad: | |
| status: | Triaged → Fix Released |
To post a comment you must log in.
A recent run of the script is showing a bunch of spurious team participation records: https:/
They might have been caused by recent changes to the code which maintains TeamParticipation as this is something we haven't seen in the past.