Kelly Arrey Expert

Yes, I knew I could search for a specific issue by typing in the key, but I didn’t realize it supported more arbitrary text searches.

Hi @Zeinab Alaoui , @Alex Koxaras -Relational- Perhaps it would be helpful to try and clarify this situation a little: * A "Field Configuration" defines which fields are required or optional and visible or invisible for a specific issue type. * A "Field Configuration Scheme" is used to associate specific "Field…

Hi @Navraj Sharma, * Is there a sub-filter further down the page? * What's your "Hide completed issues older than" setting?

Hi @akhil dev, Hi @Dave Mathijs, Just me thinking out loud but if you create 3 separate Screens as Dave has described, I think you could then hide the field by not including it in the Layout for the issue type? Hope that helps, Kel

Hi @Pillai_ Aarthi I don't think you can do that today, but it's a great idea. Perhaps you'd like to add it as a comment to this article?

+1

Hi @hiroyuki.fujiwara The membersOf() function searches Jira groups, so if you're using the Team field, I don't think it will work. This is yet another reason we use a custom single select field we call Agile Team instead of the Jira-supplied Team field, and define Jira groups with the identical names to map members to…

We've been using a custom single-select field we call "Agile Team" since long before Advanced Roadmaps, and it works great - we can use the Agile Team name in JQL, and we've also created Jira groups with the same names as the Agile Teams.

Hi @Ivan Andrieiev One approach you could try that doesn't involve automation is an Assign transition: * Make sure your Screen Scheme includes a separate Edit screen which does not include the Assignee field - * Add one or more Assign transitions to your workflow* you can make them transitions to the current status e.g.,…

Hi @Nicole Ritter, we also use Worklogs by SolDevelo and recommend it highly. 

Hi April, the part I don't understand is how the rule is supposed to know which issue to link to - for an arbitrary CAT-x ticket, should it link to PETS-1 or PETS-2 or PETS-3 or ... ?

You could add a validator for each of the relevant fields in the workflow transition, and include a message. This won't display an *, but if the field is on the transition screen then the user can fill them in.

How does the automation rule know which epic to associate the tasks with? 

Having said that, this is weird. I run a quick search query like: PRJ MOD It pops up the filter results page with the following query `project = PRJ and text ~ MOD`, with 6 hits. So far, so good. Oh, and thank you for this little message: Ok. Let's run the search without smart query: Now you get one hit? What? So what…

Didn't know it worked that way. Looks handy. Perhaps a wider search bar with a bit more contextual help would get people to use it more, for example Quick Search, e.g., PRJ search words and a contextual help button in the search bar (like you have on the JQL search bar) for further explanation.

In company-managed projects in Jira Software, you can have issue types with different workflows on the same board - you just have to map the relevant statuses to columns.

Or, if you have a transition from Closed to a prior status, move it back to the prior status and move it back to Closed (assuming that the Close transition sets resolution correctly).

@Fuji Unfortunately I'm not an expert on team-managed projects. I know that company-managed projects are more mature than team-managed, and provide more flexibility, but I don't have enough experience with team-managed to be able to explain the differences in detail.

Lately, we've added three formula columns to our structures to replace the Original Estimate, 𝚺 Remaining Estimate, and 𝚺 Time Spent columns: * OrigEstDays, i.e., the Original Estimate, in days, for which the formula is: * `Original_Estimate/1000/60/60/8` * SumRemDays, i.e., a roll-up of Remaining Estimates for the…

As an aside, we've also defined Jira groups with identical names, so you can do JQL queries like: `"Agile Team" = "A-Team" AND assignee not in membersOf("A-Team")`

Hi @michelle.purcell We've tried to use the built-in Team field with no success. Instead, we've created a custom single-select field we call "Agile Team". This supports using the team names in JQL as well as in automation. Usual disclaimers apply: YMMV, deuces are wild, etc.

Hi @yasin.donmez , as @Najm Polaris has suggested, you may want to add another column to your board. One idea is to have a column where the developers put the tickets they *think* are ready for testing. Then, the test team can validate that they really are ready for testing and move them to the testing column, or move them…

As an aside, why would you need to "validate" the project category every time a story moves to In Progress? How often does your project category change?

Hi @EduardCampo Usual disclaimers apply, YMMV, deuces are wild, etc., but I'd recommend sticking with the out-of-the-box issue hierarchy where Stories, Bugs and Tasks all exist as standard or base issue types, not sub-issue or subtask issue types, and they can be grouped under Epics, for the following reasons: * Anyone…

(Just me thinking out loud, but is there a way in that roadmap view to: * filter out the tasks in Closed/Done status * sort the remaining tasks in descending order of status?) 

Hi @Eamon McCracken I don't see the screen you've shown above on my system, so not sure how much help I can offer. Two possibilities come to mind: * My understanding is that the Original Estimate and Remaining Estimate values start out "linked", so that the Original Estimate value will populate the Remaining Estimate field…

As an aside, in a company-managed project, you have the option of setting Swimlanes by Assignee, and you can see both tasks and sub-tasks in that view. 

Captain Obvious here. If you're just getting started with Jira, one way to get around this is to use the component field - create components BE and FE, and set the component value for all your tickets appropriately. Now you can filter on `component = BE` to your heart's content.

There is a way to do something like this out of the box: * Create components in Jira * Make your team members the component leads for the components where they are the experts * Make the component lead the default assignee Then, when an issue is created in component 'x', it will be assigned to the component lead for 'x'.…

It sounds like you will want to implement several automation rules with different triggers, e.g.: * when assignee changes to one of your team members * when ranking of an issue on your board changes * when someone comments on an issue * when someone adds a label * when someone changes a component