For managing large developer teams TrackStudio uses the system of delegation of authority (rights). Let's assume that we have two managers: John and Smith. The top manager can grant access to the Foo group of projects to John, and access to the Bar group of projects to Smith. After that both managers can grant access to specific projects, tasks and releases to individual developers or delegate this right to a lower level manager. 

In all cases the company management can access the summary or detailed information. The summary information includes the total amount of time spent by the Foo and Bar managers. The detailed information includes the list of tasks and employees involved in them, the detailed work description and the time spent on each task. 

At the same time access to information can be restricted so that the Bar manager will not even know that the Foo project exists, let alone the number of employees in another team and the number of projects/tasks assigned to it. So, the authorized persons (top managers) can access and analyze any information (this would be impossible if the data were stored in different databases), but the lower level managers and the employees can see only the information required for their work. If necessary, however, one manager can be granted access to some of other manager's tasks). 

To permit the user to access the task, you should specify the user status for this task and its subtasks. The initial user status is the same as the user status specified in the user header. You can change the access status by selecting it from the Status drop-down menu. If a user or a manager has access to an upper level project with a certain status, he/she will be automatically granted access to all subordinate projects. To give access to a subordinate project only, you can extend inherited status or override them. The users having access to lower level projects cannot access their ascendants (they can see only their names -- this is required to navigate the project tree). Please note that a user cannot grant access rights for a task alone. 

The user can perform some operation (e.g. editTask) when: 

1) The user has access to the task. 

2) The user status specified at the user creation or one of the access statuses to the task enables him/her to do this action. 

If the user does not have access rights to the task, only the user's own status is considered when determining available operations. When determining available actions for objects having the parent task (Filter, Workflow, Report etc), the rights for the object's parent task are considered.

To permit a user access to a task, you have to select it from the User drop-down list and press the Add User button. You can forbid access to any user by deleting him/her from the access list - just select user and click the Delete button. To delete an inherited item you should select the Access Control tab of the parent task. 

Suppose that there is a ROOT project, the first-level subproject projectA and the second-level subproject projectAA. In this case projectAA is the subtask of projectA. Suppose that the user with his/her own status viewer has access to projectA with the developer status and overrides the access rights to projectAA with the administrator status. Then the user privileges for projectA will be a union of privileges of viewer and developer statuses. The user privileges for projectAA will be described by administrator status.