Symptoms
========
There is no UI to let a private team be a member of another team. The UI prevents this because the underlying code does not have any rules for determining visibility of private teams other than 'only the members and owner can see the team'.
Analysis
========
Currently private teams have a rule that their existence and identity must not be exposed under any circumstances. This is overly strict: it prevents the team sharing assets with others (e.g. private PPAs), owning assets (e.g. other teams or projects) or participating in larger structures (e.g. consider an internal company structure mapped into launchpad - a ceo team owning department head role teams owning department membership teams and so on).
So there are a number of different situations where we need to allow private teams to interact with other objects.
If we clearly identify actions that will expose the existence of the team, and what data will be exposed, then users can decide for themselves whether they want the benefit of taking the action, or the privacy of not taking it. When a private team is exposed due to its interacting with some other object we should only show enough data to let the system render pages correctly.
That is:
- name, displayname, branding (so we can show the team)
- *if the interaction granting visibilty is exposed under the teams url* - url
And on views of the team itself, if they can see its url then we can show them a bare bones page showing only the metadata they are permitted plus the child objects that the user has been granted access to.
For team membership there are two teams involved: the joined(parent) and the joining(child) team.
To allow a private team to join a private team we need to analyse both scenarios.
Private parent teams
====================
In this scenario a private team allows another person to join it. This is implicitly analysed today because we permit users to be in private teams. The rules we chose were:
- permitting a member into a private team permits full visibility of the team.
- The teams membership list can be seen, its owner etc.
This doesn't say that all the members will be mutually visible - but it does say that the parent team does not apply its own visibility limits to any of its metadata for any of its members.
Private child teams
===================
In this scenario a private team joins another team. The parent team has three interesting actors associated with it:
* owner - can modify the parent team but are not part of it.
* administrator - can modify the parent team and are part of it.
* member - care part of the team.
In order to administrate the team visibility of every member is required (otherwise members cannot be evicted). Similarly proposed members must be visible. So the owner and administrators must be able to see the name and display name for every member whether they are private or not.
In order to be part of the team no visibility of other members is needed, so none should be granted.
Implementation
==============
This implementation will let private teams be members of public teams and of other private teams.
Add visibility rules for private teams which allow administrators(including owners) of the teams they are in or are proposed for membership in to see their displayname and name. Add a UI to propose a private team for membership in another team which the person doing the proposal can see.
The rules for visibility of a private team is then:
* You own or are in the team.
* You own or administer a team that the private team is in
* You own or administer a team that the private team is has been proposed for membership in (in either direction: the requirement that the proposer have visibility to both teams satisfies this).
Parent case: When accepting a proposed member to a private team, adding a member to a private team, or offering membership in the team to another team/person we need to notify the person doing the acceptance/addition/offer that they are granting full visibility of the private team object (but seeing other members is up to the visibility rules governing those members).
Child case: When putting a private team forward for membership in a team or accepting a 'you have been added to this team' offer on behalf of a private team the person applying for or accepting the offer is notified that their teams name/display/branding will be visible to administrators and owners of the other team.
Caveats
=======
There are other ways we may want to permit widespread visibility of private teams to non-members such as 'everyone in $company should be able to see $company team names', but that is a different project and its implementation would not make the problem of team membership in teams easier or harder because private teams may join cross-organisationally.
Hi Brad. Thanks to taking this issue.
I think Public <- Private is [N]. This is a painful rule because it will require some real teams to manage a public and a private launchpad teams so that they can work public and private projects.
I think private team owners will want to add their private team to a public (owner, driver, bug supervisor) team because those roles are needed to do some task. Presumably the admin of the public team is also a member of the private team, but we know the membership can change. Communication within the team will be awkward because a member of a private team is a "double-agent" who must guard everything he says and does to not revel he has a private interest. I think we want to avoid this conflict of interest (as we should have done when mailing lists were added to teams)
The official recipe will require a separate pubic team. I am sure there will be a duplication of membership at first. I believe the public team membership will naturally diverge from the private team because the interests of the two teams are not the same. That is to say, If were were to permit Public <- Private, users will get into trouble when they discover they need to create a separate pubic team to collaborate with other users. Let's avoid the situation.
If this division proves to be awkward, we can look at making team creation and membership management easier.