<!--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> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=506834) </details> <!--IssueSummary end--> The following discussion from !165855 should be addressed: - [ ] @SamWord started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/165855#note_2233031871): (+1 comment) > I noticed there was a placeholder user I didn't add. > > It turns out I made a bitbucket server for myself a while ago, so I had an open pull request for some time. I guess after 21 weeks Bitbucket server just declines an open PR, but does so with a system user that gets imported as a placeholder > >  > >  > > Should those users be handled differently? It's like some kind of system user that doesn't make sense to map to a real user IMO. ## Implementation suggestion Bitbucket Server provides a user type in the API response. This is also included in the user data we get in API responses for things like pull requests. ```bash curl http://user:pass@localhost:7990/rest/api/latest/users/bitbucket.system-user ``` ```json { "name": "bitbucket.system-user", "active": true, "displayName": "Bitbucket", "id": 1, "slug": "bitbucket.system-user", "type": "SERVICE", "links": { "self": [ { "href": "http://localhost:7990/bots/bitbucket.system-user" } ] } } ``` We could: - Add this field to the user representation. - Pass the field to `UserFinder#uid` / `UserFinder#author_id` - If `type == "SERVICE"`, return the service user. - Skip pushing references to service users.