@username autocomplete displays unauthorized users (BB-7840)

Issue #6672 resolved
Derrick Johnson
created an issue

For projects with access restricted to only a team, the pull request's assignee field should only show the team members. Current behavior is to show any matching user, seemingly autocompleting from some global Bitbucket user list.

Although autocompleting an unauthorized user isn't allowed (Bitbucket properly says "John Smith does not have access to view this pull request"), it's still disconcerting to see total strangers pop up in the autocomplete list.

To duplicate, create a pull request (for a restricted access project) and slowly type in a few characters in the assignee field. You should see unauthorized users show up.

Comments (49)

  1. Dylan Etkin

    Hi Derrick,

    This is true. As a social coding site we need to expose all users.

    To try to address your concerns we cache the users that you have chosen and display them to you first.

    We also differentiate users with a Team Member badge to help distinguish them.



  2. Roel van der Kraan

    I'm not sure I understand why users that are not in my team are shown on my private repositories. I cannot even add them as a pull request reviewer because they have no right to. Please show my teammates first, also for shorter search queries. I know have to type at least 4-5 chars to find them.

  3. Chetan Vaity

    I agree with the people here. Autocomplete should show only Team Members for private repos. Also, sometimes I simply cannot add a user as a reviewer because the autosuggest does not bring him up. This is broken :-(

  4. Nicolas Venegas

    From #7793

    At the moment, the query for users in autocomplete will search across all Bitbucket users. If your teammates happen to be in the list of results that match the query, we surface them to the top.

    It would be preferable to first search only your teammates. If there are not enough results, then we should fall back to searching the entire Bitbucket user base. Alternatively, we could provide an option (checkbox, perhaps) to limit the search to only your teammates.

  5. dbtoronto

    As a social coding site we need to expose all users

    Atlassian is now forcing companies and corporates to use Bitbucket (instead of hosted Fisheye). The companies and corporates do not want to be social, they instead want full privacy. Bitbucket on the other hand is adamant to be open and public (also see #5599).

    I think Atlassian needs to make a call here, if Bitbucket is only for open-source and individual developers or if they want to have a good offering for private teams too. Stash is not an option because it is not hosted.

  6. Nicolas Venegas

    Today I deployed a fix to make the query always rank teammates above everyone else, so the user autocomplete should give much more relevant results.

    Please let me know if you experience problems with it.

  7. Dan Loewenherz

    I guess I might be confused as to what constitutes a teammate. In a certain project I'm working on, 3 users have access, not including me. Only 1 of them comes up in the teammate autocomplete.

  8. Dan Loewenherz

    Hmm, I'm not getting it. I think it makes more sense for it to be repo-based. I might have a huge team, but only have a small subset who have access or who are working on the repo at-hand.

    My preference would be to only autocomplete users who have access to the repo, even if they aren't a part of the team who owns the repo. Likewise, users who are a part of the team but do not have access to the repo should not appear. It doesn't make sense to reference a user if they can't read the comment/pull request/etc they were referenced in.

  9. Dan Loewenherz

    To elaborate--I think the currently autocompleting tactic works for public repos, since everyone can access those. It's the private ones that my previous comment applies to.

  10. Anthony Wu

    Just wanted to echo the other comments here that the current auto-complete behavior for private repos is annoying. It's bad UI and leads to actions that are clearly not the user's intent. I don't understand why I'd need to cc anyone who does not have private access to our repo...

  11. Emilien Coquard

    +1, for private repos only users that are authorized should be available in the typeahead.

    Or at least it should be available as an option.

    We are a software development agency and we use Bitbucket for commercial and closed source projects and products. In this setup, the “social coding” notion should be restricted to the member of our Bitbucket teams.

  12. Anthony Wu

    I honestly can't understand why this isn't higher priority to be resolved. It's one of the most nagging non-features on the site. Keep it social strictly within the organization on private repos, it makes all the sense in the world. There has been so may mis-autocompleted reviewer entries that it's starting to piss off my team.

  13. Edward Wang

    agree with most of comments above, it's beyond me that this is even a debatable topic! I mean other than annoying us users, what the points to show a whole lot of strangers?! The whole point of private repo is being private, come on! if Atlassian guys really want to be cute, add a checkbox (unchecked by default!) said "Include the world" or something like that, which I guarantee that nobody beside Atlassian programmers will ever click.

  14. Peter Abramowitsch

    Definitely the reviewer list needs to be restricted to the team members. The minute you include a reviewer who is not in your team, your code is exposed and the notion of a private repository loses its meaning. If you temporarily need an 'outside reviewer' then add him/her as a team member with R/O access and remove the member after the review closes.

  15. James Jensen

    @Peter Abramowitsch and @Edward Wang This defect does not actually expose your code to anyone: if you select someone who does not have access to the repository, it will fail to add them as a reviewer. This is purely a matter of convenience and professionalism: we should not have to sift through all of BitBucket's users, when we can only actually choose from among a handful of them.

  16. Anthony Wu

    Many a F-bomb has been dropped in our office for this unfortunate feature. Another user case to think about, an individual may have different username handles across services. Sometimes I accidentally use a teammates's non-BitBucket username on reflex and muscle memory, and hits enter too quickly, auto-completing to a complete stranger. When making a decision of whether to keep/remove this feature, I think it should be centered on how real users are likely to use or mis-use it.

  17. Kevin O'Connor

    I don't think that the fix @Nicolas Venegas made is enough. The big issue being that if you're a part of multiple teams, any teammates are ranked to the top. This is an issue for me since these two teams are completely separate with private repos.

    There really needs to be a flag on repo settings to completely isolate a private repo to users with authorized access to it. It is way too easy for a mistake to be made with the current implementation. Maybe something like levels (ex. World, Team (but only the team that owns the repo), Internal (authorized users only)) would be a better implementation of this. This should then be honored across the application for that specific repo to properly scope that exposure of a private repo.

    If not that then at least make the teammate lookup be restricted to only teammates on the team that owns the repo. Doing cross-team lookups doesn't make sense to me.

  18. James Jensen

    @Kevin O'Connor is right, except that this doesn't even need to be a flag on the repo settings. The business logic has already been decided: If you try to click on a reviewer that doesn't have rights, Bitbucket will disallow it. There is no justifiable reason I can think of to show names in search results which will then be rejected if you choose them.

  19. Scott Plumlee

    We've just transitioned over to Bitbucket from Github, and this issue is enough to make me put moving back on the table. Please give an option or a default to make the list ONLY surface users with access to the repo. It's a poor use of developer time and energy to have to mentally sift through extra user names, and it's a strange design choice given that a flag has already been set that this repo is limited to a certain number of users by the fact that it's private. The arguments given by Atlassian in favor of the current design seem to be that you've added extra UI elements or business logic to indicate which users you might want or to prevent wrong users from being selected, when all the commenters agree we want a list that's already properly filtered so we don't risk making an incorrect choice in the first place.

  20. Rob Teegarden

    Why has this been going on for over a year? Make it a config setting if you don't want to remove the public search, let the admins configure it on each repository. I mean really, how hard would it be to give the option to do either?

  21. James Jensen

    @Rob Teegarden Config points add complexity, which adds maintenance costs. In this case, there is zero reason to have names appear in auto-complete which cannot actually be selected. It should not be configurable: it should be changed for everyone.

  22. Matthew Jewell

    Agreed with the gist above, it makes absolutely no sense to have this level of "openness" in a private repository. @Scott Plumlee nailed it.

    From a business point of view it architectures an idea of insecurity in the repo, even if this is not the case. A private system need also be a closed one, in this case.

  23. Davis Hernandez

    I agree, no matter if this have a social media approach, other social media doesn't show unknown people when you work with your private post, it show only your friends list, only when your are browsing for new friends it can show you those unknown people. So if you are working in a Private context, you should only show the people that have permission to this private group.

    No matter if at the end this other users can't access your private repository, its a security issue that you already told someone that you have code here, plus the right person will not be notified on time.

  24. James Jensen

    @Davis Hernandez Just to clarify: the UI doesn't actually allow you to add people as reviewers if they don't have rights. The moment you select their name, you get immediate feedback that it didn't work.

    This is purely a usability issue, making people see and sift through countless options in a menu when they're only able to actually select a small subset of those options.

  25. Marcus Bertrand staff

    This week, we have released a change to our Pull Requests that now filter the reviewers list to only users who have at least read access to the destination repository. If you encounter any issues with this new behavior, please notify us in support@bitbucket.org.

    Cheers, The Bitbucket Team

  26. Tim Dawson

    great to hear this was fixed for pull requests.

    Can we implement this functionality in the issue tracker as well? Or if it must remain for 'social' reasons, hide it behind an extra 'show global users' ui.

  27. Log in to comment