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

Dylan Etkin avatarDylan Etkin created an issue

The subject says it all.

Comments (217)

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

    +1 This feature is a must have. As a work around I'm planning to create a new repository with no source in it and use it just for bug-reporting and wiki.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  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.

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

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

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

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

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

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

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

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

  29. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.