| 2009-07-27 12:42:16 |
Brad Crittenden |
bug |
|
|
added bug |
| 2009-07-27 13:22:21 |
Curtis Hovey |
launchpad-registry: importance |
Undecided |
High |
|
| 2009-07-27 13:22:21 |
Curtis Hovey |
launchpad-registry: status |
New |
Triaged |
|
| 2009-07-27 13:22:21 |
Curtis Hovey |
launchpad-registry: milestone |
|
2.2.8 |
|
| 2009-07-27 13:22:21 |
Curtis Hovey |
launchpad-registry: assignee |
|
Brad Crittenden (bac) |
|
| 2009-08-20 13:31:41 |
Curtis Hovey |
launchpad-registry: milestone |
2.2.8 |
3.0 |
|
| 2009-09-01 14:01:38 |
Curtis Hovey |
launchpad-registry: status |
Triaged |
In Progress |
|
| 2009-09-04 13:47:53 |
Brad Crittenden |
launchpad-registry: status |
In Progress |
Triaged |
|
| 2009-09-10 13:52:04 |
Curtis Hovey |
launchpad-registry: milestone |
3.0 |
3.1.10 |
|
| 2009-09-29 12:04:54 |
Curtis Hovey |
launchpad-registry: importance |
High |
Low |
|
| 2009-10-02 15:21:00 |
Curtis Hovey |
launchpad-registry: milestone |
3.1.10 |
|
|
| 2009-12-10 14:51:59 |
Curtis Hovey |
launchpad-registry: assignee |
Brad Crittenden (bac) |
|
|
| 2010-09-28 16:44:48 |
Curtis Hovey |
tags |
|
disclosure |
|
| 2011-05-24 03:46:01 |
Curtis Hovey |
description |
Private teams need to be able to join other teams. The restrictions need to be explored as to which types of teams can join others:
[Y] : Private <- Private
[N]: Private <- Public
[?]: Public <- Private -- would allowing a private team to join a public team be a source for discovering existence and/or membership of the private team? Will the commingling of teams introduce extra privacy-based screening that causes otherwise simple queries to time-out, as we've seen elsewhere?
This bug does not address changing membership rules for Private Membership Teams. |
Private teams need to be able to join other teams. The restrictions need to be explored as to which types of teams can join others:
[Y] : Private <- Private
[N]: Private <- Public
[?]: Public <- Private -- would allowing a private team to join a public team be a source for discovering existence and/or membership of the private team? Will the commingling of teams introduce extra privacy-based screening that causes otherwise simple queries to time-out, as we've seen elsewhere? |
|
| 2011-05-30 23:27:58 |
Robert Collins |
description |
Private teams need to be able to join other teams. The restrictions need to be explored as to which types of teams can join others:
[Y] : Private <- Private
[N]: Private <- Public
[?]: Public <- Private -- would allowing a private team to join a public team be a source for discovering existence and/or membership of the private team? Will the commingling of teams introduce extra privacy-based screening that causes otherwise simple queries to time-out, as we've seen elsewhere? |
Private teams need to be able to join other teams. The restrictions need to be explored as to which types of teams can join others:
[Y] : Private <- Private
[?]: Public <- Private -- would allowing a private team to join a public team be a source for discovering existence and/or membership of the private team? Will the commingling of teams introduce extra privacy-based screening that causes otherwise simple queries to time-out, as we've seen elsewhere? |
|
| 2011-05-30 23:28:11 |
Robert Collins |
description |
Private teams need to be able to join other teams. The restrictions need to be explored as to which types of teams can join others:
[Y] : Private <- Private
[?]: Public <- Private -- would allowing a private team to join a public team be a source for discovering existence and/or membership of the private team? Will the commingling of teams introduce extra privacy-based screening that causes otherwise simple queries to time-out, as we've seen elsewhere? |
Private teams need to be able to join other teams. The restrictions need to be explored as to which types of teams can join others:
[Y] : Private <- Private
[Y] : Private <- Public
[?] : Public <- Private -- would allowing a private team to join a public team be a source for discovering existence and/or membership of the private team? Will the commingling of teams introduce extra privacy-based screening that causes otherwise simple queries to time-out, as we've seen elsewhere? |
|
| 2011-05-30 23:59:56 |
Robert Collins |
description |
Private teams need to be able to join other teams. The restrictions need to be explored as to which types of teams can join others:
[Y] : Private <- Private
[Y] : Private <- Public
[?] : Public <- Private -- would allowing a private team to join a public team be a source for discovering existence and/or membership of the private team? Will the commingling of teams introduce extra privacy-based screening that causes otherwise simple queries to time-out, as we've seen elsewhere? |
Private teams need to be able to join other teams. The restrictions need to be explored as to which types of teams can join others:
[Y] : Private <- Private
[Y] : Private <- Public
[Y] : Public <- Public
[?] : Public <- Private -- would allowing a private team to join a public team be a source for discovering existence and/or membership of the private team? Will the commingling of teams introduce extra privacy-based screening that causes otherwise simple queries to time-out, as we've seen elsewhere? |
|
| 2011-05-31 22:23:15 |
Robert Collins |
summary |
Allow private teams to join other teams |
Private teams are not able to join other teams (public or private) |
|
| 2011-05-31 22:46:38 |
Robert Collins |
description |
Private teams need to be able to join other teams. The restrictions need to be explored as to which types of teams can join others:
[Y] : Private <- Private
[Y] : Private <- Public
[Y] : Public <- Public
[?] : Public <- Private -- would allowing a private team to join a public team be a source for discovering existence and/or membership of the private team? Will the commingling of teams introduce extra privacy-based screening that causes otherwise simple queries to time-out, as we've seen elsewhere? |
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
==============
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 proposed for membership in.
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. |
|
| 2011-05-31 23:04:08 |
Robert Collins |
description |
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
==============
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 proposed for membership in.
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. |
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. |
|
| 2011-06-30 01:06:16 |
Robert Collins |
launchpad: importance |
Low |
High |
|
| 2011-09-21 15:39:18 |
Curtis Hovey |
tags |
disclosure lp-registry |
disclosure lp-registry privacy team |
|
| 2011-09-21 18:27:19 |
Curtis Hovey |
tags |
disclosure lp-registry privacy team |
disclosure lp-registry privacy teams |
|
| 2011-12-19 16:14:58 |
j.c.sackett |
launchpad: status |
Triaged |
In Progress |
|
| 2011-12-19 16:15:01 |
j.c.sackett |
launchpad: assignee |
|
j.c.sackett (jcsackett) |
|
| 2012-01-06 15:39:31 |
j.c.sackett |
branch linked |
|
lp:~jcsackett/launchpad/remove-private-prevention |
|
| 2012-01-12 11:20:24 |
Launchpad QA Bot |
tags |
disclosure lp-registry privacy teams |
disclosure lp-registry privacy qa-needstesting teams |
|
| 2012-01-12 11:20:26 |
Launchpad QA Bot |
launchpad: status |
In Progress |
Fix Committed |
|
| 2012-01-15 16:28:23 |
Curtis Hovey |
tags |
disclosure lp-registry privacy qa-needstesting teams |
disclosure lp-registry privacy qa-ok teams |
|
| 2012-01-18 00:19:55 |
William Grant |
launchpad: status |
Fix Committed |
Fix Released |
|
