• Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      There was a previous suggestion to add unlisted repositories in 2013, but it was somewhat flawed in my opinion, so I decided to recreate it to evoke discussion of the matter.
      I would have a lot of use out of this (for instance, placing on a resume or portfolio while still maintaining project secrecy and/or privacy.)

      The suggested way of going about this is adding an option to add an 'Everyone' or 'Anonymous' principal to the repository's access settings. We could then grant or deny view access.

      As previously stated, this option would only be available for repositories already marked Private, and if the repository is made Public, the existing setting won't be removed, but will also have no effect. However, to avoid potential abuses of people using this to bypass the private repository limit, you can either require a paid account to use this, or impose a unique viewer limit per day/week/month/etc (perhaps by IP or BitBucket account, or both.) Additionally, you could have this take up, for example, two private slots to grant temporary view access to the next two/four/some multiplier of BitBucket users that view the "unlisted" repository.

      If you have any questions or concerns about this proposal, let me know, ideally we can reach a compromise.

            [BCLOUD-14540] Anonymous/View/Unlisted access to Repository

            Katherine Yabut made changes -
            Workflow Original: JAC Suggestion Workflow [ 3539945 ] New: JAC Suggestion Workflow 3 [ 3597920 ]
            Status Original: RESOLVED [ 5 ] New: Closed [ 6 ]
            Alastair Wilkes made changes -
            Status Original: GATHERING INTEREST [ 11772 ] New: RESOLVED [ 5 ]

            Given our focus on teams working together in groups - who all have access to the repo - I don't see us doing this anytime soon, so I'm closing it.

            Alastair Wilkes added a comment - Given our focus on teams working together in groups - who all have access to the repo - I don't see us doing this anytime soon, so I'm closing it.

            I'm feeling that the only difference between an unlisted repository and a public one is it simply not being visible on search results. Preventing cloning might further help push the idea in the "just showing a few people you trust" area which would go quite a ways when using BitBucket in say, a private portfolio (as mentioned in the OP), showing the project to hopefuls who aren't sure if they want to help or not (For example, you'd temporarily switch from private to unlisted/update the permission, then share the link to a few people that might want to help, then swap back to private when done), etc.

            It's rather light in functionality when it comes to the idea, but I can imagine it being somewhat painful to implement.

            Somepotato NA added a comment - I'm feeling that the only difference between an unlisted repository and a public one is it simply not being visible on search results. Preventing cloning might further help push the idea in the "just showing a few people you trust" area which would go quite a ways when using BitBucket in say, a private portfolio (as mentioned in the OP), showing the project to hopefuls who aren't sure if they want to help or not (For example, you'd temporarily switch from private to unlisted/update the permission, then share the link to a few people that might want to help, then swap back to private when done), etc. It's rather light in functionality when it comes to the idea, but I can imagine it being somewhat painful to implement.

            First, we'd need a "view on the web only" permission (i.e. no cloning), and then we'd need to find a way to extend that in the manner you describe. I can't say this would be high on the priority list right now, but's definitely an interesting idea.

            Alastair Wilkes added a comment - First, we'd need a "view on the web only" permission (i.e. no cloning), and then we'd need to find a way to extend that in the manner you describe. I can't say this would be high on the priority list right now, but's definitely an interesting idea.
            Geoff created issue -

              Unassigned Unassigned
              07615d794696 Somepotato NA
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: