Congratulation - you are now Jira project admin. And because you are not experienced with Jira, you are here on this page. Don't  be afraid of playing with your projects - you cannot damage other's work (Jira ask you if you really want to delete something) specially if the project is still empty, and we fix it anyway.

As project administrator, you have access to Project administration page. As admin:

  • You can set Components, Versions and Roles
  • You have to know how Permissions and Issue security works
  • You have to know how Issuetypes affect workflow and screen setting
  • If your project doesn't share schemes with other projects, you can partially set workflows and screens 
  • The rest in list is not important now and/or can be set by Jira  admins (TDS team).

Project board is the place where you will work at most. 

  • Any user can create a board, not only projects admins
  • You can create a board in top menu Boards → View all boards → Create board


But now, create a first issue.





If you go through this page you will be able to manage your project. For further studies visit Official Documentation or ask  directly TDS Team

Project setting

You can manage it or is important to know


Details

Here are the basic information of projects, names generally. 
  • 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 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.

This is advanced, additional setting. Don't look here until you understand the basics


Fields
  • 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

Security levels
  • 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.

Notifications
  • 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.

And that is all for project setting. And remember, there is a lot more in Official Documentation. 



Boards management


  • Let's start with the easiest way "Create a new board": Boards → View all boards → Create board
  • choose between Scrum board and Kanban board
  • Go to "To right corner Board" → configure
  • Official Board documentation

  • 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


  • Issue visualization by color based on queries, issutypes, stories, ....


  • Set up working days of the week and holidays


  • If you clock on any issue on board, the detail issue view is shown.
  • Here you can configure what is important for you to be visible on board.