[go: up one dir, main page]
Skip to content

Don't import contributions of users banned on source

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem

Currently, we import contributions of users banned on the source, but actually don't want to show them on the destination.

Differences between banned and blocked users

Blocked Users:

Access to the GitLab instance is denied
Their data and contributions remain visible to others
Their account still exists in the system
Typically used when you want to prevent access but retain historical context (like for ex-employees)

Banned Users:

Access to the GitLab instance is denied
Their activity and contributions are hidden from the instance
Their spam or inappropriate content is removed from public view
Used for users who post spam or violate terms of service

Given that the contributions of banned users become automatically hidden, it makes sense that we shouldn't import these as it's effectively as though they don't exist.

Proposed solution

1. Update how user contribution relation is exported.

The user contribution relation should be updated to include users state.

The relation should be exported by scanning all exported tables for unique user IDs.

For the list of exported tables that has user_ids, we can use Import::PlaceholderReferences::AliasResolver as reference.

Most tables have a sharding key already implemented, so in most cases, we can obtain the list of users by filtering the table rows by project_id or group_id.

For example, we would fetch the user IDs by performing queries like:

  • MergeRequest.where(target_project_id: ID).pluck(:author_id)
  • Issue.where(project_id: ID).pluck(:author_id)

Note that the queries above are just an example. We should make sure the queries have good performance.

Some tables still lack a sharding key, which would complicate the query.

2. Update Direct Transfer to use the user_contributions relation

Update Direct Transfer to have a new pipeline that downloads the user_contributions and store the details on Redis.

The pipeline should only be executed on new Gitlab versions.

3. Update Direct Transfer to use the details saved on Redis

Update Direct Transfer to created the placeholder users using the details saved on Redis.

4. Update Direct Transfer to skip banned users

Update Direct Transfer to skip contributions from banned users

Previous proposed solution

We should allow DT to import contributions by banned users if the importing Owner chooses to import those contributions.

In DT UI add an additional check box on the page where groups are selected for import, next to Import user memberships, disabled by default, with short explanation in tooltip and link to docs.

Checkbox:

Import banned contributions

Tooltip:

Select whether contributions from banned users are imported.

In Direct Transfer's API, the user should be able to pass an optional value (defaulting to false) indicating that they want the banned contributions to be included.

Filter based on users' exported state across all of the exported relations - if they's banned, don't import, unless the Owner explicitly wants it.

Use Update Direct Transfer to skip banned user cont... (!185459 - closed) as reference, there we check if the project creator's state is banned and we skip the project entirely, if migrate_banned_contributions is false.

Review threads !185459 (comment 2437705870) and !185459 (comment 2442283755) before refinement.

Docs

Document this in UCM docs.

Edited by 🤖 GitLab Bot 🤖