Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,293,502
Community Members
 
Community Events
165
Community Groups

How can I create a report that would list specific fields from any Jira issue?

Edited

How could I create a custom report that lists some fields for any issue I select?  I'd like the report to start with a text representation of status history.  Next would come specific standard fields, followed by some custom fields, in a defined order.

1 answer

Hi @Phil Bustin -- Welcome to the Atlassian Community!

There is nothing built-into Jira Cloud to create a report like that.  I recommend proto-typing the report you want on paper or in a document, and then investigate reporting options in the marketplace for addon tools to meet your need.

Kind regards,
Bill

The Internet provides tutorials on running searches and saving the queries.  I have to delve into that, but such an approach may work, if it provides output showing an issue's selected fields.

I also thought of creating an issue view that contains specific fields, but I have the impression that there can only be one view for, say, the closed status.

Correct; using an advanced issue search you could see the fields you want and the current status, but not the history of status values over time.  To do that you would need to view an individual issue or use an addon tool capable of visualizing that history.

Thank you. 

This is to replace an existing application for which separate fields store historic information.  For instance, Business Analyst Signoff, BA Signoff Date, etc.  The transitioner is automatically recorded in the field when the transition occurs.

 To do the same in Jira, I envision creating such fields, and configuring the fields to be populated automatically when specific transitions occur, assuming that’s possible.  I don’t need a history of status values.

Thanks for clarifying that!  With those custom fields, you could set the values using Automation for Jira rules...such as on status transitions.

Please take a look at this overview and example rules, and if it looks like it might help try creating a rule to make the updates.  If you get stuck, post images of your rule and I will try to help with that.

https://www.atlassian.com/software/jira/guides/expand-jira/automation

https://www.atlassian.com/software/jira/automation-template-library#/rule-list?systemLabelId=all&page=1&pageSize=20&sortKey=name&sortOrder=ASC

Once the values for the fields are saved your reporting could be produced using a saved JQL filter.

There is a sandbox project workflow, that has the statuses for which I wish to test creating rules to populate fields I wish to create.  However, the workflow is shared by production projects.

The seemingly obvious solution is to create a workflow that is only linked to the sandbox project.  It seems to me that whether I create such a workflow by navigating to the create workflow function from the project (as I've seen in a Community post), or from any other point, I will be able to link the new workflow to only that project before I create the workflow--in other words, creating the workflow will not pose any risk of affecting other workflows.  Could you confirm this?

Another seemingly obvious solution might be to create another instance of Jira that I alone can interact with.  Do you think that is an action fraught with complications, or a simple task to request of the admin who has that privilege?

In the documentation for which you provided a link, I clicked on the link next to the invitation to use rules in a sandbox.

Is there documentation on creating workflows that provides a sandbox?  If so, perhaps I could find my answer there to the question of whether I can restrict a new workflow to one project.

In the sandbox, I don't see a condition of a particular status being reached, if my terminology is correct.  In our sandbox, there are perhaps 6 statuses, all connected to the In-Progress entity (what is the term for it?) in the workflow.  I assume that these statuses are manually changed from one to another.

Not sure what you meant by "post images of your rule", since I don't see a trigger that fits.

A description of what I want is: When the user changes the status to [status name], populate field [name of field that is meant to contain the name of a Jira user] with the name of the status transitioner, and populate field [name of field meant to contain the date of the status change] with the current date.

Regarding a saved JQL filter, at first glance, I don't see how I could filter one issue for some of its fields, which is the result I'd like.  The filter seems to me to be for searching multiple issues, not presenting one issue with its fields.  I'm probably OK with just using the standard issue view instead, and pinning the fields I want in the right-hand column.

One more thought on that: I thought I saw documentation on creating a custom issue view.  I can Google that, of course.

Eureka moment: The Print view is perfect for what I need.

Catching up with your posts...If the "print view" meets your needs please try that.

For the use case you described, it may be enough just to create a test project in your site to experiment; probably no need for another workflow unless you wanted to change that also.  If you and your admin want to isolate the testing, you could create a test site for this first.

Regarding posting an image of the rule, I was suggesting to create an automation rule, and so I wondered if you had that.  For example:

  • trigger: transition to the status you want to monitor
  • action: edit issue to...
    • set the value of the user custom field with {{initiator}} who triggered the rule
    • set the date of the transition with {{now}}

How did I miss those?  I'll have another look...

Meanwhile, questions are: 1) Can I create a workflow and link it to only one project; 2) Can I create fields and link them to only one project; 3) Can the fields be updatable only by rule (not manually by user)?

Also, 4) Can I restrict specific statuses so they can only be seen by specific groups of users; and 5) Can I restrict statuses so that only one status is visible at a time (determined by rule, I presume)?  I know the last question would be moot if I just created more states in a workflow, but I have a directive to retain the default 3-state workflow.

I see that Jira uses the term Category for the 3 default states, and statuses can be associated with a Category.

In my private account, I tried to create a field configuration for my 6 or so new fields, of which I have created 1 so far, but that new field is not listed on the configuration page, so I'm stuck.  I'd set up the new fields as hidden and optional, since I intend to populate them by rule.

Hi, Phil.  Lots of questions and hopefully some answers to help...

First thing: when you are a site or org admin, please look for the gear icon at the top right of the view, select Jira Settings, System, and then Search Jira Admin.  When you enter some key words (e.g. Workflow, Status) it will take you to the correct place and offer links to help.  Note that the free Jira account does not offer all of the same features as a paid one, particularly around permissions and some configuration.

1) Can I create a workflow and link it to only one project;

Yes.  Please search for the workflows in admin functions to find this for company-managed projects (CMP).  For team-managed projects (TMP) this is accessed directly from the project.  Please look here to get started: https://support.atlassian.com/jira-cloud-administration/docs/create-and-manage-issue-workflows-and-issue-workflow-schemes/

2) Can I create fields and link them to only one project;

Yes.  For CMP custom fields are configured by the site admin and then adjusted to context and screens.  For TMP these are configured by the project admin directly from the project.  Please look here to get started: https://support.atlassian.com/jira-cloud-administration/docs/configure-issue-custom-fields/

3) Can the fields be updatable only by rule (not manually by user)?

In general, I suspect no.  To be updatable a field has to be on the edit views.  If instead you use something like entity properties those could be managed by rules and generally are not on the views unless you have marketplace addons.  Please look here to learn more about entity properties: https://developer.atlassian.com/cloud/jira/software/jira-entity-properties/

4) Can I restrict specific statuses so they can only be seen by specific groups of users; and...

I do not know that as I have never tried it.  I suggest posting that as a new/separate question to get more input from the community.  In the meantime, perhaps read up on issue security permissions to learn what is possible: https://confluence.atlassian.com/adminjiraserver/configuring-issue-level-security-938847117.html

5) Can I restrict statuses so that only one status is visible at a time (determined by rule, I presume)?

I am unclear what you mean by this, or even what a use case would be.  Perhaps create an example with more details and post this as a new question to get more visibility to the community to answer.  Regarding status visibility I suspect this could only be done by using different workflows by issue type and then changing issue type dynamically...and that has all kinds of challenges...which is why type change is normally a manual activity.

 

To reiterate, this thread seems to be expanding beyond your original question, so consider posting some of these separately.  Otherwise only the people watching this thread, or checking older ones, will see it.

 

Thanks,
Bill

Thanks.  Referring to 3) above: By 'updatable' by rule, I meant the field would be populated when a user changed the status to a particular value.  I would keep the field invisible to prevent user access to it, but the restriction is of secondary importance at the moment.

Regarding the link you provided for Rules, so far I can't find a place in my free Jira account to create one.  The page the link brings up says:

How to build this rule

  1. Navigate to your Automation settings and select Create rule in the top-right corner.

Which link do you mean?

I'm looking at a free site now and the paths to create automation rules are:

  • From the board, select the lightning bolt icon at the right side of the page to see options, or...
  • From the left-side of a project page's expanding options, select project settings and automation.

"Which link do you mean?"

Early on, you had provided a couple of links to Rules documentation

I thought I had posted a limited list of Rules options available when I click the Rules icon.  No trigger like "Update a field when a status is selected."

Ah, that's an oddity in Jira-speak. 

You do not actually select a status, or even edit it.  Status is not a field, it is a display of where an issue is in its life-cycle.  You change between status by using one of the outgoing transitions associated with the current step (status), which, in some places, looks like a selection!

TLDR: Look for the trigger "Issue Transitioned"

Like Bill Sheboy likes this

A user showed me that in the issue view, she clicks a button above the fields display column on the right, and advances to the desired status that way.  I do not know how that button was in the right place at the right time, but I need to know that.  Maybe the button was a transition.  I'll ask her to show me the button again.

Here are 3 screen shots: The To-do drop-down in the issue view; the workflow; and the Statuses as selected in the navigation bar on the left (gear icon Settings > Issues > Statuses).  All the names are the same, so I conclude these are statuses and that there are no transitions as such.

Drop-down.jpgWorkflow.jpgStatuses.jpg

Thanks, Nic.  To clarify, in our workflow, transitions have not been defined (not my decision).  The 'field' I was referring to is a field I wish to create (and have created in my personal account), that I wish to update by rule when a particular status is selected.

Yes, those buttons are triggers for the transitions.

You have loads of transitions in that workflow.  The arrow between "all" and a status is a transition.  The "all" just means that the transistion starting point can be any of the status in the list!

I understand that, and those transitions have no name.  Not a problem at the moment.  My goal is to create a rule that happens when one of those transitions is invoked or one of the statuses is selected--semantics or either or both--no matter.

The "all" type  transitions have the name of the status that they go into!

Thoughtful naming of statuses (states in other software) and transitions, in order to  distinguish the one from the other, is very helpful to users and administrators.  I recommend helpful.

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you