Example of Privilege Check Flow for Cockpit Items (such as Requirements, Voices, Tests, Risks, Folders, Sections etc) Item (Req, Voc, Risk, Test) Project Owning Group An item first checks if privileges have been explicitly set on itself. An item then checks on its owning group (sometimes called as primary group) An item finally checks for privilege settings on the project.

Privilege Check Flow for Groups (such as physical groups, breakdowns, directories and documents) Group Project A group first checks if privileges have been explicitly set on itself. NOTE: A sub-group does not look at privileges on its parent group. It checks if privilege settings have been explicitly set on itself, and if not it goes directly to the project and checks for privilege settings on it An group then checks for privilege settings on the project.

Example of Privilege Check Flow for Cockpit Items (such as Requirements, Voices, Tests, Risks, Folders, Sections etc) Requirement – SubReq3 first checks for explicit privilege definition on itself Then, it checks for Privilege on its Owning Group – Owning Group of SubReq3 Finally it checks for privilege on the Project – Privilege Demo Project Item Req, Voc, Risk, Test Project Owning Group An item first checks if privileges have been explicitly set on itself. An item then checks on its owning group (sometimes called as primary group) An item finally checks for privilege settings on the project.

Example of Privilege Check Flow for Cockpit Items (such as Requirements, Voices, Tests, Risks, Folders, Sections etc) Requirement – SubReq4 first checks for explicit privilege definition on itself Then, it checks for Privilege on its Owning Group – Owning Group of Top Level Reqs Finally it checks for privilege on the Project – Privilege Demo Project Item Req, Voc, Risk, Test Project Owning Group An item first checks if privileges have been explicitly set on itself. An item then checks on its owning group (sometimes called as primary group) An item finally checks for privilege settings on the project.

Where do you see the owning group (primary group) of a requirement? 1 2 3 4 5 4 Note the display setting for a requirement in the Primary Group Settings area which says requirement display should be qualified by owning group 1 Select a requirement in TOC 2 Switch to the Details page on the right 5 Note the display of requirements being qualified with owning or primary group 3 Note the Primary Group Settings on the page. Use this to either change Owning/Primary group settings for a requirement

Privilege Check Flow for Groups (such as physical groups, breakdowns, directories and documents) The group “Owning group of Top Level Reqs” first checks to see if privileges have been explicitly set on itself. NOTE: The sub-group does not look at privileges on its parent group. It checks if privilege settings have been explicitly set on itself, and if not it goes directly to the project and checks for privilege settings on it The group then checks for privilege settings on the project – Privilege Demo Project Group Project A group first checks if privileges have been explicitly set on itself. An group then checks for privilege settings on the project.

Privilege Check Flow for Groups (such as physical groups, breakdowns, directories and documents) The group “Owning group of SubReq3” first checks to see if privileges have been explicitly set on itself. The group then checks for privilege settings on the project – Privilege Demo Project Group Project A group first checks if privileges have been explicitly set on itself. An group then checks for privilege settings on the project.

Different kinds of Privileges There are two types of privileges in the Cockpit application: System privileges These are system (domain) wide privileges that determine what a user can do within the application. Project, Document, and Item privileges These are privileges that determine how users and groups access specific projects, documents, or items in the application

Different kinds of Site Privileges The types of Site Privileges available in the Cockpit are: Privilege Type Description System Administrator Determines who can access domain maintenance commands. Provides complete access to all project privileges. Create Project Determines who can create a new project. Customization Determines who can have access to define User Defined Attributes, Table Definitions, Page Definitions, Filter and Grouping definitions etc. In other words, this privilege determines who can have access to an internal custom query/script builder called ASE to write custom searches, queries, section formats etc.

Different kinds of Project, Document and Item Privileges Privilege Type Description Modify Determines who may modify the project or project item. Delete Determines who may delete project items. View Determines who may view the project or project item. Project Admin Determines who has general administrative access to the project, including assigning and removing project privileges Approve Versions Determines who may approve versions of the project or project items. Manage Voices Determines who may create, modify or delete Voice Of Customer data in the project. Someone without a Delete privilege (which gives persons access to delete any data item) can delete Voice of the Customer data with this privilege. Manage Requirements Determines who may create, modify or delete Requirement data in the project. Manage Risks Determines who may create, modify or delete Risk, Cause and Mitigation data in the project. Manage Tests Determines who may create, modify or delete Test data in the project. Define Structure Determines who may create, modify or delete Structure (document breakdown, product breakdown, BOM Structure etc) in the project.

Investigating Privileges on a Person Lets look at Persons A, B, C Note that at the Site level, they have Create Project Privilege

Investigating Privileges on a Person Now lets look at a typical team setup on a project. Note that the team is divided into role based groups on a project. Notice the home page for “Team”. Note that even though the team has been divided into role based groups, the groups have NOT YET BEEN SPECIFIED to be the ones managing the privilege of its members. So currently, the groups serve just as a visual indicator.

Investigating Privileges on a Person Now lets look at a typical team setup on a project. Note that the team is divided into role based groups on a project. Note that Person A and Person B belong to a group called General Users Note that Person C belongs directly to the team.

Investigating Privileges on a Person Lets set the group General Users to be the Managed Item i.e. we are indicating the privileges set on the group General Users will be Inherited by its members (i.e. person A and B). Note that privileges for Person A and Person B will be managed by the group “General Users” This reduces the burden of managing privileges individually on persons.

Investigating Privileges on a Person Lets now investigate privilege on the PROJECT Grey Checkbox means IMPLIED privilege (a result of a green checkbox) Green Checkbox means direct privilege. Blank Checkbox means NO privilege. For e.g. if you have a GREEN checkbox for Modify, you will get a GREY checkbox for the View privilege (implied). If you want to uncheck View, uncheck modify first and then you can change the setting of the View privilege.

Investigating Privileges on a Person Lets now investigate privilege on the PROJECT Being a member a project team guarantees all privileges except Project Admin and Approve Versions. So currently Person A, B and C all have the same privilege.

Investigating Privileges on a Person Lets make the following changes to the privileges on the Project 2 3 1 1 Grant Delete privilege to the group General users Uncheck Project Team privilege from Person C (note all privileges disappear). Grant him View Privilege So currently, for the project – Person C can only view things. No modify or delete privilege on any project items. Person A and B have full View, Modify and Delete privileges. 2 3

Investigating Privileges on a Person Now Click on any group that is contained in the project. Note the inherited privilege settings from the project. Person A and B have View, Modify and Delete privilege Person C has ONLY View Privilege

Investigating Privileges on a Person Now lets change privileges on this group Specifically grant modify privilege to Person C for this group Note that Person A and B (and other groups such as marketing and quality control etc) all lose their Modify privileges. So, giving Modify privilege at the item level gives full control to ONLY the specified individuals. People with Modify privileges at the project level are unable to override this explicitly stated privilege at the item level.

Investigating Privileges on a Person Why did a few items retain their Modify privilege? e.g. Research and Development Group, Hal Berman etc Note that the Research and Development group has been granted Project Administrator privilege at the project level. Note that Hal Berman is a Project Administrator.

Investigating Privileges on a Person Summary: Lets assume that there are three people (A,B,C) at the project level ALL with Modify privilege. Now, if we explicitly give Modify privilege to only one of the people (e.g. C) on a sub item such as requirement, group etc, then ONLY that person will have Modify privilege on the particular sub item. (i.e. C can modify sub item but A and B cannot) Note: Lets assume that there are two people (A,B) at the project level with a certain “Manage” privilege (VOC, Requirement etc). Also lets assume that C does not have the “Manage” privilege in question. Now, if we explicitly give a “Manage” privilege to an additional person (e.g. C) on a sub item such as requirement, group etc, who previously DID NOT have the “Manage” privilege A, B and C ALL will have the “Manage” privilege on the particular sub item.