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.
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.
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).
+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.
+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.
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.
I'm sure that Atlassian won't ever implement this features because they are part of Stash http://www.atlassian.com/software/stash/overview.
If you want them you can buy a Stash licence and then you will have all the fine grained permissions you need.
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.
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.
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.
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.
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.
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 ...
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.