User Identity Mapping#

DevLake resolves tool-specific identities (GitHub accounts, Jira accounts, GitLab users, etc.) to unified cross-tool users through a three-layer model: plugin-level tool accounts → domain accounts → domain users.

Core Identity Tables#

All three tables live under backend/core/models/domainlayer/crossdomain/:

Domain ID Generation#

Every plugin converter calls DomainIdGenerator to produce a deterministic, globally-unique ID for each account. The format is {pluginName}:{EntityType}:{pk_fields...} — for example github:GithubAccount:1:1234 or jira:JiraAccount:1:629cdf 1. This ensures the same tool entity always resolves to the same domain ID regardless of when it is collected.

How Actor Fields Are Populated in Domain Records#

pull_requests#

The PullRequest domain table stores AuthorId, AuthorName, MergedById, and MergedByName — all set to generated domain Account.Id values, not raw user IDs.

The GitHub PR converter (pr_convertor.go) illustrates the pattern:

1. An accountIdGen is created from models.GithubAccount{}.
2. AuthorId is set via accountIdGen.Generate(connectionId, pr.AuthorId) 2.
3. MergedById follows the same pattern 3.

cicd_deployments and cicd_deployment_commits#

Neither CICDDeployment nor CicdDeploymentCommit carries a dedicated deploying-user field. Deployment actor attribution is not directly stored in these domain tables.

Per-plugin behavior:

• GitHub (GraphQL deployments): The GithubDeployment tool-layer model has no creator/actor column. The GraphQL query does not request the creator field, so there is no triggering-user data in the pipeline 4. The only person-related field available is the commit author from the deployed commit.
• GitHub Actions (workflow runs): The GithubRun model stores the triggering actor login from the API but the cicd_run_convertor.go does not map it to any AuthorId/ActorId in the output CICDPipeline or CiCDPipelineCommit records.
• GitLab deployments: The tool-layer GitlabDeployment model stores rich user data: both the deployable user (DeployableUserID, DeployableUserName, DeployableUserUsername, etc.) and a top-level triggering user (UserID, UserUsername). However, the deployment_convertor.go does not map these fields into CicdDeploymentCommit, so they remain in the tool layer only.
• Azure DevOps builds: The ci_cd_build_converter.go emits CICDPipeline and CiCDPipelineCommit with no actor fields populated.

Account-to-User Resolution#

Resolving accounts → users (populating user_accounts) occurs in two stages 5:

1. Heuristic auto-mapping — The org plugin's connectUserAccountsExact subtask matches accounts to users by email and name similarity.
2. Manual override — Operators download user_account_mapping.csv via the org plugin API, correct or add rows, and re-upload. See Team Configuration for the full walkthrough.

To join tool identities back to real people in SQL 6:

SELECT a.id AS account_id, a.email, a.user_name AS account_user_name,
       u.id AS user_id, u.name AS real_name
FROM accounts a
JOIN user_accounts ua ON a.id = ua.account_id
JOIN users u ON ua.user_id = u.id

Architecture Overview#

Key Source Files#