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.
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.
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.
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
@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....
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. :)
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) .
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 :).
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...
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 ;-)
@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 :-(
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.
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?
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.
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?
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.
I just thought of a workaround, and see that https://bitbucket.org/bharathchandra/ suggested this above in 2012: a work around is to create a separate repository (it doesn't have to have any source code in it) and use it just for bug-reporting and a wiki.
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.
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.
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.
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.
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.
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."
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!
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.
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.
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.
@Galdin -- from what I can tell, it's not possible on GitLab. See https://gitlab.com/gitlab-org/gitlab-ce/issues/14021 .. a LOT of users want it, but it hasn't been implemented. I suppose there's no stronger commercial reason for the GL staff to implement it than for Atlassian staff to do it for BB.