[Bug 517762] [PMI] clean up nodes with user reference on account removal
| Bugzilla Link | 517762 |
| Status | NEW |
| Importance | P3 normal |
| Reported | Jun 02, 2017 18:00 EDT |
| Modified | Sep 16, 2021 17:26 EDT |
| Blocks | 517648 |
| Reporter | Darrell Armstrong |
Description
when an account is removed, this leaves references to the uid that no longer exists.
a few options for this.
-
ProjectRole node type author can be set to the user as they don't have edit access to this type. This should remove it on user_delete. This has the same downside as the next, which will may need to be implemented anyways.
-
hook_user_delete. Manually sponge out nodes with fields of user reference.
caveats
- You can still have invalid uid's if they are removed directly from the db
- Will need to be updated if additional types are added or removed.
- cron script to perform period sanity scrub.
- will also need to be updated for changes
- time delay, depending on frequency
Designs
Relates to
- #163PMI 2.02
Activity
assigned to @epoirier
added bugzilla legacy projects.eclipse.org labels
This is the patch that Darrell worked on a few months ago:
https://foundation.eclipse.org/r/#/c/1659
It cleans up nodes of type Projectrole_type that have been created in the past that contains users that have been deleted.
We should be doing the same for Elections and ProjectRole.
We should also use (for each of those modules) hook_user_delete so when a user is deleted.
Basically, each modules should be able to clean themselves on their own.
-
After discussion with Wayne, we need to keep records of Election nodes even if the Nominee or the Nominator is not an existing user on projects.eclipse.org.
Wayne suggested that when we encounter an election that contains a nominator or a nominee that doesn't exist anymore on the PMI, we simply replace that user with the Default user (webdev). But we also need to keep a record of the original Election. It is true that in the revision we can find out what user has started the Election, but we only have the uid. Which doesn't help much if the user has been deleted from the site.
Chris suggested that we could create fields in the Election content type to store the Original Nominator and the Original Nominee's full name and email address. This way if, for example, the Nominated By field (which is a user reference field) gets updated with the Default user, we still have record of the Original user.
(In reply to Eric Poirier from comment #2)
Chris suggested that we could create fields in the Election content type to store the Original Nominator and the Original Nominee's full name and email address. This way if, for example, the Nominated By field (which is a user reference field) gets updated with the Default user, we still have record of the Original user.
I would also include the username of the user at the time of the nomination.
-
To keep the discussion all in one place, here are some comments from Wayne on a patch review:
Question: Let's say for past elections, nominators that have been deleted from the site, can we simply put webdev as the nominators? Or for record purposes, it?s valuable to keep the name of the user that originally submitted the election?
It's pretty important that we keep proper track of nominators and committers.
Note that the nominator is also represented in the votes. If you're concerned about nominators turning out to be bogus accounts, then you'll also have to consider that voters can be bogus.
Frankly, however, if we ever discover that a nominator or voter is bogus, we probably have a bigger problem that will warrant some investigation.
For somebody to nominate a developer, they have to themselves be a committer. To be a committer, they must have be provisioned by the webmaster. It is during provisioning that that the webmaster normalizes the committer credentials and just generally ensures that the record in our database represents a specific individual. When that record is created, so should a PeopleProject record; that combination of records should then exist forever (both in the foundation database and in places where it has been replicated, like the PMI).
In some cases, we do end up with multiple records for an individual. This can happen, for example, if somebody signs the ECA using a different email address than what's used on their committer account. When we detect this, we merge the bogus record into the committer record. The committer record should be, therefore, always right. Again, if it's not, then we have a bigger problem that needs to be investigated.
I recall two cases where we've changed the committer id. This is a potentially ugly corner case that can have a ripple effect. We'll need to pay attention to this.
So, this is a (relatively) long way for me to say that it's extremely unlikely that an election nominator would ever be discovered to be bogus and need to be deleted.
If you ever do detect this situation, I'd really like to know about it.
Given that it's a corner case, it seems reasonable to me that we just switch it to a default user. I think that Chris said that we can make it be literally "nobody". (In reply to Eric Poirier from comment #2)
Chris suggested that we could create fields in the Election content type to store the Original Nominator and the Original Nominee's full name and email address. This way if, for example, the Nominated By field (which is a user reference field) gets updated with the Default user, we still have record of the Original user.
I'm pretty sure that this is a corner case that we should almost never see (for reasons that I've already outlined).
The election behaviour creates a new revision on every vote (including the implied vote with the initial nomination). When a committer votes, a statement like "wbeaton registered their vote." is recorded as the revision message. This was a bit of an experiment, so I didn't put all that much thought into the form or what was captured. "wbeaton" was enough for me at the time.
It is enough, IMHO, that we just record a bit of extra information in the log rather than create new fields that we'll have to either hide or otherwise sort out how to deal with.
-
(In reply to Wayne Beaton from comment #5)
(In reply to Eric Poirier from comment #2)
Chris suggested that we could create fields in the Election content type to store the Original Nominator and the Original Nominee's full name and email address. This way if, for example, the Nominated By field (which is a user reference field) gets updated with the Default user, we still have record of the Original user.\
I'm pretty sure that this is a corner case that we should almost never see (for reasons that I've already outlined).\
The election behaviour creates a new revision on every vote (including the implied vote with the initial nomination). When a committer votes, a statement like "wbeaton registered their vote." is recorded as the revision message. This was a bit of an experiment, so I didn't put all that much thought into the form or what was captured. "wbeaton" was enough for me at the time. \
It is enough, IMHO, that we just record a bit of extra information in the log rather than create new fields that we'll have to either hide or otherwise sort out how to deal with.
I agree.
I did a test locally by deleting the user that created the election and the full name of the user got replaced by Anonymous if we decide to reassign the user's content to anonymous. But we still have the username. I'll upload an image shortly.
I'm noticing that the very first revision doesn't contain any comments. Maybe that would be an improvement that we could make as well as adding more information about the user in the comment (username, full name, email address).
The first revision could also contain the nominee's information as well. In the case that it would become a bogus user overtime and we replace it with webdev or anonymous.
For example: [Nominator's Full Name] (email@email.org - username) nominated [Nominee's Full Name] (email@email.org - username) to be a Project Lead on [Project Name]
I also did some tests on user reference fields and if we delete a user that is being referenced in a node, the user's name just disappear in the node view and doesn't break the page.
-
Created attachment 270259 Election revisions
Screen Shot 2017-09-19 at 8.35.20 AM.png -
(In reply to Eric Poirier from comment #6)\
I also did some tests on user reference fields and if we delete a user that is being referenced in a node, the user's name just disappear in the node view and doesn't break the page.
Correction: On Election nodes, the page breaks. It tries to get the none existent user with getFullName(). But on Project Proposals nodes the page doesn't break.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.
If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
--
The automated Eclipse Genie.added to epic &14 (closed)
added statetodo label
removed projects.eclipse.org label
added prioritylow severitylow team:webdev labels
added prioritymedium label and removed prioritylow label
marked this issue as related to #163 (closed)
removed from epic &14 (closed)
