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

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