Permissions FAQ

Project Permissions

See also Project Profile Permissions Example Cookbook.

How come the project owner is on the project team with a Project Member (view only) profile but can edit the entire project?

Any resource that is a project owner by default has edit/view permission on the Details section of the owned project. You can increase the project owner's permissions by editing the Owner permission profile and selecting additional permissions from the Permissions Hierarchy. Permissions are always additive, so if the Owner profile offers more permissions that the team profile, the Owner profile wins. Note that if you went through the project permissions migration of 2017, then the project owner might have been put on the project team as a result of the migration. Or, the project owner might have originally been a team member and then was subsequently assigned ownership of the project. Regardless of how the resource was placed on the project team, the most lenient profile is used.

How do I configure permissions so that certain users have access to projects in specific Departments (or Divisions, or Categories)?

Please see Distribute Project Permissions Based on Department.

How do permissions work with regard to the unit hierarchy - since units can contain other units, do permissions applied at the parent unit also get applied at the child units?

Generally speaking, permissions applied to/on a parent unit cascade to members of child units - with one exception: permissions are not always granted on the unit managers. See below:

• Any permission granted TO a unit (like when you add a unit to project team along with some permissions), those permissions are granted to all the unit members and all child/grandchild unit members AND to their corresponding unit managers.
• Any permissions granted ON a unit (like from a special access rule), those permissions are granted on all the unit members and all child/grandchild units, but NOT on the corresponding managers. 
• Granting permissions at the root unit should be analogous to granting permissions on All Users.

See also How Do I Grant Units Access to Specific Projects.

How do I assign a permission profile to a group?

Groups can be used with Team or Global profile rules. Let's assume you've either created a user-defined group in Admin/Groups, or you want to use a standard group. 

• For a profile with a Team rule, you associate the profile with a group when you add the group to the team of a project. Navigate to the project's Team: Profile-Based Permissions page, click Add, choose the group and then choose the profile from the droplist at the bottom of the dialog. 

• For a profile with a Global rule, you'll select a group in the Add dialog. Click New profile, then select the Global rule. In the dialog that appears, click the Group radio button, then select the group you want to assign the permission profile to. 

What is the difference between a team and a group?

A team refers to the set of people who have some kind of permission on an instance of entity, such as a project or portfolio. For example, a specific project can have many team members, and each team member can have the same or different permissions on that project. Each time a user/group/unit is added to a project team, a permission profile is added along with them that defines the permissions they have on that specific project.

A group is an arbitrary set of people that have been put in the same "bucket", allowing them to be assigned to team or permission profile at one time. Groups are useful if you have a set of people that need to be treated the same way. For example, a common group is a "contractors" group; you might want to add this group of people to project teams with the same permission profile - it is much easier to add a group of people than add one person at a time.

How do we associate entities with permission rules (how are permission rules related to entities)?

You can use a Global permission rule to apply permissions to an entity type as a whole. For example, if you want to give a user/group/unit Edit permissions to all projects, you would create a profile, add a Global rule, select the user/group/unit to give the Edit permission to, and then select Project > Edit in the Permissions Hierarchy.

You can also use an Association permission rule to give unit members permissions on associated projects or portfolios. See How Do I Grant Units Access to Specific Projects.

When we create a Team rule, we do not see entities like Resource and Requests - how come?

Resource and Request entities (as well as Divisions, Departments, and Enterprises) do not use this permissions model yet. Resources are targeted for 2018.

What are the definitions of Owner, Team, Global, Association permissions rules?

All the permission rules are defined at About Profile-Based Permissions.

Where do I get the permission hierarchy information for Full User, Admin, and Time user types?

In the legacy permissions model, Full Users automatically had View permissions on all projects. If you perform the automatic migration, the Full Users group will have a profile with a Global rule that gives them the same View access to all projects. You can always delete this rule if you don't want all Full Users to see all projects. The thing to remember is the Full Users will not have any implicit permissions - they will have only the permissions you give them with permission profiles and rules. Note that if you do not see a Full Users standard group, you can create a custom filter-based group that uses a filter based on user type = Full User. The custom Full Users group will be maintained automatically - any time a new Full user is added to the system, it will be added to that group.

Admin users still get access to the Admin tab. You must use permission profiles if you want to give them additional permissions. For example, you can make a Global rule that gives the Admin group permission to edit all projects.

Time users types will have no additional permissions outside of seeing tasks they own or are assigned to, and issues they own. For example, if you add a Time user to a project team with View permissions, the Time user will NOT be able to view the project because that user type is not allowed to view projects.

Also note that there is no difference between Team Users and Full Users in the new permissions model. If you are using Team Users, you do not need to make any changes; those users will still only be able to see the projects on which they are team members. However, if you choose to, you can give Team users access to all projects by using a Global rule.

I gave a user read-only permissions to a report, but she can still edit it. Did I do something wrong, or is this a bug?

If you put the user on the report team with a profile that grants read-only permissions, and the user can edit the report, then the user is getting edit permissions from a different profile. Most likely there is a global profile that is granting edit permissions to a group or a unit that the user belongs too. Use the Permissions Explorer to check who has permissions on the report and how. When you see your user in the list, click on the user and see how many profiles are listed - one of them probably grants edit permission.

I created my project with no parent department, but when I edit the project I can't save my changes because the Department field is empty and is behaving like it is a required field. I thought that projects no longer required a Department?

It sounds like the Department field is configured as a required field in SSA for projects. Navigate to Admin/Setup/Entities/Projects/Details. Locate the Department field and select it. In the right-hand side, uncheck the "Field is Required?" checkbox.

My organization is "high trust" - is there any way I can give permissions to everyone to be able to view and edit projects?

Yes, create a profile with a Global rule and Add the All Users group. Configure the project permissions you want all users to have, perhaps full edit. Save the profile.