| 2009-06-30 15:15:23 |
Daniel Holbach |
bug |
|
|
added bug |
| 2009-06-30 15:53:34 |
Curtis Hovey |
launchpad-registry: importance |
Undecided |
Low |
|
| 2009-06-30 15:53:34 |
Curtis Hovey |
launchpad-registry: status |
New |
Triaged |
|
| 2010-05-28 15:33:57 |
Tom Haddon |
tags |
|
canonical-losa-lp |
|
| 2010-08-04 22:48:35 |
Curtis Hovey |
tags |
canonical-losa-lp |
canonical-losa-lp merge-deactivate |
|
| 2011-05-12 17:30:00 |
Curtis Hovey |
launchpad: importance |
Low |
High |
|
| 2011-05-12 17:30:04 |
Curtis Hovey |
tags |
canonical-losa-lp lp-registry merge-deactivate |
404 canonical-losa-lp lp-registry merge-deactivate |
|
| 2011-07-12 14:17:22 |
Max Bowsher |
marked as duplicate |
|
204002 |
|
| 2011-07-12 14:45:07 |
Guilherme Salgado |
removed subscriber Guilherme Salgado |
|
|
|
| 2011-07-12 20:11:47 |
Robert Collins |
removed duplicate marker |
204002 |
|
|
| 2012-01-01 08:27:43 |
Robert Collins |
summary |
~team membership of ~X-merged can not be deactivated |
deleted or merged persons/teams can have memberships left over which cannot be revoked |
|
| 2012-01-01 08:39:21 |
Robert Collins |
description |
~ubuntu-games-merged is member of ~locoteams and I can't remove it.
https://devpad.canonical.com/~matsubara/oops.cgi/2009-06-30/EB121 |
Symptoms
========
Delete user foo (or team foo). Someone else adds foo to a team at the same time. After the delete the user or team will still be in the new team (sometimes).
Diagnosis
=========
When person foo is deleted / merged a job executes to remove all the teams / memberships. This is naturally racey - unless it is delayed longer than the longest possible web transaction, it will not see all newly added memberships, and there are nothing causing contention on common rows, so neither transaction will fail.
The current situation is that we run the update job after most transactions so new occurrences of this should be fairly rare (but short of an audit, not impossible).
Possible solutions
==================
* Run a garbo job looking for memberships of deleted person/teams.
* Ensure that the purge process runs after *all* possible transactions adding membership (and team participation) rows... web ops, scripts, backend jobs.
A garbo job will have progressively slower performance but is simple to implement. |
|
| 2012-12-03 15:51:41 |
Curtis Hovey |
launchpad: assignee |
|
Curtis Hovey (sinzui) |
|
| 2012-12-03 15:51:45 |
Curtis Hovey |
launchpad: importance |
High |
Critical |
|
| 2012-12-03 15:53:46 |
Curtis Hovey |
description |
Symptoms
========
Delete user foo (or team foo). Someone else adds foo to a team at the same time. After the delete the user or team will still be in the new team (sometimes).
Diagnosis
=========
When person foo is deleted / merged a job executes to remove all the teams / memberships. This is naturally racey - unless it is delayed longer than the longest possible web transaction, it will not see all newly added memberships, and there are nothing causing contention on common rows, so neither transaction will fail.
The current situation is that we run the update job after most transactions so new occurrences of this should be fairly rare (but short of an audit, not impossible).
Possible solutions
==================
* Run a garbo job looking for memberships of deleted person/teams.
* Ensure that the purge process runs after *all* possible transactions adding membership (and team participation) rows... web ops, scripts, backend jobs.
A garbo job will have progressively slower performance but is simple to implement. |
Symptoms
========
Delete user foo (or team foo). Someone else adds foo to a team at the same time. After the delete the user or team will still be in the new team (sometimes).
A 403 will be raised if the merged team was private. Even if the team was deactivated,
the +members page can not be viewed by team admins because no one has permission to
view the merged team.
Diagnosis
=========
When person foo is deleted / merged a job executes to remove all the teams / memberships. This is naturally racey - unless it is delayed longer than the longest possible web transaction, it will not see all newly added memberships, and there are nothing causing contention on common rows, so neither transaction will fail.
The current situation is that we run the update job after most transactions so new occurrences of this should be fairly rare (but short of an audit, not impossible).
Possible solutions
==================
* Run a garbo job looking for memberships of deleted person/teams.
* Ensure that the purge process runs after *all* possible transactions adding membership (and team participation) rows... web ops, scripts, backend jobs.
A garbo job will have progressively slower performance but is simple to implement. |
|
| 2012-12-03 15:53:52 |
Curtis Hovey |
tags |
404 canonical-losa-lp lp-registry merge-deactivate |
403 404 canonical-losa-lp lp-registry merge-deactivate |
|
| 2012-12-03 15:54:18 |
Curtis Hovey |
tags |
403 404 canonical-losa-lp lp-registry merge-deactivate |
403 404 canonical-losa-lp lp-registry merge-deactivate privacy teams |
|
| 2012-12-03 18:11:53 |
Loïc Minier |
bug |
|
|
added subscriber Loïc Minier |
| 2012-12-03 19:03:10 |
Curtis Hovey |
launchpad: status |
Triaged |
In Progress |
|
| 2012-12-03 21:57:43 |
Curtis Hovey |
branch linked |
|
lp:~sinzui/launchpad/cleanup-merged-people-1 |
|
| 2012-12-04 16:50:38 |
Launchpad QA Bot |
tags |
403 404 canonical-losa-lp lp-registry merge-deactivate privacy teams |
403 404 canonical-losa-lp lp-registry merge-deactivate privacy qa-needstesting teams |
|
| 2012-12-04 16:50:39 |
Launchpad QA Bot |
launchpad: status |
In Progress |
Fix Committed |
|
| 2012-12-04 19:06:28 |
Curtis Hovey |
tags |
403 404 canonical-losa-lp lp-registry merge-deactivate privacy qa-needstesting teams |
403 404 canonical-losa-lp lp-registry merge-deactivate privacy qa-ok teams |
|
| 2012-12-05 15:29:37 |
Curtis Hovey |
launchpad: status |
Fix Committed |
Fix Released |
|
