Skip to main content
System StatusContact Support
VersionOne Community

Assigning a Project Role

This feature is available in all editions.

editions-all.png

Overview

A member's Project Role grants them access to projects based on the role they play (e.g., team member, project lead, tester, etc.) and determines if they can create, view, and modify project assets. This article is intended for project and member administrators responsible for assigning and managing projects membership and project role assignments.

About Project Roles

Here are a few important things to know:

  • A member's Project Role is different than their Admin Privileges role. See Roles & Project Membership for details.

  • A member may have different roles on different projects.

  • Project role assignments automatically apply to all child projects (unless explicitly changed).

  • Project role assignments made in a child project do not affect the parent or any other child projects.

  • At any level in the project tree hierarchy, a member's project role can be changed to increase or decrease project permissions.

  • You must have administrator or lead-level permissions to assign project roles to other members.

Before a project role can be assigned, the member must first be assigned to the project. This grants the member access to the project so they can see it in their Project Navigator and Project Tree. See Assigning a Member to Project for instructions.

Option 1. Assigning a Project Role on the Member Roles Page

  1. From the Admin menu, select Projects, and then click on the Member Roles tab (1). 

  2. Expand the project tree, select a project, and then click Manage (2) next to the project name. 

  3. For each member, select a role from the New Project Role/Owner List (3) drop-down list and then select the checkbox if you want the member's name to display in the Owners list.

  4. Click Save.
    ProjectMemberRole.png

Option 2. Assigning a Project Role on the Project Roles Page

  1. From the Admin menu, select Members (1), and then click on the Project Roles (2) tab. 

  2. Click Manage (3) next to a member's name. 

  3. Expand the project tree, and then select the roles from the New Project Role/Owner List drop-down list (4).

  4. Click Save.
    ProjectsMemberRoles.png

Project Roles Summary

These project roles work well for most organizations:

  • For most members, the Team Member role is sufficient. This is a great "go to" role that grants the user basic access to any project and will allow them to begin working immediately. 

  • Assign the Project Lead role to members who need to manage the schedule (e.g., Product or Project Manager).

  • Assign the Observer role to members who want to view progress (e.g., Executive Management).

 
Role Name
 
 
 
 
 
 
 
 
 
View Edit
Project Specific Access
Admin
(System, Member, Project)
Project Lead
Team Member
Developer
Tester
Customer
Requestor
Observer
Visitor
Inheritor
No Access
Projects
 
Feature Groups
 
Backlog Items
 
 
Tasks
 
 
 
Tests
 
 
 
Effort/Done
 
 
Portfolio Items
 
 
Issues
 
 
 
Requests
 
 
 
Defects
 
 
Retrospectives
 
 
 
Goals
 
Capacities
 
 
 
Regression Tests
 
 
 
Roadmaps
 
Rooms
 
Security
 
 
 
 
 
 
 
 
 
Sprint/Iteration Schedules
 
 
 
 
 
 
 
 
 

Role

Description

Recommended Uses...

System Administrator

This role is not the traditional super user role you typically think of  (e.g., Root for Unix, or Administrator for Windows). While they can make some system configuration changes, their access to projects can be restricted by their project and project role assignments.

For the project(s) to which they are assigned, they have full read/write access and can add and remove members, change member roles, and manage sprints and schedules.

This role is intended for individuals who are responsible for managing system configuration settings and managing members and projects.

Member Admin

Full read/write access to the project(s) to which they are assigned, including the ability perform member administration tasks and change member roles. They cannot make system configuration changes, but can manage schedules.

This role is intended for use in organizations where member administration can be delegated.

Project Admin 

Full read/write access to the project(s) to which they are assigned. They can create and edit all project assets (backlog items, including defects, tasks, tests, etc.). They can also add/remove project members and change project roles. They cannot, however, perform any system configuration or member administration tasks.

This role is intended for use in organizations where project-level administration can be delegated.

Project Lead

Project Leads have similar project-level rights as Team Member, but they can also create/edit Project details to which they are assigned, Goals, Roadmaps, Rooms, and Strategic Themes.

 

Team Member

(Recommended for most users) Team Members can view, edit, and create all project artifacts, including adding and removing items from sprints. Finally, they can view, but not modify or create the project schedule.

It is recommended that you use this role as the default for all members and assign other roles only as needed.

Developer

Developers can view all project artifacts, but can only create and edit tasks, defects, issues and requests. Furthermore, they can only log effort against a task.

Use this role only if you need to restrict a team member's access to development artifacts, otherwise you can use the Team Member role for a developer.

Tester

Members with this role can view all project artifacts, but can only create and edit test, defects, issues, and requests. Furthermore, they can only log effort against tests. Tester role can also work in Regression Planning and create Test Plans and Suites and generate Test Sets.

Use this role only if you need to restrict a team member's access to test artifacts, otherwise you can use the Team Member role for a tester.

Customer

Customers can view all project artifacts, but can only create and edit stories, defects, test sets, feature groups, goals, request, issues, and tests.

Use this role to restrict a member's access to business-related artifacts (e.g., the Product Owner in Scrum).

Requestor

Requestors can view all project artifacts, but can only create and edit requests.

Choose this role to grant access to managing input into project, but not the project work itself.

Observer

Observers have read-only access to all project artifacts.

This role is valuable for anyone (such as executives) who needs to track, but not edit a project.

Visitor 

Visitors can view backlog items but they cannot see any of the details (e.g., tasks, tests, etc.) below the items.

This role is useful for anyone who needs an overview of a project, but does not need to see detailed tracking information.

Inheritor

Inheritors can see a project in the project tree, but cannot access project contents.

Use this role on higher-level projects if you have read/write access to multiple low-level projects and need to coordinate plans or roll-up reporting. Members do not have access to information on the higher-level projects.

No Access

This role denies access to a given project.

This role is good if you want to grant access to higher-level projects, but you do not want the member to know that a lower-level projects exist