Skip to content

BE - Add visual indicators for content imported by direct transfer

Release notes

Problem

GitLab allows copying content of GitLab groups and projects between GitLab instances and within one instance between groups with direct transfer method. This allows for potential security issue with imported content. Imported content is not easily identifiable, which could lead to abuse.

Proposed solution

This issue covers the backend portion. frontend work will be tracked at #443492 (closed)

The proposed solution, a defense-in-depth measure, is to add:

  • a database identifier that serves the frontend
  • a visual indicator to imported records that authorship can be attributed to.

For Direct Transfer that would be:

  • epics
  • events
  • designs
  • issues
  • merge requests
  • notes
  • snippets

This would allow users to quickly identify imported content and help to prevent abuse. It would allow Administrators to more easily clean up abuse, see comment, and give users a signal that the comment / MR / activity they are looking at wasn't made on this instance but was imported from elsewhere.

Besides changing the backend and Direct Transfer to set which resources were imported, the API and GraphQL API should also be updated to expose the information so the frontend can display the visual indicator.

  • Rails Controller
    • Expose the notes imported attribute in the GET /ISSUEABLE_TYPE/ID/discussions.json endpoint (change notes serializer to export the attribute)
  • Rest API / GraphQL
    • Expose the imported_from attribute and imported? state for all relevant resources.

This Draft MR has some of the required API changes. Note: ⚠ the MR wasn't tested thoroughly, so proper testing needs to be performed to make sure nothing breaks

Example console commands

If an Administrator notices weird imports, they could delete imported records by using commands like:

Notable.where(imported: true).destroy_all

Open questions

  • Should the information contain the date of import? (wouldn't that be too crowded and also requiring additional calls to DB?) - Decision Based on the final designs, the date won't be needed.

  • Should we use an enum instead of a boolean to help identify the importer? Or a string from a set of allowed strings? - Decision We will use an enum. The developer can decide the enum references. We won't backfill columns for already created resources. Please note: the column should be of smallint type that uses an integer, rather than a specifically defined postgres enum (these default to the largest/longest enum value and can take up more space than a varchar type. The developer working on the issue can decide whihch importer equals which integer, but the import sources module can be used as a reference.

  • Should we expose the imported attribute of all updated tables or just the ones needed for the frontend? - Decision we will expose the attribute for all tables we've added it to and make it available to the REST and graphql apis.

Intended users

Personas are described at https://about.gitlab.com/handbook/product/personas/

Feature Usage Metrics

Edited by Carla Drago