Content
View differences
Updated by Attila Dombi almost 2 years ago
**As an** Project admin
**I want to** provide permissions team members to view and edit project attributes
**So that I** can better control who gets the information.
**Acceptance criteria**
* There are two new permissions on project level:
* (1) View project attributes
* Migration: This new permission is added to all roles
* The specification used to say "to all roles that have the permission "View project"". "View project" is an internal permission that every role has so the requirement is equivalent.
* Seeding: Add to all roles
* (2) Edit project attributes
* Migration: This new permission is added to all roles that have the permission "Edit project".
* Seeding: Add to all roles that currently have the "Edit project" permission.
* Users not having the view permission in a project cannot:
* Find the project in which they lack the permission by applying a filter for the project attribute even if they have the permission to see the project attribute in another project.
* See the project attributes in the overview page
* The project overview spans the entire width, without the right pane
* See the project attributes in the project settings
* See the project attributes in the project list
* See the project attributes in the project list export
* See the project attributes in the API
* See the project attributes in the Schema API
* Users not having the edit permission (but the view permission) in a project cannot:
* Write the project attributes in the overview overview
* Write the project attributes in the project settings
* Write the project attributes in the API
* Write the project attributes in the Schema API (receive them as readonly)
**Out of scope**
* Permission on individual project attributes <mention class="mention" data-id="50179" data-type="work_package" data-text="#50179">#50179</mention>
* Global permissions
**I want to** provide permissions team members to view and edit project attributes
**So that I** can better control who gets the information.
**Acceptance criteria**
* There are two new permissions on project level:
* (1) View project attributes
* Migration: This new permission is added to all roles
* The specification used to say "to all roles that have the permission "View project"". "View project" is an internal permission that every role has so the requirement is equivalent.
* Seeding: Add to all roles
* (2) Edit project attributes
* Migration: This new permission is added to all roles that have the permission "Edit project".
* Seeding: Add to all roles that currently have the "Edit project" permission.
* Users not having the view permission in a project cannot:
* Find the project in which they lack the permission by applying a filter for the project attribute even if they have the permission to see the project attribute in another project.
* See the project attributes in the overview page
* The project overview spans the entire width, without the right pane
* See the project attributes in the project settings
* See the project attributes in the project list
* See the project attributes in the project list export
* See the project attributes in the API
* See the project attributes in the Schema API
* Users not having the edit permission (but the view permission) in a project cannot:
* Write the project attributes in the overview
* Write the project attributes in the project settings
* Write the project attributes in the API
* Write the project attributes in the Schema API (receive them as readonly)
**Out of scope**
* Permission on individual project attributes <mention class="mention" data-id="50179" data-type="work_package" data-text="#50179">#50179</mention>
* Global permissions