Import/Export - Comments by user importing project are incorrectly appended with an 'imported from GitLab project' message

Summary

When importing into a GitLab instance that has the same users (as defined by username and email address), all comments from the user importing the project have the following comment appended:

By Administrator on 2018-09-14T17:56:31 (imported from GitLab project)

Reported in ZenDesk ticket 103561 (internal link), also mentioned in passing in this comment in gitlab-ce#25346.

Steps to reproduce

  1. Create two instances of GitLab, setup identical users on both instances with admin_1 and admin_2 as admins
  2. Export a project from instance_1
  3. Import the project into instance_2 using admin_1
  4. Comments made by admin_1 will have the 'imported' message appended
  5. Import the project into instance_2 a second time using admin_2
  6. Comments from the admin_2 will have the message added, and admin_1 comments will display normally

What is the current bug behavior?

All comments by the user importing a project have the imported message appended despite their profile details matching between instances.

What is the expected correct behavior?

Comments made by users with matching names and/or email addresses in both instances should not have the 'imported' message appended.

Relevant logs and/or screenshots

With root as importer:

Screen_Shot_2018-09-14_at_2.34.31_PM

The same project imported again, but by admin_user:

Screen_Shot_2018-09-14_at_2.33.19_PM

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 
System information
System:		Ubuntu 16.04
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	2.4.4p296
Gem Version:	2.7.6
Bundler Version:1.16.2
Rake Version:	12.3.1
Redis Version:	3.2.11
Git Version:	2.18.0
Sidekiq Version:5.1.3
Go Version:	unknown


GitLab information
Version:	11.3.0-pre
Revision:	6eb7926
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	postgresql
DB Version:	9.6.8
URL:		http://gitlab.wchandler-flame.com
HTTP Clone URL:	http://gitlab.wchandler-flame.com/some-group/some-project.git
SSH Clone URL:	git@gitlab.wchandler-flame.com:some-group/some-project.git
Elasticsearch:	no
Geo:		no
Using LDAP:	no
Using Omniauth:	no


GitLab Shell
Version:	8.1.1
Repository storage paths:
  • default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab Shell ...


GitLab Shell version >= 8.1.1 ? ... OK (8.1.1)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:root, or git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
1/1 ... ok
1/2 ... ok
1/4 ... ok
3/5 ... ok
1/6 ... ok
3/7 ... repository is empty
3/8 ... ok
1/9 ... ok
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK


Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Sidekiq ...


Running? ... yes
Number of Sidekiq processes ... 1


Checking Sidekiq ... Finished


Reply by email is disabled in config/gitlab.yml
Checking LDAP ...


LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab ...


Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
1/1 ... yes
1/2 ... yes
1/4 ... yes
3/5 ... yes
1/6 ... yes
3/7 ... yes
3/8 ... yes
1/9 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.4.4)
Git version >= 2.9.5 ? ... yes (2.18.0)
Git user has default SSH configuration? ... yes
Active users: ... 3
Elasticsearch version 5.1 - 5.5? ... skipped (elasticsearch is disabled)


Checking GitLab ... Finished

Possible fixes

It looks like there are two spots in lib/gitlab/import_export/members_mapper.rb that trigger this problem.

Line 21

hash[old_user_id] = existing_user.id if existing_user && add_team_member(member, existing_user)

Here the call to add_team_member returns false for the user performing the import. An 'already exists in source' error is returned when trying to save their ProjectMember object, so persisted? evaluates to false. This occurs because the importing user was already added to the project before map is built by the ensure_default_member! method.

line 36

map.keys.include?(old_author_id) && map[old_author_id] != default_user_id

In the include? method, we check that old_author_id does not match default_user_id. As the user performing the import is the default user, this condition cannot be met and update_note_for_missing_author will always be triggered.

/cc @jameslopez

Edited by Will Chandler (ex-GitLab)