3984
Comment:
|
4999
|
Deletions are marked like this. | Additions are marked like this. |
Line 6: | Line 6: |
'''As a ''' project owner<<BR>> '''I want ''' grant users and teams permission to see everything<<BR>> '''so that ''' they do not need many subscriptions to access parts of the project.<<BR>> Project and distributions owners need to see who can access all or some of |
Project and distribution owners need to see who can access all or some of |
Line 14: | Line 9: |
[[PrivateProjectsAndDistros]] | [[PrivateProjectsAndDistributions]] |
Line 22: | Line 17: |
This allows stakeholders to know who has access, and in a single action, | Stakeholders need to know who has access, and in a single action, |
Line 26: | Line 21: |
e.g. Steve Magoun from OEM would like to be able to see exactly who has access to every component in his project. |
|
Line 33: | Line 30: |
* Landscape (Jamu Kakar) * UbuntuOne (Matt Griffin) |
* Landscape (???) * UbuntuOne (???) == User stories == <<Anchor(seeing-legacy)>> === Seeing legacy disclosure === '''As a ''' project owner<<BR>> '''I want ''' to see who has access (is subscribed to) private bugs and branches within my project<<BR>> '''so that ''' I can make sure that everyone who needs to have access has it, and no one who shouldn’t doesn’t<<BR>> <<Anchor(granting)>> === Granting disclosure === '''As a ''' project owner<<BR>> '''I want ''' grant users and teams permission to see everything<<BR>> '''so that ''' they do not need many subscriptions to access parts of the project.<<BR>> <<Anchor(seeing)>> === Seeing disclosure === '''As a project owner'''<<BR>> '''I want ''' to see users with permission to see all of the private items in my project<<BR>> '''so that ''' I can maintain control over who has access to my project.<<BR>> <<Anchor(withdrawing)>> === Withdrawing disclosure === '''As a project owner'''<<BR>> '''I want ''' to prevent a user from accessing to my project or a bug/branch<<BR>> '''so that ''' private information is not disclosed and that owners can respond to a disclosure issue immediately |
Line 42: | Line 69: |
The view must also show how the user has access: direct or via a team, contributor or user, subscription to artefacts or access to project. |
The view must also show exactly ''how'' the user has access, for example: directly or via a team; as a (core?) contributor or as a user; by subscribing to some artefacts or through access to the whole project. |
Line 60: | Line 88: |
1. A way to see how the user knows about the project. <<BR>> Owners often want to know if the user has email subscriptions to understand if the user is getting information via email too. |
|
Line 69: | Line 93: |
Line 72: | Line 95: |
1. Revoking a user or team not allow the user to have partial access.<<BR>> | 1. Revoking a user or team must not allow the user to have partial access.<<BR>> |
Line 89: | Line 112: |
1. Viewing a list of users and a summary of an single user. | 1. Viewing a list of users and a summary for a single user. |
Line 93: | Line 116: |
1. Failing to grant access to a team that is public or a member team is a public |
1. Failing to grant access to a team that is open or a member team is open |
Line 124: | Line 147: |
1. Owner, drivers, an bug supervisors are assumed to have full access. | === jml === 1. Owner, drivers, security contacts and bug supervisors are assumed to have full access. 1. We should get a team within Canonical to beta test |
Managing Disclosure
Project and distribution owners can grant or revoke user and team permissions to access all private artefacts.
Project and distribution owners need to see who can access all or some of their project. Owners need to grant and revoke access.
PrivateProjectsAndDistributions
Rationale
With the introduction of private projects and distributions, owner need a way give access to hundreds of private project artefacts.
Stakeholders need to know who has access, and in a single action, grant or revoke it. This is valuable to public project with default private bug and branches--once a company team is granted access, all employees have access to company information.
e.g. Steve Magoun from OEM would like to be able to see exactly who has access to every component in his project.
Stakeholders
- OEM (Joey Stanford, Steve Magoun, Cody A.W. Somerville)
- Hardware enablement (Chris Van Hoof, Hugh Blemings)
- ISD (Stuart Metcalfe)
- Landscape (???)
UbuntuOne (???)
User stories
Seeing legacy disclosure
As a project owner
I want to see who has access (is subscribed to) private bugs and branches within my project
so that I can make sure that everyone who needs to have access has it, and no one who shouldn’t doesn’t
Granting disclosure
As a project owner
I want grant users and teams permission to see everything
so that they do not need many subscriptions to access parts of the project.
Seeing disclosure
As a project owner
I want to see users with permission to see all of the private items in my project
so that I can maintain control over who has access to my project.
Withdrawing disclosure
As a project owner
I want to prevent a user from accessing to my project or a bug/branch
so that private information is not disclosed and that owners can respond to a disclosure issue immediately
Constraints and Requirements
Must
A lists of all the users with full or partial access.
The view must also show exactly how the user has access, for example: directly or via a team; as a (core?) contributor or as a user; by subscribing to some artefacts or through access to the whole project.A summary everything an user may know about the project.
The view must also show how the user has access: direct or via a team.A way to grant a user or team full access to a project.
When a owner grants access to a team, the view should show who gains access.A way to revoke all access to a user or team.
Revocation removed all subscriptions to individual artefacts be default. The owner many choose to keep some subscription so that partial access is allowed. If the user has access via a team, the view must explain how to remove either the user or the team to revoke permissions.
Nice to have
List the users who have full access via the owner or driver team.
The owner may need to know about contributors as well as users. If the owner can revoke access to an owner/driver, then the user must be removed from the team and assignments and subscriptions are removed too.
Must not
Revoking a user or team must not allow the user to have partial access.
Revoking access to a user must remove the individual subscriptions that provide partial access.Granting access must not cede control of disclosure.
Public teams may not be direct or indirect members of a private project. Open teams allow anyone to choose to become a member, which undermines the owner's power to manage disclosure.
Subfeatures
None
Workflows
- Viewing a list of users and a summary for a single user.
- Granting access to a user or team
- Failing to grant access to a team that is open or a member team is open
- Revoking access to a user with full access.
- Revoking access to a user with partial access.
- Revoking access to a contributor?
Success
How will we know when we are done?
- An owner can see all users who have access to a private project.
- The owner can see how the use acquired access.
- The owner can see a summary of what the user knows.
- The owner can revoke a user and see what the user was unsubscribed from everything too.
How will we measure how well we have done?
- The canonical team is subscribed to all canonical projects.
Thoughts?
jml
- Owner, drivers, security contacts and bug supervisors are assumed to have full access.
- We should get a team within Canonical to beta test