A colleague asked me if he could use sub-tasks under Features or only under Epics. Sometimes people get confused about the naming of our custom issuetypes.
We use Epics (which are basically issuetypes with a superiority complex) to house our Feature and Story issuetypes. Sub-tasks cannot be added to Epics – it’s just the way it is. But I did add Sub-Tasks to Features to break down what needs to be done in the planning stage.
So… I wanted to give him an example of a Feature issuetype that had sub-tasks. The Atlanta Community and ScriptRunner came through again and I found this:
project = “My Project” AND issueFunction in hasSubtasks()
I wanted a way to find all components lead by a Lead Developer and list them on a Board’s Quick Filter. We have some leads that manage multiple components and needed a way to display all Lead Devs’ Components.
I could have created the jql to say:
component in (component2,component3)
but components could get added. The more constant variable was the developer username (greater chance of a component change than an employee change). This is what I used instead and I hear it’s an out of the box function; not from ScriptRunner.
Short answer: you can’t change a field type (ie. from Text to Single Select), you have to create a new field and transfer data from one field to the next.
In our scenario, we had a field type of checkbox and only had one option: ‘Yes’. If it wasn’t selected, then we didn’t need that option added for a client.
Over time, we found that it would be better to have a definitive answer from the account manager on whether the option was needed or not. We needed a Single Select list of: No, Yes, TBD (‘none’ is added automatically by Jira and displays in first position).
First we used the Botron (now AppFire) app of Power Admin to tell us which screens, filters, projects this field would affect if we updated it.
Then we updated the field name with a suffix of DELETE which would change the name anywhere it was referenced.
Then we created the new Custom Field as a Single Select with the aforementioned values -and- as part of that Custom Field creation process, we were prompted to select the screens where it should appear. (Remember, up above where we found all of the screens that would be affected in Power Admin?)
Note: The new field always get added to the bottom of the screen.
We also had to determine the Projects and Issuetypes in which the new field could be found/used (we try not to use Global config) by selecting Configure to the right of the Custom Field to display the “Modify configuration scheme context” page. On this page, we selected the Issuetypes and Projects allowed.
Then we used the Tools > Bulk Change process to update the new field with the old field values. (that’s for another post)
Then we removed the old field from any screens and filters and and moved the new field up to the correct position in the screen.
After a few weeks, we will delete the old field from production and test.
Oh – and – yes, we did replicate the updates in our dev Jira environment, AND we documented this process with screen shots in the Jira Task that was assigned to me to carry out this endeavor.
Document! Document! Document!
FYI – no Confluence yet, but we submitted a request to Finance. Woot!
I was asked to find all issues in the previous 3 Sprints that are not linked to anything. Fortunately we have Adaptavist ScriptRunner, so I just ran this:
Sprint in (411, 413, 415) AND issueFunction not in hasLinks()
Unfortunately, you only get Jira keys in the result, and you would have to open each one to see details (ie: issuetype, Summary). One of our protocols is to ensure that every Story worked on in Engineering is linked to a Feature issuetype. We categorize our versions by Features.
I had to go back and update this post:
removed project filter because these Sprints were already in the Engineering Project and it was superfluous.
removed status because that wasn’t the ‘ask’. Not all issues get completed in a sprint, so you might want to add that.
removed a check by resolved date and didn’t need that either.
Today an engineer needed access to production Jira custom field IDs. Should I give him Jira Admin access?
Background: Jarod (name changed to protect the innocent) has access to Jira Administration in our dev Jira environment to test an API. The problem is that the current Jira Admins (#guilty) replaced fields in Jira prod but did not reflect updates in dev (that’s for another post – do what I say, not what I do). This means that he will be testing in dev Jira but fields in prod will be different. (sorry, Jarod!).
Instead of handing out Jira Admin access for x amount of time, I showed him how to find custom field IDs using the Issues > Search process.
Select Issues > Search
Select Advanced search (where you can type in JQL by hand)
Start typing custom field name; the auto-complete area will show the ID next to the field name