Security policy permissions
Each object type has its own access control table in the security policies. Each table displays access control sections for each tab, with rows that represent individual actions such as add, edit, delete, view, and so on. To configure permissions, you click the table cell that represents the intersection of an access role and a permission setting. Clicking in the cell toggles through the following settings:
Users in the role inherit the permission setting for the function either from their other project and object roles, or, if none of those have the permission specified, the appropriate default system role (Plan Administrator or Plan User) from the Global policy. If none of the roles they qualify for grants them permission, they are unable to perform the function.
If a user qualifies for more than one role, his or her access rights are cumulative. For example, if a user's security role grants different permissions than does his or her current project role, that user’s access rights include all permissions from both roles.
A permission block supersedes any other setting. For example, if a user's project role grants him access to the Budget tab of the projects created from a specific template but his security role blocks access to the tab, that user cannot access the Budget tab.