[Bug][GitHub] Activities not present in worklogs #8698

Activity

1. furlangiacomo

   added

   type/bugThis issue is a bugThis issue is a bug

   on Feb 5, 2026
2. furlangiacomo

   changed the title [-][Bug][Module Name] Bug title[/-] [+][Bug][GitHub] Activities not present in worklogs[/+] on Feb 5, 2026
3. dosubot

   added

   component/pluginsThis issue or PR relates to pluginsThis issue or PR relates to plugins

   on Feb 5, 2026
4. dosubot commented on Feb 5, 2026

   

   dosubotBot

   on Feb 5, 2026 – with DosuBot

   Last edited by dosubot

   More actions

   This happens because after uploading users via /api/rest/plugins/org/users.csv, the new users are not automatically linked to their corresponding accounts in the user-account mapping table. Only commit activities are shown because those are matched by author info, but activities like "Review PR" or "Open a PR" require a proper user-account linkage to appear in work logs.

   To fix this, make sure you also upload a user_account_mapping.csv via the /api/rest/plugins/org/user_account_mapping.csv endpoint after adding new users. This will link users to their accounts and allow all activities to be mapped correctly. Alternatively, you can trigger the user-account linking logic (ConnectUserAccountsExact) to match users and accounts by email, full name, or username. Without this step, only commit activities will show up for new users, while PR-related activities will be missing because the mapping is incomplete see code details and mapping logic.

   After updating the user-account mapping, re-run your data collection or refresh your dashboards to see the full set of activities for the new users.

   To reply, just mention @dosu.

   ---

   Share context across your team and agents. Try Dosu.

   
5. furlangiacomo commented on Feb 5, 2026

   

   furlangiacomo

   on Feb 5, 2026

   Last edited by furlangiacomo

   Author

   More actions

   @dosu the user is present in the user_accounts table with entries in _raw_data_table set to gitextractor. I’ve noticed that for users who have both gitextractor and _raw_github_graphql_accounts, the work logs work as expected.
6. dosubot commented on Feb 5, 2026

   

   dosubotBot

   on Feb 5, 2026 – with DosuBot

   Last edited by dosubot

   More actions

   This happens because PR-related activities (like "Review PR" or "Open a PR") are only mapped to users if there are linked accounts from both gitextractor and GitHub GraphQL in the user_accounts table. The work logs join activities to users by matching account IDs from all relevant sources. If a user only has a gitextractor entry, only commit activities will show up; PR activities require a GitHub GraphQL account link as well.

   To ensure full activity tracking, make sure the GitHub GraphQL plugin has collected account data for your users, and that the ConnectUserAccountsExact task (part of the org plugin) has run to link users and accounts by matching email, full name, or username. This subtask is enabled by default and runs automatically when the org plugin is included in your pipeline, but you can also trigger it manually if needed. No other background job performs this linkage—so if you add users or accounts via CSV, always ensure the mapping step runs to link all relevant accounts for each user. If PR activities are missing, check that the user has both gitextractor and GitHub GraphQL account entries and that their emails or usernames match for linking (source).

   To reply, just mention @dosu.

   ---

   Docs are dead. Just use Dosu.

   
7. furlangiacomo commented on Mar 9, 2026

   

   furlangiacomo

   on Mar 9, 2026

   Author

   More actions

   @klesh, sorry for tagging you directly. Do you have any clue, or am I just doing something wrong?
8. furlangiacomo commented on Jun 15, 2026

   

   furlangiacomo

   on Jun 15, 2026

   Last edited by furlangiacomo

   Author

   More actions

   Can anyone help with this? Thanks!
9. klesh commented on Jun 16, 2026

   

   klesh

   on Jun 16, 2026

   Contributor

   More actions

   @klesh, sorry for tagging you directly. Do you have any clue, or am I just doing something wrong?

   Sorry for the late response, and unfortunately I have no clue either.

   👍React with 👍1Reacted by Giacomo Furlan
10. vbhanuchander-lang commented on Aug 13, 2026

    

    vbhanuchander-lang

    on Aug 13, 2026

    Contributor

    More actions

    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,
    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),
      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
    TyroneKCummings@teleworm.us will not match an account whose email is tyronekcummings@teleworm.us.
    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 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.

    👍React with 👍1Reacted by Klesh Wong
11. klesh commented on Aug 15, 2026

    

    klesh

    on Aug 15, 2026

    Contributor

    More actions

    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, 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),
      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 TyroneKCummings@teleworm.us will not match an account whose email is tyronekcummings@teleworm.us. 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 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.
12. klesh

    added a commit that references this issue on Aug 21, 2026

    fix(org): match account names and logins case-insensitively (#9064)

    ...

    c5a4fb6
13. github-actions commented on Oct 15, 2026

    

    github-actionsBot

    on Oct 15, 2026 – with GitHub Actions

    Contributor

    More actions

    This issue has been automatically marked as stale because it has been inactive for 60 days. It will be closed in next 7 days if no further activity occurs.
14. github-actions

    added

    Stale

    on Oct 15, 2026