When configuring a permission to an object, the following options are available as the scope/application area (in parentheses are the alternatives, depending on the level of the object: a task, project, or the universe as a whole):
to this task and its subtasks (to the project and its tasks, to the universe and its projects);
only to this task (only to this project, only to the universe);
only to the subtasks (only to tasks, only to the universe).
Inheritance of permissions on the tasks at lower levels can be canceled, replaced by another set of permissions, or removed. For example, if you want a certain group of users to see the entire project, except one of the tasks in it, then you should set the “visibility” permission on “the project and its tasks”level, and then reset the inheritance on the particular task level. Thus the group will have the right of access to the entire project, except this task and its subtasks.
Note
Reset of permission inheritance gives you the flexibility to control access rights, but at the same time this feature makes the administration process more complicated. So, don’t overuse it.
When permissions are applied to the underlying objects (the third option, see above), the user is given limited permission to the parent object itself and can only partially see it. In this case, the limited visibility of the object means that the user can not see some of its properties, such as hours, budget, etc.
Discarding Inheritance
If, for some reason, you want to discard inherited access rights, uncheck the Include Inheritable Access Rights checkbox for the task selected.
As a result all the previously inherited rights will be marked as applied directly, and then discarded. After that you can edit local permissions for the task.