Page History

Details

• Name - Human readable name of the project. Can be changed. 
• Key - unique identificator of the project. When we are asking for project, give us the key or link directly. Can be changed and even existing links are not lost 

Issutypes

• Issutypes defines what the issue is. Each Issuetype can have separate workflow or screens. 
• There are many Issutypes like Bug, Task, New Feature, Change, Request, ... Important is not the name, but the way you work with that (defined by workflows and screens)
• Epic - Are used as aggregation issues. Other issutyeps can be connected with epic via "Epic link" field. 
• Subtask - Subtasks are special type of issutypes which must have parent task. Generally, subtasks are used when your parent has a task includes many simple "subtask" and you want to track them.

• Workflows are one of the most important "feature" of Jira.
• The good workflow is the one, which when you show it to newcomer, he understands your work process immediately. Simple workflow is better than complex.
• Each issuetype can have own workflow and also each project can have own set of workflows. But workflows schemes can be shared across the projects.
• If the workflow is not shared with other projects, project admin can make basic changes in workflow - such as adding statuses and transition between them.Bigger changes can be done only be Jira administrators -  you want to use other workflow than default one, contact  TDS Team. They can add any statuses you want and they can add postfunctions - automation rules executing during the transition (auto-assigment, clearing of field) , or validators - checking values of issues during transitions (mandatory fields, user rights).

• Screens are the list of fields which are used on you issues. 
• Jira admins can create o new fields.
• Each issuetype can have own screens and also each project can have own set of screens. But screen schemes can be shared across the projects.
• Each issuetype have Create, Edit and View screen. Can be the same or different.
• Workflow transition can also have screens (you can set field values during the transition).
• If the screen is not shared with other projects, project admin can add existing fields on screen.
• Fields can be separated into tabs within the screen. Very useful for huge amount of fields.
• Before you add some field to the screen wait for a while and think - how will be the field used? For example  we will introduce a new field "Reopen" where we note if the issue was reopened. Users will mark issues as reopen, project owner will make analysis of reopen fields and also some action need to be done to reduce of reopened fields. If any of this  this steps is missing, the field is useless. 
• You can ask Jira admins to create a new field. You have to give us name and type (number, select list, text single line, text multiple line, date, user picker, ...). Note the step above. There are many fields which were created and never used. Every new field have a performance impact.  

• You can set here values for system field Versions
• In Jira issue, you can find versions as Affected version (where you find the bug) and Fix Version (where you fix the bug)
• You can mark versions as released 

• Components allows you to categorize issue within the project.
• Project admin can define the new components.
• Components can be set with default assignee - which can speed up ticket resolution

Users and Roles

• First go and read Permission section
• Project owner - responsible person, have to decide how the project (workflows, issutypes) should look like
• You can add a user or whole group to role
• Don't do it here! User management is solved via TDS Portal. In most cases, you shouldn't edit this page at all. Look here for help.
• Role admin - can manage project (set roles, components and version)
• Role developer -  have all write permission
• Role reader - can only see the issues and add comment
• other roles - special cases. Mostly, these roles are not mentioned in permission/ notification schemes and have no meaning. But for example when there is added an approval process, then you can use role Approver

Permissions

• Here is set how project rights are actually works.
• Can be changed only by Jira admins.
• By default, rights are connected mostly to Project roles, but can also add to group or individual users.
• Project admin can set Project roles (see Project role section).
• Role admin - can manage project (set roles, components and version).
• Role developer -  have all write permission.
• Role reader - can only see the issues and add comment.

• Here can be set if the fields are mandatory or hidden (this can be done in workflows and screens)
• It can be done only by Jira admins
• Nothing to see here for beginners

• Extension to Permissions, another level of security.
• You can hide particular issues. Example: Your customers can see all issues but no your  internal bugs.
• Security scheme can be set only by Jira admins.
• There is no default, all project security schemes are handled separately.

• Defines when emails are send.
• On every event (issues commented, created, edited) can be defined who (reporter, assignee, particular user, group ) will receive the email.
• Can be set per project.
• Jira can spam a lot, so we keep notification schemes simple as possible.
• Can be edit only by Jira admins. 

• Jira project can be connected to Gitlab repositories.
• You can see branches and commits from you issue.
• You can even create branches from the issue.
• In case of any question, please contact TDS Support Team

• Powerful test tool.
• Adds separate issuetypes, workflows and fields to your Jira project.

• Name - self-explanatory.
• Administrators - users who can set-up configuration section. Administrators can't change the mail filter.
• Filter - the main filter is set during the board creation. It is an eider project board ("project = 'XYZ") or board based on my, existing filter ("project = XYZ and component = this one and label = some"). Only board owner can change the filter. Jira's admins can change ownership of the filter
• Sharing - accessing project and the boards is often the same. But board admin can change it.
• Kanban sub-filter - you can hide here the issues which are already done. Don't change the default unless you know what are you doing. 
• If you miss some issues on board, check the filters.

• Boards are a different view of the projects. In project workflow you define statuses, but here you can redefine in way which personally suits you the best (As developer you might not be interested in planning, analyzing phase).
• Here you can set columns on which are the workflow statuses mapped.
• You can map several statuses into one column.
• Issues with status, which are not in any column, are not on the board at all.
• If you miss some issues on board, check the columns.

• Here, you horizontally sort issues on board
• You can make swim lines base on predefined types (assignee, story) or n your own, more complex filters (assignee = 'XYZ' or assignee = 'ABC')

• Reduce number of visible issues on board to see what is really important to you