Sergei Gridnevskii Rising Star

It depends on an issue. I can imagine a task like update 5000 records in DB that can be done by two DB admins in parallel. One can update 2000 and the other - 3000. Creator can be not aware who does what, he does not care, he wants the task done. Subtask is also not practical - after both do their part who should close…

> it's generally a bad practice to have one task assigned to multiple people It is a good practice if team consists of several people with different roles. E.g. Product Manager creates a task and assigns to Team Leader, the latter decides who will do that and assigns to dev, dev finishes and assigns to qa, QA checks and…

1. If you want to trick Atlassian create a group email for 2 or more employees and make 1 user in Jira. This works pretty well unless you don't care who personally works on the issue. E.g. you have a service and 3-4 guys that support it. Having one email for all is a good idea. And you pay much less for the license. 2. If…

It is a matter of taste. Generally speaking Resolved means that all works are done and Closed means that manager is happy with resolution and Epic is no longer needed. A rule of a thumb: if you ever searched for closed epics, you need Closed. Otherwise Resolved is enough.

I guess there are no components or versions in JSM projects. Also the info to custom fields visibility is a kind of irrelevant here. Also there is no need to make same statuses - they can be mapped to Jira Software project statuses on the last step of bulk move. Anyway if it is one-off operation (e.g. boss told to close…

2. Custom fields work fine in JSM, just create them as usual and add to portal form. I also recommend using contexts for custom fields, e.g. for one project and issue type selection can contain one set of values, while for another combination - the other. 3. I have no idea what Tempo is but any issue in Jira can have work…

I found solution, thanks Mayur. I have to add the check box to Email in first column and remove checkbox from Name, then delete Name row.

I guess user names in search/filters are a bad practice. Imagine the person you have on dashboards leaves your company. Information will become irrelevant and you will need to find all places where the person is mentioned (using GUID, not his name) and replace him with someone else. It is a nightmare. Using groups is more…

Well I tend to agree, I think this field was added by some plugin. Is there a way to restrict plugin to certain projects so that it does not interfere into normal work of Jira? And the second question - is there a way to find which plugin created the field so that I would uninstall it or write to developers to fix it?

There is no Restrict to field when I search it in Custom fields. I think it is a standard Jira field.

By the way I archived an old project that used Baseline start date and Baseline end date fields (Roadmap plugin) and now they are gone from my Fields configuration. Magic.

I know that I can hide them on screen level, this is not the issue. What I am talking about is that I cannot disable them in Field Configuration for this project. There is no gui for that

I created an issue type Approval with a very simple workflow: Open, Approve, Decline. Then I added an automation rule that is triggered manually. Whenever system engineer or developer runs it on the issue page, it creates Approval issue, links it as blocker to original issue and copies Summary and Description to this new…

What I need is a possibility to use nested JQL requests, e.g. linkedissues IN (project=DEV1). There are plugins that do this but this is so natural so why not do that in Jira itself? Changes you showed above are just cosmetics, no real value.

I have a pet project in Jira where I try all new features. Recently I created an Insight database of all pieces of hardware in our organization with links to employees. Also I have organization structure, buildings, access cards, software licenses, etc. It is so much fun to do that. Maybe some day I will show this to…

Hi Nic, I think you are right if your company uses Jira for one purpose, e.g. development. Ours uses Jira Software and Jira Service Desk. Most service desk projects do not need developers fields. Other than that we have 10% of business projects that are usually shown to investors and stakeholders to show progress of tasks…

This is pretty easy. 1. Create a new Service Management project (Atlassian has plenty of templates for a start). 2. Discuss which fields you need in requests. Rule of a thumb - if you need to search info in the field consider creating a field, otherwise Description is OK. 3. Create custom fields you need. I prefer to limit…

Usually I sit together with project manager, he tells me what he wants and I tell him if it is possible or not. This relates to completely new projects. For existing we just copy original project and set up new people in it. Also there is always a choice between complexity of a workflow and "state" fields. I have a little…

Thanks Hakan. Is it possible to create Insight object from rules? Also is it possible to edit attributes of an object?

Jimi, my Jira with 300 custom fields still has a potential for growth :) But yes, number of steps in workflow can be a good IQ test. I would say 5-6 is OK, 10 is silly and 15+ is "please call a doctor, this person has no idea what he is doing"

Paul so true. I have examples of workflows that consist of 20-30 steps. Its nightmare. They think that it's good but in fact most steps are meaningless and developers just click them through. Another example are workflows with lots of conditions. And developers asking me each time to give them rights to overcome…

If you have enough budget consider using Advanced Roadmaps. They are very good in strategic planning, you can create plans for years. No fields are needed, this plugin will do all the work for you.

The biggest issue for me as admin is 100500 custom fields that developers add here and there without thinking. So in this case policy would be 1. Use unique fields configuration for each project where you turn off all fields not related to your project - or - 2. Use Contexts for each new field where you list only one or…

Product Manager: Check if Joe Dow has access to Jira Me: Yeah, buddy, since 2014 Product Manager: I cannot assign issue to him Me: This has little to do with access to Jira. Have you heard about Project Roles? Product Manager: Comon I'm too busy for this stuff, just make it working now! Developer: I cannot access issue in…

We use Advanced roadmaps. They are a bit of tricky but overall quite good. Before Atlassian presented Roadmaps we used our own plugin that showed issues as a graph. It is a pleasure to know that you moved in right direction when it was not clear where to go :)

There are sad moments, nearly once in a month I report bugs to Atlassian. Last time it was the Approve step did not work if there are two transitions with the same name "Approve" - devs in Atlassian went the easy way and just selected the first one which was wrong. Also they implemented contexts for custom fields but just…

Mess. Dozens of developers, managers, qa and devops asking stupid questions about stupid things they do in Jira

Not a good idea to give addons all access to your data. Of course atlassian checks cloud addons, but who can be sure that the plugin does not have a time bomb or steals passwords or credit card numbers from issues? I would prefer that an addon lists required permissions in documentation and that admin can choose which…

Not a good idea - Jira Cloud will turn off display names at some point due to GDPR. It is better to use ids.

I accept this as a workaround, but for me this is not logical. In my case from time to time Customer support engineers needs to share requests with Accounting department. Your solution means that I will need to add all support engineers to Accounting organization. From my point of view it would be more logical to allow to…