Skip to main content
Planview Customer Success Center

Profile-Based Permissions for Projects: Additional Features/Updates with June Release

We have added some new features and tidied up some existing ones as we prepare to launch profile-based permissions for projects into GA. New in June are the following:

  • The ability to grant "Create project" permission using profiles
  • The removal of the requirement that a project have a parent (Department/Program).
  • The ability to bulk add teams members to projects (and bulk remove)
  • The consolidation of the Add Rule -> Users/Groups/Units menu options into "Global"

Each is described below.

Create Projects

You can now use permission profiles to grant permission to create projects. Previously, in order to create projects the user either needed to be a member of the Organization group, or be a team member of the Department to which the project will belong.

Automatic Provisioning 

Starting with the June release, the migration script will now provision the create permission to the appropriate users, the same as it provisions other permissions.

The automatic provisioning does the following:

  1. Creates a Project Creator group and populates it with users who today are on a Department team with Create Projects permissions
  2. Creates a Project Create profile that is configured with a Global Rule that grants members of the Organization group and members of the Project Creators group permission to create projects.

You can modify this setup as you see fit. You can add more users/groups/units to the Project Creators group, or remove users. You can decide that you want the Create permission included in a profile that grants project full edit rights by simply adding the Create > Project permission to that profile.

Manual Provisioning

If you have already run the migration and don't want to revert and do it again, you can take the following manual steps:

  1. Create a new permission profile named 'Project Create'.
  2. Add a Global rule to the profile and choose the 'Organization' group.
  3. Check 'Project -> Create' permission box in permission hierarchy.
  4. Create new user-defined group named 'Project Creators'.
  5. Populate 'Project Creators' with desired members (formerly Department team members with Create Project permission).
  6. Add a Global rule to the Project Create profile and choose the 'Project Creators' group.
  7. Save.

Department/Division no longer required

Note: In some environments, "Department" is call "Program"

We have lifted the requirement that a project belong to a Department. There is a still a Department team, but the "Create Projects" permission has been replaced with a new permission called "Can Create Parent Relationship with Projects". As mentioned above, Department team membership is no longer a factor in whether a user can create a project.

department_team.png

When you create a project, you are still presented with a Department droplist, but you are not required to enter a value.

Projects can already have relationships with portfolios. If you establish a project relationship with a Department, rollups and such will behave the same as they do today. If you choose not to associate a project with a department, rollups will stop with the project.

Note: If you want to take advantage of this feature, make sure the the Department (or Program) field is not configured on as 'Required' on the project Details page in SSA (Admin/Setup/Projects/Details).

Bulk Add/Remove Team Members

You can now add users, groups, units to the teams of multiple projects. This is useful for provisioning different team members to different types of projects. In addition, Bulk Remove Team Members allows you to remove users from a batch of projects. This is useful, for example, after the automatic migration, where users might have been place on project teams individually, rather than in groups. Or users might be on the team individually AND as part of a group. 

It's recommended to use groups (and units) as much as possible, as that makes future onboarding and provisioning of permissions much easier. For example, perhaps members of the Finance group always get Project Member permissions on all projects that belong to the Finance department. If you set up your groups/units correctly, and put the group on the teams of the appropriate projects, then you'll only need to drop new users into the Finance group and they will automatically get permissions to all Finance projects.

The facility is shown below:

  1. Navigate to the Projects list and filter for all projects that belong to that Department (not required, just an example).
  2. Select all the projects and choose Actions > Bulk Add Team Members.

bulk_add_member.png

  1. Select the group (or unit or set of users) and select the appropriate profile from the droplist. 

add_group.png

  1. Click Select.

Renaming of User/Group/Unit rule type -> Global

After running a few internal training sessions, we decided to consolidate and rename the User, Group, and Unit rules into one rule called "Global". Each of the former rule types gave global privileges to the select users, and was an alternative to giving users "team" access. "Global" is more straightforward and says exactly what it is.

Original menu and modals:

old_menu_combo.png

 

New menu and combined modal:

add_global_combo.png