Issues

Issue #2462 open

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

Dylan Etkin
created an issue

The subject says it all.

Comments (301)

  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

    +1

    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. anaximander

    +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. Alexey Strelkov

    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. Green Imp

    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 D, 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. byjg

    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. 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.

  15. Alexander 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.

  16. 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

  17. Mark Dibbets

    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,

    Mark

  18. yajo

    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.

  19. 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.

    https://confluence.atlassian.com/display/BITBUCKET/Grant+users+and+groups+access

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

  20. 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.

  21. Micah Peterson

    If you don't trust your QA and product people to SEE the code (they can't push), you could spend some money on Jira and you should have all the control you need.

  22. Stephen Smalley

    https://confluence.atlassian.com/display/BITBUCKET/Repository+privacy,+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. csbubbles

    +1

    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?

    Auswahl_031.png

  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. Phil Lembo

    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. pomcast

    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 staff

    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. geneplaks

    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 caspar.lam@artstor.org.

    Sorry for the inconvenience.

    Best,

    Gene

  41. elsurudo

    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. Dariusz Jakubowski

    Solving this issue would be veeeery useful to our company. We just want to give wiki content to external frontend developer without giving access to our backend sources. Please!...

  46. Piotr Gabryszak

    +1 This is also important for us. For now if I want to give access only to the wiki then the only solution I can think of is creating a separate repo just for the wiki.

  47. 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.

  48. Aron Lorinc

    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?

  49. Log in to comment