Jira Administration - Custom Fields & Screens

Jira has a complex administration concepts. Performing Jira admin tasks without understanding the complete flow leads to mistakes. In this post, I'm explaining how the Custom Fields are created and how to link it to project screens.

Creating custom fields
Let's assume you get a request to create a custom field "Severity". Check whether this custom field is already existing by

• Login to Jira -> Administration -> Issue Fields -> Custom Fields

If it is not available, create it straight away

• Login to Jira -> Administration -> Issue Fields -> Custom Fields -> Add custom Field -> Choose the field type -> Provide field name, search template, etc , applicable issue types, Applicable context.

   Custom Field Context

        The custom field which we created can be associated to all issues by selecting "Global context" or to specific projects. Depending on the usability of the custom field make it either global or project specific.

If the custom field is already exist, then try to reuse it.

Screens

Screens group multiple issue fields. Using Screens, you can control which fields are displayed. You can also split fields on a Screen into multiple tabs.

Configuring/Adding screens

• Login to Jira -> Administration -> Issue Fields -> Screens

You can define/edit screens with the above steps. 

How the screens relates to a project ?  [Screen -> Screen Schemes -> Issue Type screen schemes]

  A Screen Scheme allows you to choose which Screen will be shown to a JIRA user when they perform a particular issue operation (like Create Issue, Edit Issue, View Issue). You can specify the same screen for each of these issue operations, or choose different screens for each operation.

Creating/Configuring Screen schemes

• Login to Jira -> Administration -> Issue Fields -> Screen Schemes -> 

Here associate an Issue operation to a screen.

Linking screen scheme to projects

To activate a Screen Scheme, you need to associate it with one or more projects and issue types, using Issue Type Screen Schemes

An Issue Type Screen Scheme associates a Screen Scheme with issue types, allowing you to specify different Screens for the same operation (e.g. 'Create Issue') in the same project for issues of different types.

Create/Edit Issue Type Screen Schemes

• Login to Jira -> Administration -> Issue Fields ->  Issue Type Screen Schemes

The configuration of an Issue Type Screen Scheme involves associating an issue type(s) with a particular Screen Scheme. For example, associating the 'Bug' issue type with the 'Default Screen Scheme' and then associating the 'Improvement' issue type with the 'Improvement Screen Scheme'.

Associating an Issue Type Screen Scheme with a Project: Login to Jira -> Administration -> Select the project of interest -> Issue Type Screen Scheme -> Associate


How to add a Custom field to a screen ?
Find out the "Issue type screen scheme" your project is using Jira -> Administration -> Select the project of interest -> Issue Type Screen Scheme  -> Edit ( Here you will get to know about your screen scheme) -> Click your screen scheme [It will list the screens ]-> Select the screen -> Add Field  -> Add

Is your new custom field still not showing up on the desired screen ?

• Check  whether the field is hidden in Field configuration

           Login to Jira -> Administration -> Issue Fields -> Field configurations  -> Click configure of the desired field configuration scheme -> It will list all the fields for your project -> If the needed field is hidden, then click 'show' 

• Check whether your custom field context is restricted to specific projects 

     Login to Jira -> Administration -> Issue Fields -> Custom Fields -> Choose the custom field of interest -> Configure -> Edit Configuration -> Choose applicable context. 

      If it is restricted to specific project, then you can 

1. Add your project also
2. Or change it to 'Global context'

        Be careful and don’t configure a existing custom field to a project. This will then limit the custom field only to that project, removing it's visibility on other available screens.

How to know which projects/screens use a given custom field ?

  Login to Jira -> Administration -> Issue Fields -> Custom Fields -> Choose the custom field of interest  

 If the custom field 'Available context' shows any project, then it is restricted to that project. If no projects is listed in 'Available context', then look at the screens it is associated. A screen will be associated to a project through Screens -> Screen Schemes -> issue type screen schemes

Issue: Nexus is too slow in downloading pom files

Recently our nexus open source [1.5] version became too slow in downloading .pom files. It worked well for years, but it starting taking more than 2 mins to download a .pom file of size 422 Bytes. But it used download few files faster. Manually we could have downloaded the same file either using browser, wget or curl in fractions of seconds. But artifact download through maven got affected badly.

We new the changes happened in our network. Our nexus host machine got moved to a restricted network, where access to internet was blocked. Finally we nailed down the issue is either maven/nexus is trying to contact external public repositories for updates for each download and slowing down things.


Issue resolution: Re-order group repositories.

By default with nexus installation, we had “Maven central” in top of public repositories.

Since Maven central is blocked in our network, nexus got slowed down.

Now I put our own hosted repositories on top of the “Ordered Group repositories”.

Now every search for artifact is getting matched in our local repository, instead of going external network and hence download got faster now.


Login to Nexus -> Public Repositories -> 

ssh command run from Jenkins shell will take “/” as home directory

Issue:

ssh command run from Jenkins shell will take “/” as home directory and hence it tries to look for all the files in that directory like “/.ssh/known_hosts” & /.ssh/id_rsa. It typically happens in Windows cygwin shell

Environment:

 Jenkins 

 Windows Slave

 Cygwin

 ssh

Error:    

debug3: check_host_in_hostfile: filename /.ssh/known_hosts

debug3: check_host_in_hostfile: filename /etc/ssh_known_hosts

debug3: check_host_in_hostfile: filename /.ssh/known_hosts

debug3: check_host_in_hostfile: filename /etc/ssh_known_hosts

debug3: check_host_in_hostfile: filename /.ssh/known_hosts

debug3: check_host_in_hostfile: filename /etc/ssh_known_hosts

debug2: no key of type 0 for host library-blr.ap.rsa.net

debug3: check_host_in_hostfile: filename /.ssh/known_hosts2

debug3: check_host_in_hostfile: filename /etc/ssh_known_hosts2

debug3: check_host_in_hostfile: filename /.ssh/known_hosts

debug3: check_host_in_hostfile: filename /etc/ssh_known_hosts

debug2: no key of type 2 for host library-blr.ap.rsa.net

Build was aborted

Fix:

1) Run Jenkins service as “Administrator”. By default it will be running  as "Local user"
              Start -> run -> services.msc -> Jenkins Slave -> Right click -> Properties -> Log on -> This account ->

           Give Administrator & password.

       

       Then in  jenkins -> manage nodes -> Select your machine -> Disconnect -> Then reconnect.

       Make sure the slave is launched as "Windows service"

        The above step should fix the issue.

     Note: Step 2 is optional. 

2) Run Cygwin-sshd as “Administrator.  By default it will be running  as “cyg_server”

Jenkins upgrade > 1.444
If you upgrade jenkins to latest versions, again ssh commands through windows will hang for the same reason mentioned above.
The fix is not to run Jenkins service as 'Local user'. Now you can configure it through jenkins node configuration page.
Login to jenkins -> Manage Jenkins -> Manage Nodes -> Click on your node -> configure -> Run service as -> select 'Log on using a different account' ->
For ex: 
User name:   .\Administrator  
pasword:  ********

Note:  .\  in user name is must , otherwise it fails with 
ERROR: Failed to create a service: Status Invalid Service Account

Thats it !!