Allow group owner to delete Placeholder Users that are Awaiting Reassignment via CSV
<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=519391) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=519391) </details> <!--IssueSummary end--> ### About With user mapping, imports generate Placeholder Users that will appear in the top-level group's **Manage > Members > Placeholders (tab)** section. ### Problem There is currently no way for a group owner to delete these entries. The results of any test imports, for example, will appear in this section permanently. ### Proposal Allow group owners to delete entries in their **Manage > Members > Placeholders (tab)** section if their reassignment status is "not started". This issue will provide CSV support. https://gitlab.com/gitlab-org/gitlab/-/issues/537340 will add support for UI separately. Add an extra column to the CSV mapping file that would allow a person to signal per user/row whether to "delete placeholders". e.g. ```csv <existing columns...>,Delete placeholder <existing columns...>,yes ``` When parsing the CSV, if a row has `GitLab username,GitLab public email` completed, or has `Keep as placeholder` set to true (feature being added in https://gitlab.com/gitlab-org/gitlab/-/issues/535229), we should skip processing that line and add to our list of errors. Because people may enter anything into this new column, we should parse its content using [`Gitlab::Utils.to_boolean`](https://gitlab.com/gitlab-org/gitlab/-/blob/101078dbbea74e77be827a6912aefff0da04daca/gems/gitlab-utils/lib/gitlab/utils.rb#L81-84) - so people could enter any of the following values to signal "true" for the column: `true`, `t`, `yes`, `y`, `1`, `on`. We should write a new service to do the deletion as we will reuse the service in https://gitlab.com/gitlab-org/gitlab/-/issues/537340. The service would be called from [`BulkReassignFromCsvService#process_line`](https://gitlab.com/gitlab-org/gitlab/-/blob/cf3a756f347fb08847e61e25fbb89c9e8e14e86b/app/services/import/source_users/bulk_reassign_from_csv_service.rb#L84) when processing the CSV data. The service would: - Validate that the current user can delete the `Import::SourceUser` record - Validate that the `Import::SourceUser` record is in [`pending_reassignment` status](https://gitlab.com/gitlab-org/gitlab/-/blob/452e94aaa6f4278b277b44abe5119c7bbb5b42b0/app/models/import/source_user.rb#L51). - Delete the placeholder `User` record (using `#delete_async` in the same was as we do [here](https://gitlab.com/gitlab-org/gitlab/-/blob/a7025a32ccb33f2bad0a4809d2c23f85bed3596e/app/workers/import/delete_placeholder_user_worker.rb#L21-24)). - `Import::SourceUser` record for that placeholder user would be deleted (this would delete the related placeholder user reference data in `import_placeholder_memberships` and `import_source_user_placeholder_references` due to `ON CASCADE DELETE` foreign keys, and so could in a small way contribute to https://gitlab.com/groups/gitlab-org/-/epics/17248). - Return `ServiceResponse` objects for success or failure We should add ~documentation of the new CSV capabilities. The documentation should include full warnings of what the effects on imported data would need to be given. Roughly the effects would be 1) certain records associated with the placeholder user would be associated with the GitLab ghost user and 2) certain other records may continue to exist and would be unable to be reassigned. Note: As pointed out [here](https://gitlab.com/gitlab-org/gitlab/-/issues/519391#note_2477685528), users can already upload the CSV 3x times, with the 3 scenarios broken down into 3 CSV files. Perhaps it's not obvious to user that they can do it, so we can consider if we should document it or not. I think we say already that not all CSV rows need to be completed to upload the CSV. ### Question Should we only allow this to happen if the placeholder `User` has no associations with other data (like [this check](https://gitlab.com/gitlab-org/gitlab/-/blob/68464d2e4a9fce3697240f64bf0688723a7cdf28/app/workers/import/delete_placeholder_user_worker.rb#L38-45)) - returning a failure message for this action if there are. Group owners should ideally delete relevant projects and groups before deleting the associated placeholder.
issue