Issue #9987 open

Can't view individual commits for team pull requests (BB-10999)

Ben Buchanan
created an issue

We have a simple setup where developers on the team work on forks of the definitive repo in a company-owned account; then submit changes via pull request. The repos need to be private as it's not open source code.

The problem is while we can see the overall diff on PRs, we can't view individual commit diffs, which is a pain when PRs are updated.

Root cause is permissions: individuals can't inherit permissions due to the general problem described in comments at https://bitbucket.org/site/master/issue/4828/team-admins-dont-have-read-access-to-forks so everyone's fork is effectively locked down to one person.

When you inherit permissions for a repo, your account shouldn't have to have the same account level as the upstream repo. Alternatively, attach the commit diffs for the PR to the PR's permissions - ie. we can see the overall diff regardless of account settings, so the individual diffs could be revealed under the same scheme.

Comments (7)

  1. Kaleb Elwert staff
    • changed status to open

    I have opened an issue for this in our internal tracker.

    While I'm not entirely sure how this would be displayed, I can definitely see the use for being able to see the actual content of the specific commits you're approving.

  2. Sébastien Gautrin

    Regarding this functional need as I understand it, if 223-Create a way to group repositories were to be done and integrated correctly with permissions (see this comment on PR#2323 where I outlined it), this could greatly reduce the need to handle cases where the user viewing the PR does not have read access on the origin repo.

    If that was the case, teams such as Ben Buchanan 's (and ours, but luckily we are small enough so developers can give read access to their repos to people approving the PRs without running into user plans problems) could change just a simple thing in order to do what's needed: instead of having developers fork the definitive repo in their own account, they would put their forks on the company-owned account in a specific directory/group (however it's implement with #2323) which would be the only place where they could push, and they would create their PRs from there. You could then that way have the read access to the repo when reviewing the PR as it would count towards the company-account user plan.

    Though even then, this specific use case (PR from a repo we can't see) will still exist, but should impact much less people (I can't see for the moment a use case where people would want, assuming #2323 available and integrated with permissions, specifically that developers fork on their own account)

  3. Erik van Zijst staff

    Can I bribe you Erik van Zijst Nicolas Venegas and Zach Davis with a care packet of tim tams perhaps? ;)

    That's tempting :-)

    I understand the issue and don't see any technical concerns for implementing this. I might add it to my ShipIt or Innovation Week list, as it might be hard to otherwise get this prioritized on the short term.

  4. Ben Buchanan reporter

    Erik van Zijst I'm absolutely serious about the Tim Tams :)

    If you resolve the inherited account limit issue, I suspect many people will want to send tim tams. It causes a lot of annoyances (I know a couple of people who consider it a deal breaker) and dogfooding won't show it up internally.

  5. Log in to comment