Allow admins to specify read/write/admin permissions for wiki and issue tracker separate from repository (BB-1166)

Issue #2462 open
Dylan Etkin
created an issue

The subject says it all.

Official response

  • Jarred Colli staff

    Sorry that you guys are feeling left out of the loop. Voting here is one of a few important channels we use for collecting feedback on what to work on, we also interact with our users via surveys, interviews, support channels, and more.

    Right now, a few long-term projects are getting dedicated focus, including better pull-requests, code-search, improving the app marketplace, v2 APIS, and rejiggering our application to become GDPR compliant. While these projects have gotten focus, we've addressed some of the top voted issues along the way. Subsequently, this issue is now the top unresolved request.

    We're looking at how we can make permissions work better for everyone in the coming year, which will primarily focus on how permissions are managed for repos, groups, etc, but it will be a bit before that's reflected in the product.

    Free free to tweet at me if you have any questions @Jarred Colli


Comments (379)

  1. Thomas Praxl

    +1. Want to grant access on issue-tracker to freelancers and external companies. The customer really doesn't want to share the sources with external service-providers.

  2. rfw2nd

    +1 I have a public repository, but I want to restrict wiki editing to only admins. I'd just like to see a third, maybe "Protected" option, where the wiki is publicly visible, but only admins are able to edit it.

  3. Adam Kragt

    +1 for this feature.

    In combination with the ability to set issues as private (Issue #934) and set a 'minimum' permission for viewing those private issues, it would make the Issue Tracker a much more flexible tool.

  4. Adam Crossan

    Please allow this feature! This is almost the first thing I need to drive the use of bitbucket for my projects - getting one or two select testers to be able to raise issues, without exposing them to the entire code repo.

  5. Arjen Schipmolder


    This is an absolute show stopper for us to use BB on larger projects where we have (multiple) third parties working with/for us as either we have to allow them access to the source code or the project becomes unmanageable (multiple repos for the same project etc).

  6. Beyers Cronje

    Has anyone from BitBucket even looked at this Issue? I havent seen any official response from them in this thread and it's been two years since the original issue was created.

  7. Austin Steed

    +1 Would really appreciate this functionality. Even if you made it so you just had another permission on the code repository that was "No Access" or "No Read", where I could give someone access to a private wiki/issue tracker and know they could not access the code repository would be very nice.

  8. Nicholas Budd

    +1 Would be nice if we could specify permissions for issue types as well - for example, if I open up an issue tracker, people who don't have repo access should be able to create and view bug reports and proposals, but I'd like to keep tasks hidden because they're used to manage the work being done and therefore give away details of the implementation that I might not want to make public.

  9. Kimu

    This is the most wanted and most ignored requested feature. It's more than 2 years that this thread collects "+1" but no feedback has ever come from Atlassian. It's quite obvious that they don't want it.

  10. Алексей Стрелков

    Guys what is wrong with you? By commenting "+1" you are making this ticket LESS POPULAR. Because people start unwatching it (obviously no one loves "+1" spam in their email inbox).

    If you support the ticket just PRESS WATCH on it. Don't annoy people that support it, plz.

  11. LeeR

    I'm actually quite surprised that, after over 2 years, this still hasn't been implemented.. or any official response from Attlasian.

    This is obviously a much sought after feature and makes so much sense.

  12. Lars Trebing

    Guys, no need to bother about +1-posting dorks anymore! Atlassian has finally added a “Vote” feature here, so we can just stop watching this issue and vote for it instead!

    Oh, and @Gabriel De Luca, sorry but you clearly and completely missed the point, which is the fact that some people actually use Bitbucket for other purposes than spamming the Bitbucket issue tracker.

  13. Joao Gilberto Magalhaes (JG)

    One argument to implement this idea is bring more users to the Bitbucket. Right now the access is mainly from developers. By adding this feature we can bring more users to the Bitbucket like Product Owners, Clients and Key users.

  14. Anonymous

    Why this feature is not available from the start is beyond me, it's just logical... Any progress on this?

  15. Nasir Rasul

    Isn't this the case already? I can see separate settings for code, wiki and issue tracker. The options are private (allowed users) and public. Each seems to be configurable separately.

  16. Alex Corn

    @Nasir Rasul The options are only public (everyone can read/write) or private, inherit from repository.

    For example, if I have a repo and I set the wiki to public, then everyone can read/write to it.

    If I have a repo and I set the wiki to private, then only those who I explicitly give read access to can read, and only those who can commit to the repo can write.

    There's no way to have a publicly-readable but privately-writable wiki.

    Similarly, there's no way to give a user read access to a wiki but not to the repo.

  17. Justen Stepka

    Official update:

    At this time we do not have an estimate for when this feature will be implemented. Our focus for the short to medium term, will be to provide SSO and better user management with our OnDemand JIRA and Confluence products. I would estimate that the SSO integration and bi-directional oAuth integration between Bitbucket / JIRA / Confluence / Bamboo will take us well into 2014, at which time we will re-evaluate this decision.

    Cheers, Justen -- Bitbucket product manager

  18. MarkD

    C'mon. You guys must understand this is a serious issue. We as a fairly sized web agency (100+) are an inch away from choosing for bitbucket. But this thread really makes me reconsidering our choice. Our clients are very diverse, from B2B to smaller cultural organisations. We don't want them to learn Jira or anything enterprise like, just something simple like TRAC or this tracker would be perfect. We are looking for a complete solution, so we don't have to keep our issue tracking somewehere else. I am pretty sure there a lot of (larger) companies who think alike.

    This thread is more then two years old!? I don't want to be harsh, but it is obviously a business decision to promote using Confluence / partner software as Jira instead of fixing this important issue.

    Kind regards,


  19. Jairo Llopis

    Workaround: Disable repo's wiki and create a folder named /wiki into your source code repo. Then record that in the README.

    It isn't a perfect solution, but gives you a lot of more control, and .md files in the source code are also formatted.

  20. Micah Peterson

    Hey everyone, I could be mistaken, but I think the feature already exists:

    READ - View and fork the repository code. All public repositories grant all Bitbucket users read permissions automatically. Read access on a repository also allows users to create issues, comment on issues, and edit wiki pages.

    So maybe it's just a misunderstanding of what Read Access is in BitBucket...

  21. Rob Kellett

    Micah, you misunderstand. We want to have users that can create issues or edit the wiki WITHOUT being able to see the repository. Think of them as QA users.

  22. Stephen Smalley,+permissions,+and+more#Repositoryprivacy,permissions,andmore-HowPermissionsworkforIssueTrackersandWikis claims that one can set the repo private and the wiki public to limit writes but allow public reading of the wiki. But with that setup, it is still possible for anyone to modify the wiki by clone, commit, and push. That seems like a bug in the documentation or the code, not sure which.

  23. Maxim Novikov


    Issue reporters shall not have access to the repository source code in general (keeping the issue tracker privately same time).

    Right now the lack of such a feature makes me maintain two repositories on BitBucket for the same project - one for the project's source code, the other one for collecting users' feedback. Pretty inconvenient.

  24. Andreas Diehl

    Did you hear of something like "usability"? If many people use software in a wrong way, it might not be the fault of the users.

    BTW, the clickable actions in this application are sometimes buttons, sometimes text-links. So where is the usability here, Alexander? And where is your brain?


  25. Alexander Prokhorov

    Usability may be poor, but it's not an excuse to spam. Judging by the numbers, looks like most people managed to understand the function of the "Vote for this issue" link and the number next to it.

  26. Andreas Diehl

    So why don't you just post an explanation how to vote instead of telling people they are stupid? If you see this issue and all the +1 posts, this lets you think "ok, do it like the other lemmings". I also overlooked the small "vote" text-link, I searched for a button ...

  27. Lars Janssen

    My use case is similar to most of the above. I would like to have a wiki with the following permissions:

    • Public - no access, not even read
    • Specific users (or groups) - read only access or read/write

    This can be useful when working with third party/outsourced developers. Even if they have read/write access to a repo (which could easily be a private fork, so they do pull requests to the main one), we might not want to give read/write access to the central documentation.

    Sure, we can probably trust the people we work with if we ask them not to mess with the wiki, but really, this is not a complex use case. The wiki is already its own repo, we just need to be able to set permissions on it.

  28. rboggess

    I'd like to have the ability to assign visibility of specific groups of issues based on a user's group membership. For example, my internal developers should have full read of all issues, but customers should only be able to view issues, for example, that they submit (or that we mark as visible). Sometimes features are an option that might make it into the source gratis, but if we run out of time, we don't want a customer demanding implementation of a feature to which they haven't paid and aren't entitled.

  29. Anonymous

    Basically "what they all said". In my case I'd like to have my publicly readable (but only owner/admin writable) repository accompanied by a wiki that can be read but not written to by the public.

  30. Ali Tavakoli

    With all due respect to the good people at Atlassian, can we please just get this joke of an issue closed as wontfix and remove the references to it in the blogs as a good example of how issue tracking works?

    If it's not going to get fixed because it's a feature of a paid product, that's a fair reason not to implement it; let's just be honest about it.

  31. bsquidwrd

    I too am looking for this feature.

    Edit: I just took a look at GitHub and it's just a checkbox that says "Allow contributors only" under the wiki edit settings.

  32. Mike Bray

    With the number of people who will attack wikis just for the fun of it growing we need the ability to publish our work without fear of attack. I add my vote to solving this issue quickly.

  33. Theo van den Bogaart

    If you're thinking of posting a comment with +1 [some positive remark], please don't.

    It's awesome you want to show your support for this issue, but it's what the vote button is for. Over 200 people are watching this issue for status changes or an update from Atlassian. Your +1 doesn't need to be mailed to all those people. Just vote the issue up. Tnx

  34. Manuel Carrasco Molina

    @theo_van_den_bogaart just clicking "vote" is simply not enough. The positive comment is what makes the difference. It's the difference between activism and people just saying they are against/for something. As a side note, my heart goes "boom" every time I read a "+1" and it drives me nuts that Atlasssian still hasn't done anything. It's like they really, actually don't care that we all wish this feature....

  35. Rui Figueira

    This is a must. I know the wiki is just a repository, and you can rollback the changes if you don't like the edits, but doesn't make any sense coming back the next day, and rollback because someone just decided to sabotage your wiki. :)

  36. Prakhar Bansal

    +1 This would be a really nice feature to create and maintain user guides for users, but also create pages that are entirely private and act as references for developers.

  37. Ike DeLorenzo

    We do not have plans at the moment to add granular separate permissions for wikis and the Bitbucket issue tracker.

    However, we are working toward allowing owners of the wikis that are associated with public repos to block anonymous contributions to those wikis (and a few other useful and more granular permission that are related to repo permissions) .

    • Ike DeLorenzo, PM , Bitbucket
  38. Björn Fieweger

    Well, it would be great if you implement at least one aspect of this request: Public write only for the issue tracker, to share this with testers. Maybe just like a extern "form" (special link, that you dont have to change the actual stuff) for just "enhancement" and "bug". Then some little textfield and maybe a name/mail-field and add this data to the issue tracker. It would be a HUGE advantage for the bitbucket-service :).

  39. Adrian Lungu

    I would be thankful if the guys at Bitbucket just left the Wiki and Issue Tracker the way they are, for the moment, and just added an additional "No Access" option to the Access Management. Should be simple enough to add, would prevent users from seeing the code, but would allow them to see the Wiki and the Issue Tracker...

    tl;dr: "No Access" access management option => hidden source code; visible wiki and tracker...

  40. Gene Plaks

    I will be out of the country and without e-mail access until Monday, March 9th. If you need immediate assistance, please contact Caspar Lam at

    Sorry for the inconvenience.



  41. Ernest Surudo

    I would love this as well, but it seems to that it will never be implemented. Atlasssian probably wants you to use their premium products (i.e. Confluence) for more advanced use-cases such as this.

  42. Jonas De Kegel

    Actually they'd probably want you to use JIRA, since that's their more advanced issue tracking system (and it integrates with bitbucket, so you get to keep using that :)) I guess it kind of makes sense from a company's perspective, but it would still be nice to enable it for those small projects where JIRA would be overkill. projects that receive a lot of issues daily couldn't be handled through bitbucket anyway... so such users would transfer to jira :)

    still hoping for the implementation, although I'm also looking into JIRA (for other projects) already ;-)

  43. Tom Roche

    @Ike DeLorenzo: 'we are working toward allowing owners of the wikis that are associated with public repos to block anonymous contributions to those wikis'

    Good news: BB projects now have Settings>Wiki settings with checkbox=Allow anyone with access to the repository to edit the wiki.

    Good news (IIUC): if you now create a public project with a wiki, by default you create a wiki that is publicly readable but not publicly writable (i.e., that checkbox will be clear/unset).

    Bad news (for all the matching repos that I have checked): any public projects you created before the introduction of the wiki-editing UI (apparently sometime after 2015-01-29 per Ike DeLorenzo's comment) have that checkbox set (perhaps for compatibility with previous behavior). I.e., that public project's wiki will be both publicly readable and publicly writable.

    Hence, if you have public projects with wikis, you might want to (for each such project) goto its Settings>Wiki settings and check your wiki's writability.

    If anyone knows the API to unset the writability of a public wiki (e.g., from a bash or python script), please lemme know--I've gotta lotta public repos with wikis :-(

  44. Cwazy Wabbit

    Definitely, +1

    I wanted to allow my client to add bug reports without giving him access to the repository, I can't do that without exposing the issue tracker to public because I can't add him to the repository and set his permissions to use the issue tracker only.

  45. Adnan Issadeen

    For the people who want this feature, I'm planning on solving if for myself with a standalone system. Would anyone else be interested in using it if I do so?

    Edit. Just to clarify, this system would sit on top of the issue tracker and wiki of bitbucket.

  46. Aron Lorincz

    I want my clients able to report me issues, just without letting them see the code (to give them +1 reason to pay me for the job). Using a separate repo each time is so distracting... Shall I use JIRA?

  47. Kaylyn Garnett

    +1 I want people to be able to see the wiki/issues so that they can stay up to date with the project and its releases, but I want it to be read-only without having to show my code

    Edit: Nevermind, according to setting wikis to read-only for non-contributors is already supported, and I don't necessarily have the need for a more general application of read/write permissions (yet)

  48. Daniel Bennett staff

    Hello everyone,

    While having separate permissions for the issue tracker seems like an easy thing to do, the unfortunate situation is we have a lot of technical debt to pay down before we can get there. When first added to Bitbucket the issues were bolted tightly onto the repository model. So tightly, in fact, that each repository still lugs around with it issue tracker metadata even if they don't have issues enabled. This means that issues inherit all the access controls for repositories "for free" but at the expense of the flexibility you're asking for.

    As we go through the process of paying down some of this debt we'll get closer to being able to realistically talk about the effort required to create a separate issues security model. Though I don't know when we'll hit that point, I'll return to this issue in 90 days or so and provide an update if one hasn't already happened.


    Dan Bennett, Bitbucket Development Manager

  49. Maxim Novikov

    @Daniel Bennett

    Thanks, Dan, for getting back to us.

    Could you please clarify if I get it right that you are going to solve this in future, and the community can expect this issue get resolved in our favor, but you just can't realistically estimate when it would happen?

    PS Please keep us posted...

  50. Daniel Bennett staff

    @Maxim Novikov absolutely. Yes, we plan to solve this limitation in the future, and the community can expect to have something available to them that resolves the need. However, I cannot realistically estimate when it will happen nor guarantee that what we do is exactly as I imagine it will be today.

    Maybe we complete the current trajectory of separation, or, maybe we end up completely rewriting the issue tracker. Though, one is significantly more likely than the other, as an engineering representative rather than product management, I can't predict.

  51. A

    Is this legit? Or a sick dev joke? As @Anthony MacAllister just noted this have been open since 2011.

    Giving users access to the code would be - in a way - like giving the FTP access. Who does that?

    Code is code. Issues are issues.

    Repo - Read, Write, Admin

    Issues - Read, Write, Admin

    Wiki - Read, Write, Admin


  52. Greg Hammett

    Good point. I was thinking primarily of a wiki. I don't know if there are work arounds in the bug reporting to include a tag to a particular commit in another repo. I would think there should be, because often times libraries have dependencies on other libraries.

  53. A

    fwiw, since this doesn't seem like it's going to happen, I've taken to having two primary repos per project.

    One repo for code and the other for only issues. There's a part of me that kinda prefers this now. Mainly because now the code's issues can be more code-centrirc (and only used by the code team.) Whereas the repo for just issues is a snadbox (of sorts) for stakeholders, clients, etc.

    That is, Issues (only) is broad and pan project. While the issues within the code repo are particular to code. This is the direction I for one would like to see things move in.

  54. Austin Steed

    Love it, 5 years and the only response we get is, "We don't have any response right now, we might respond in a few months with probably the same answer" to be fair though, I'm pretty certain that everyone has given up hope on this.

  55. Billy Galbreath

    Yeah, I'm affraid I'm about to give up on bitbucket, too. Hard to stand by a company that doesn't listen to its userbase. :/

    I'll check back in a couple months to see if things get better (just as likely as this ticket getting resolved in the people's favor)

  56. Gianluigi Rubino

    I would like to add that, if you're willing to pay, you can connect their other product, JIRA, for the bug tracking. Then you'd be able to assign different permissions to your user: issue tracker, or repository.

    Their company has different solutions, I used to be a customer, the problem is that bit bucket started their development taking some assumptions that nowadays are no more valid.

    This could easily mean a so huge refactoring of the code base, that probably has a lower priority.

  57. A

    As mentioned, the workaround - I feel into and have sense loved more - is to have a repo just for Issues for stakeholders. The Issues for the actual code becomes the code team's issues where things can be discussed beyond the gaze of the stakeholders. The audiences, needs and lexicons are different. It makes sense for the tool to be setup to reflect that.

    p.s. Yeah, I felt "hacky" to me at first but then I realized it makes more sense to have two different sets of Issues.

  58. Alastair Wilkes staff

    Hi everyone. We know this is a highly voted and useful feature and is something we'd like to do. However, as we are busy at work on other highly voted features like code search (#2874), large file support (#11204), and more code review improvements (#589, #7042, #5652, #8995), and due to the implementation complexities described above, we don't anticipate getting to this in the near future. As a result, I'm moving this to "On Hold."

  59. Jonas De Kegel

    Would it, as an alternative, be possible to modify the interface to have a "linked" repository, preventing clutter on the home/listing screens

    I.e.:a "merge" /link that merges those repositories under 1 "item", and allowing switching between those linked repositories when "inside". Should be fairly easily fixed, and a great alternative to fix the issue!

  60. Sergio Basurco

    Seems to me it also doesn't make sense to implement this from a commercial perspective.

    For Atlassian it's beneficial as private companies do not want a public issue tracker, what they want is a group of users. Then you need to add them as Bitbucket users, even for a repository with no code this is also costly if you don't want a public issue tracker.

    The other solution would be JIRA, but either as JIRA users or setting up the JIRA Service Desk, it is also costly for the company to allow groups to track issues.


  61. Laurence Brevard


    Why does the documentation at

    ... say: "You can set your Bitbucket repository, wiki, and issue tracker as private or public, independently of each other." ?

    ANSWER: The PROJECT has to be public but the REPOSITORY can be private, at which point the Issue Tracker can be made public.

    Whew... I was going to have to give up on BitBucket until I figured this out.

  62. Marcos Ackel

    I think this is NOT SOLVED. Wiki docs says: " For a private wiki, a user's access to the code repository also applies to the wiki. For a public wiki, anyone can view it even if the code repository is private."

    What is needed is to have a private REPO where most users can read but not write, and a WIKI where most users can read/write. In other words, different rights in REPO and WIKI.

  63. Dirk Watkins

    I would love to have the ability to allow certain bitbucket accounts access to the issue tracker separate from the repository. These users should not affect the repo licensing and could only create and edit issues. For instance, this would be used by project managers and clients to log issues. They would not have access to the source code. We definitely do NOT want the issue tracker public to the world.

  64. Blackfeather Tanfur

    Has the vote button disappeared because the issue is on hold? I'd +1 this the right way (vote button) but it's not appearing on my page.

    I do add that another really cool addition to that would be a per-page read option, rather than just the whole wiki. But starting with the whole one would be good.

  65. Robert Howlett

    This is potentially a deal-breaker for us (paid subscription). Most of our company should not have read access to the code. We would like to give them limited access to the issue tracker, and are willing to pay the additional fees for the extra users.

  66. Scott Courtney


    I am testing the site with a free account right now because I am a team of one, but I will absolutely commit to upgrading to a paid account if I can selectively grant Issues access only to the same people to whom I grant readonly access to my repository. The desired state for my projects would be that the issues are publicly readonly but can be created only by those to whom I grant permission.

  67. Jurre Van Wouw

    +1 I want (future) users (of my application) to be able to see that I already have a particular enhancement in mind (but just haven't had time to implement it yet) without them being able to randomly create issues.

  68. MRS

    Testers are separate from developers, i do not want them to access private repo. They should only have access to issue tracker.

  69. Jarred Colli staff

    Hi Everyone, thanks for your feedback on this ticket. We review our highest voted issues regularly, and just completed this process again.

    Unfortunately, we don't have any plans to address this feature right now. At the moment, we're busy improving Bitbucket in the following areas:

    • pull requests
    • code search
    • pipelines & deployments
    • design and user experience.

    Please continue to follow this ticket for updates, and add comments describing any use-cases that are important to your team and not already covered above.

    Thanks, Jarred

  70. Bob Fletcher

    This is a very desirable feature. Obviously, there are many times when we would like for users/testers to be able to create and review issues but not allow them access to the code.

  71. Riaan

    +1 this feature would be much appreciated.

    As a workaround, and as mentioned by other users above, you can create a separate project/repo on for the purpose of issue tracking/wiki pages. It doesn't need to contain any source code though, but this could potentially be used for purposes of sharing code/documents/etc.

    Hope this will help someone.

  72. Phil Hilton

    @Jarred Colli So what is the point of voting on an issue if your top most voted issue, which has been requested for more than 7 years, has 47% more votes than the next highest, and 108% more than the one behind that, is not considered worthy of developer time?

  73. Aaron

    The cynical might say they don't want to do it, have no intention of doing it - but don't want to /say/ so, because it would annoy us...

  74. Jarred Colli staff

    Sorry that you guys are feeling left out of the loop. Voting here is one of a few important channels we use for collecting feedback on what to work on, we also interact with our users via surveys, interviews, support channels, and more.

    Right now, a few long-term projects are getting dedicated focus, including better pull-requests, code-search, improving the app marketplace, v2 APIS, and rejiggering our application to become GDPR compliant. While these projects have gotten focus, we've addressed some of the top voted issues along the way. Subsequently, this issue is now the top unresolved request.

    We're looking at how we can make permissions work better for everyone in the coming year, which will primarily focus on how permissions are managed for repos, groups, etc, but it will be a bit before that's reflected in the product.

    Free free to tweet at me if you have any questions @Jarred Colli


  75. Phil Hilton

    @Jarred Colli Well written, sir. I've been of the belief that Atlassian has little interest in adding features to Bitbucket that are already available in Jira/Servicedesk or other solutions as that is a primary motivator in getting people to pay for them. You made me forget that for about 3 seconds, however. You should run for office.

  76. Ed Kolis

    I want to let end users create issues without giving them access to my source code. Is there an API I could use to give them an alternative frontend using the current system?

  77. Ed Greenberg

    @Ed Kolis There is indeed an API, and I have written as bit of this in PHP with Laravel. At least posting an issue, so far.

    Start here:

    I was unable to create issues in the names of the reporters, since they don't have accounts, so I created all issues in my own name, and put their names in the subject line along with their subjects.

    If you want to discuss further... edg at greenberg dot org or tag me here as @Ed Greenberg

  78. Log in to comment