2. Setting up users and projects (for admins)

Users and projects are the two most fundamental concepts in Sirid. Before you can start using Sirid you must add some users and projects to the system, and users to the projects. It is important to notice that a (non-administrator) user cannot do practically anything before he or she is assigned to one or more projects.

2.1. Users

New users can be created via the User management menu. Each user has five very important fields: Initial password, login name, user type, user name and email address. Other fields are less important and whether you fill them or not does not have a major impact on the system usability.

Initial password specifies the password the user can use to login to the system for the first time, and which the user should then immediately change. Login name is the name the user uses to login to the system. There is no restriction to the format of the login name but we recommend either first letter of first name and full last name, or full first name and first letter of last name. That is, for John Doe, either jdoe or johnd. Login name is thus the "writer-friendly" name of the user, while User name is the "reader-friendly" version, that is, the full real name of the user. User type specifies whether the user is allowed to do administrative tasks (tasks listed in chapters 1 and 2). There is no restriction to the amount of administrator users but it is recommended to have at most "a few" administrators. Email address specifies the address of the user where Sirid should send messages when some action concerning that user is taken.

2.1.1. User groups

User groups can be accessed via the user management menu (Manage user groups). User groups specify sets of users that have limited access to the projects. In practice the limited access means that members of user groups should generally see only tasks and bugs that are related to a member of the group. You could, for example have a group named "Subcontractor A" or a group named "Customers of project B". The members of this kind of group should usually see only a limited list of tasks and bugs. In the case of "Subcontractor A", the members of that group should only see tasks and bugs some member of that group is responsible for, and in the case of "Customers of project B", the members of the group should see only such bugs that have been added by a member of the group.

Sirid automatically takes care of showing only the appropriate tasks and bugs for users if you specify limited access rights when adding the user to the project. See section 2.4, Staff members for more information regarding staff member management.

2.2. Project folders

Project folders provide a way to categorize your projects. Using project folders is optional, while recommended if you have about ten or more projects. Typically you want the folder hierarchy to reflect different departments in your company or different types of projects. The first level of folders could contain such folders as Internal projects, Customized projects and Retail projects. These folders could further be divided into other subfolders if necessary.

2.3. Projects

Administrator users can add new projects via the Projects menu. Each project has only a few required attributes (such as name and folder) but in order for the project to be meaningful it must have also at least one version and some project members (staff). Most entries in Sirid are tied to a project or to a specific version of the project. For example tasks and bugs are tied to a specific project version while (currently) project specifications are tied to the project itself.

Administrators and users with the "Manage project"-access right can get to the Project management menu via the Projects page (Management). The Project management menu provides access to the various attributes of the project, such as basic project information, project versions, important dates, staff members, other access rights and project specific categories.

Project versions should specify clearly separate versions of the project. How "clearly separate" is defined depends on a project and your needs and it is difficult to give any clear guidelines of when one should add new version. Each version may have a starting date and deadline which specify the timeframe when the version should be implemented.

Important dates are currently meant to be like the CVS tags. For example, when you release a new minor version of your project (for which you do not create a new version in the system), you could add an important date stamp to indicate when that version was released. You can use these stamps for example when tracking changes between different release versions of your product.

Adding employees and other access rights is described in the next subchapter.

2.4. Staff members

Before a non-administrator user can see a project or make any modifications to it, the user must be assigned to the project and given the appropriate access rights. Users can be added to projects via the Project management menu (accessible via Projects menu [Management]).

Each staff member has a job description, status and a set of access rights. Job description should describe as well as possible what the user is supposed to do for the project. The access rights are the most important property of a staff member. They specify what the user can see about the project and what modifications he or she is allowed to do. The access rights assigned to the user depend on the role of the user. Project manager might have all access rights while a tester might be able only to view bugs and tasks and report new bugs.

In addition to staff members, the project also has "Other access rights" property. With other access rights you can make the project visible also to people other than the staff members. The most fundamental difference between Staff members and Other access rights is that only Staff members can be set responsible for tasks and bugs. You generally want to give these access rights to your customers so that they can directly report bugs and add feature requests to the system.