klesh commented on issue #8698:
URL: https://github.com/apache/devlake/issues/8698#issuecomment-5300132668

   > I traced this through the code. It is not something you are doing wrong — 
the CSV upload simply cannot link a GitHub account in your situation, and your 
own observation about `gitextractor` vs `_raw_github_graphql_accounts` is 
exactly the tell.
   > 
   > **Why only commit activities appear**
   > 
   > There is exactly one subtask that links users to accounts, 
`ConnectUserAccountsExact` in 
[`backend/plugins/org/tasks/user_account.go`](https://github.com/apache/devlake/blob/main/backend/plugins/org/tasks/user_account.go),
 and it links an account only if one of three exact comparisons hits:
   > 
   > if userId, ok := emails[account.Email]; account.Email != "" && ok {      
// line 79
   > if userId, ok := names[account.FullName]; account.FullName != "" && ok { 
// line 87
   > if userId, ok := names[account.UserName]; account.UserName != "" && ok { 
// line 95
   > where `emails` and `names` are built from the `users.csv` rows (lines 49 
and 52). There is no fuzzy matcher — those three are the whole mechanism.
   > 
   > Now compare what each source puts in the `accounts` row:
   > 
   > * **gitextractor** accounts carry the commit author's email and name, 
taken straight from the git
   >   history. Your `users.csv` email matches that, so the link is made and 
commit activities attribute
   >   correctly.
   > * **GitHub** accounts copy `githubUser.Email`
   >   
([`account_convertor.go:151`](https://github.com/apache/devlake/blob/main/backend/plugins/github/tasks/account_convertor.go#L151)),
   >   and GitHub returns an **empty** email for any user who has not made it 
public — which is the
   >   default. With `account.Email == ""` the first branch is skipped by its 
own guard.
   > 
   > That leaves only the name paths, and `users.csv` has no column for a 
provider login — its fields are just id, name, email and team ids. So the 
GitHub account links only if the GitHub **display name** or **login** happens 
to equal the `Name` in your CSV, character for character. If it does not, the 
GitHub account is never linked, and every PR/review activity, which attributes 
through that account, is missing — while commits keep working. That is 
precisely the split you are seeing.
   > 
   > It also explains why pre-existing users are fine: they were linked when 
their name did match, or via a mapping that already existed. Note line 58 
restricts the scan to `id NOT IN (SELECT account_id FROM user_accounts)`, so 
once an account is linked (or deliberately left unlinked) a later run will not 
revisit it.
   > 
   > **What to do today**
   > 
   > Link the GitHub accounts explicitly rather than relying on the match. 
There is a dedicated endpoint for it:
   > 
   > ```
   > PUT /plugins/org/user_account_mapping.csv
   > ```
   > 
   > `GET` the same path first to get the current mapping in the right shape, 
add a row pairing your user id with the GitHub account id (they look like 
`github:GithubAccount:1:12345678`), and PUT it back. That bypasses the matcher 
completely, and because of the line 58 filter it will also stop the exact 
matcher from trying to claim those accounts later.
   > 
   > **A related defect I will raise separately**
   > 
   > The email comparison is a plain map lookup with no case folding, so a CSV 
address of `[email protected]` will not match an account whose email 
is `[email protected]`. Email addresses are treated 
case-insensitively in practice, and corporate git configs vs provider profiles 
differ in case all the time, so this silently drops links that should be made. 
It is not the cause of your specific problem — your gitextractor link is 
working — but it is the same class of failure and worth fixing.
   > 
   > [@klesh](https://github.com/klesh) if the analysis looks right to you, the 
parts I would consider changing are: fold case when comparing emails, and let 
`users.csv` carry an optional provider login so linkage can be declared instead 
of guessed. Happy to send a PR for the first one now, and to discuss the second.
   
   Thanks for the diligent analysis and thorough explanation. I totally agree 
with the email addresses should be case-insensitive.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to