Enterprise Onboarding Problem - Teams can't share repos with other teams

Issue #14547 open
Kingdon Barrett
created an issue

Issue #5942 - Adding a team to a private repo - Please look at the screenshot from this bug report.

In 5942 the screenshot shows Missed Opportunity # 1 in the user interface where it might make sense to allow sharing a Repo with a Team, but because the system does not allow it you get the red text instead.

Please look at the screenshot attached, case study # 2 or Missed Opportunity # 2 in the user interface. This account is the administrator of Test Team 14 and Test Team 15. There is a modal to switch from "Individual" to "Group."

This was the second place I thought I would be able to share a private repository from one team to another, but it has no way to share a private repo from Test Team 15 into one of the projects available to members of Test Team 14. Try it and you get the red text again.

I have been working with support to try to solve this use case for me, and they identified a workflow that might technically satisfy what I'm asking for, but will never work in practice or at scale for any decently sized enterprises.

So, my very brief feature request, please add the capability for Enterprise Teams to share their repos with other Enterprise Teams!

Atlassian Support, if I understand correctly, suggested that we (the Team is called nd-oit) should create a Group in our Team, grant the permissions on whatever repositories we wanted to that Group, and add the users of the other Team to it. We are currently planning on doing that for the small list of users that we will onboard this week and next, but I'm saying that long-term this will never work because the people with Administrator role are very busy, and don't like busy work. Keeping two lists in sync is by definition busy work and there is no logical reason why anyone should do it, let alone doing it on-demand.

I could write an API Client to keep the members of Team B in sync with a group in my own Team... that seems quite onerous for what should be an extremely common use case. Can you just enable the capability for team administrators to share a private repo from one team to another instead?

In the (current-state) user story,

  1. First "ND_HR-IS" must first establish their team.
  2. Members of HR-IS their team must all create accounts, and join the ND_HR-IS group. It would be helpful if we could get them to do this up-front. (Hint: They won't do this up-front.)
  3. Then, someone with the "nd-oit" team's Administrator role must
  • create a sub-group of nd-oit (the first time)
  • manually add each of the members of the "ND_HR-IS" team to that group (every time)

Manually keeping that list of team members updated as ND_HR-IS adds new team members. Who is going to do that? People with the Administrator role are busy and won't return my e-mails already when I try contacting them about this. (Hint: They are never going to do that.)

In reality, this (current-state) user story will never happen because HR-IS is not using Bitbucket already. We are onboarding them now, or at least we hope to do this. It might turn out that their team is quite small, or quite large, we don't know! But for the near future, members will be added one at a time. It would be expedient if we did not have to remain permanently involved in adding them each individually. Unfortunately HR-IS does not have any Git content of their own, and they are not yet interested in generating any, so getting them on Bitbucket even one by one is kind of a hard sell.

They may some day create their own repos and wikis, but they also may never do this. They are most of them certainly not using Git right now. We still wish to engage them on our private repos and help them create their own team so they can participate in our development process on Bitbucket better, and always have access to our most current documentation. We are power Git users and we depend heavily on Bitbucket for code reviews and intra-team sharing.

Until HR-IS Admin engages ND-OIT Admin upon new team member's account creation, in the current-state, each new ND_HR-IS team member who joins the team has access to no content until ND-OIT admin acts to add the new team member to our team's group. (Since nobody is going to agree to do that job, we can safely show that this story will never actually happen unless I write some API integration to support it.)

This is why the title of this enhancement is "Enterprise Onboarding Problem"

In the desirable "trivial enhancement" future state that is very desirable for me and my enterprise,

Just like I can grant Read-Only or Developer access to a private repo, to members of my team, or groups on my team... I can grant Read-Only access to one of my team's private repos, to ND_HR-IS team that I have Administrator rights on.

It would make sense if, in the case where I only have Admin on one team, I can grant my private repos to another team, but it has no effect on the users of that team until an Admin from that team adds it. Then, after I granted that access, there would be some workflow on the Project configuration page (seems like it could go on the page attached here as screenshot) where an Admin from that team could add the shared repo to one of their team's Projects.

This just seems like such a natural feature that I don't understand why it doesn't already work that way. Almost like Teams were bolted on as a feature for Enterprise users at some point, and it was just never considered that Teams might actually want to share with each other.

Users on that team would see my repository in the list of repos with their other Team repos. Admin on each team can still control Project settings and may designate which repos are in which projects and which groups/teams have access to them, but the list of repos on a Team's project configuration pages no longer draws solely from the team's own projects, but also from the listing of any private repos that are shared with the team.

Comments (6)

  1. Kingdon Barrett reporter

    I'm talking about two teams that are basically not related, except in the sense that Team B is our customer.

    We have a product that they are using and we want to share the source code with them, because it contains technical specifications that they should be able to read. We want to provide them with the latest copy of everything, so sharing the repository directly from Bitbucket seemed like a natural. The documentation is in plain-text (it's a suite of Cucumber regression tests.) So they are executable documentation that we have created for the customer's consumption, and it means something when I say they are "current" because there is a status page where they can see whether or not the tests are all passing.

    I asked our customer to create a team. By adding a new Team, it will give them the capability to manage the sharing within their department. We don't need to worry about whether the whole department has access, or only those that are using Bitbucket already, or what, because they are going to do it. So instead of holding their hand, we just want to say "get a Bitbucket team and we will share our development artifacts with you."

    They are in a different working group and it's not reasonable at all to expect that we will manage their personnel changes. When they want to involve a new team member, I would not expect to get a phone call about it, but according to Bitbucket I must get a phone call. That's basically what the support solution to our request entailed.

    I believe the support rep's assessment, this is the only way to accomplish what we are trying to do without a feature update from Bitbucket devs. One of my team's Administrator users must create a group, grant the access to the artifacts to that group, and add members of the remote Team to that group on an individual basis.

    The people with the Administrator role are certainly very important and busy, and they will not want to spend time keeping a group on our team, for this group that belongs on the other department's team.

    (Our departments are basically autonomous from each other and don't share these resources. They are our "strategic partner" but the relationship is also very much like "customer." These are departments in a large private University administration.)

    We already have unlimited users per private repos, so there is no billing issue for us. I'm not sure how the story goes for lesser tiers of users, but the solution that was proposed by support for us, does not scale in our case. We are not paying for the remote department's Enterprise Team, they will be responsible for that. I don't know if there is incremental cost for us, but we will eat the incremental cost if necessary of adding another user to our team's roster because by adding this group, the number of users with access to our private repos has gone up. That's fine. I just don't want for it to be incumbent on someone in my own team to manage the other team's group.

    We just want to share the documentation in our git repository with some non-development users in another department, and that department will manage the billing for that team, and the list of users in that group. But in the current system there is no way for two teams to work together like that. I must create a group within my team and add members of their team to it. (Where by "I" what is meant is, someone. I don't have the Administrator role and I have to actually ask someone to do this, if we are going to get it done at all. So I'm hoping I don't have to ask for a lot, because I know this person is very busy. They will definitely never sign up for managing another group, in the best case I can get them to grant me Administrator to the group, if that's a possibility in the list of supported configurations.)

    So, my friend in other department has created a Team, and my Team has a private repository, but the current-state of the Bitbucket system is that there is no way for me to add my private repository to their team.

    Believe me, I tried everything, and even if the two Teams have one user in common who shares the Administrator role in both teams, nobody has the capability to share a private repo from one team to another.

  2. Alastair Wilkes staff

    As it stands today (and as you correctly mention), teams in Bitbucket are meant to be the umbrella for your entire organization, so they don't really 'talk' to each other. For large organizations, using a single team presents one set of challenges (particularly around user management), whereas splitting into several teams resolves some of those (user management) but introduces other issues (collaboration between teams).

    Knowing this, I'd still recommend using a single team where possible, but there are definitely improvements that can be made to make this kind of management easier for very large teams.

  3. Kingdon Barrett reporter

    @Alastair Wilkes I'm told we are going to federate across ND soon, but they kind of put "soon" in finger quotes.

    Maybe that's how it will go with federation, but... we are talking about a whole university here with many free-standing departments though, to put in context what it means if we're all going to be on one team. (Thousands of people and most of them will never talk to each other.)

    There's going to be one set of admin users for the whole team? I'm told we'll be able to use our LDAP groups as BitBucket groups once the federation is completed, I don't know what the hold-up is, but I've got my fingers crossed that it's going to solve all of our problems.

    There's no way that students should see projects that belong to the IT office, I know that. So it would make a lot of sense to have a separate student team from the staff team. The staff will never really be working together with the students. (Maybe if one of them gets a second job becoming both faculty and staff, but they could then be added to a faculty group that is on the team that collaborates with students.)

    We're not really using Projects (we have one mega-project, and every repo is in it), so I'm not sure if I'm really describing a dire state, or if Projects are somehow part of the solution to my problem. And like I said, it does not look like the story is any better on Github.

    If there's any way I can help with the effort to move to federation, I'm interested.

  4. Log in to comment