A "task" in TrackStudio is a generic description for an object to be tracked, such as projects, bugs, defects, versions, components, modules and so on, and allow the state of those objects to be tracked.
A task (item) in TrackStudio is a very generic concept. It is an instance of a category, and as you will learn further on, you can define a category with a particular workflow and custom fields to represent anything you like.
TrackStudio stores tasks in a hierarchy. The best way to explain this is with an example: after you log on to the system, you can see a task called Sample, Inc. This example company have configured their task hierarchy as follows: There are two folders at the top level called Products and Customer Support. Both of these items of category Folder contain items of category Product. When you click on one of the products in the Products folder, you will notice that the purpose is to track Product Version tasks. You will notice fairly quickly that all tasks, regardless of the category, have certain standard fields.
All the created objects (filters, workflows, custom fields) can be inherited, which means you do not have to declare the same custom fields and workflows for each new project. It is enough just to create a new project and it will automatically inherit all the properties common for this project group. You can also enhance the inherited objects to make them fit the specific project. To create a global object available for every task in the system, you must create an object attached to the root task.
Suppose some bugs appear in versions of your software both for Windows and Linux. The versions for different platforms are being developed by different teams and you need to track the bug fixes individually for every version. There are two common ways to ensure this:
In TrackStudio you can create several sub-versions of each bug (in fact, each of them is a lower level task of a special kind) and set up individual properties (handler, access rights etc.) for each of them. You will be able to view both the general information on the bug (e.g. the total time spent on fixing the bug in all versions) and the version or configuration-specific information (e.g. the list of all bugs not yet fixed in the Windows version).