Amir Katz (Outseer) Expert

Respectfully disagree...As a Jira admin, I have browse permission to ALL the projects in our Jira instance. So I don't think this is the cause. Also, if this was the case, I would expect to get some results, from the projects that I have permission to browse and not get any errors at all.

Thank you! Wonderful? OK... easy? not so much...Solution? it's an ugly a hack :-)

We're on the cloud. My top apps (as admin), high to low: * JMWE * JEP (Enhancer Plugin for Jira) * ScriptRunner (the enhanced search) * JSU

This should be provided by the vendor as an inherent part of the product. It would be highly objectionable if such basic functionality is offloaded to a 3rd-party who will, no doubt, charge extra for that

Recently we had a mail-related problem and Jira support was digging into the mail logs - we had a Zoom session and I watched him do it. Clearly, there are no end-user/admin -facing interfaces, neither in the UI nor in the REST API. So if you have a one-time problem, they will help. On a related note: if the Jira Cloud gets…

Great article, @Jimmy Seddon ! Regarding deletion of tickets - We (Jira admins) are deleting test tickets that we create for testing purposes, but now that you mention this, I will moved them to Canceled/Rejected status. Or I may add a new dedicated status like 'REJECTED without prejudice' :-). Such change, will require…

Very true. However, IMHO, it merits a different thread, so I suggest we don't go down this thread by going down the rabbit hole of JSM vs. regular Jira, I'm sure this topic has been discussed ad nauseam :-) In my case, like Clare's, I inherited the JSM project. Not sure if I would have chosen it if it was up to me. But, as…

if you also have Jira, and you don't need all the bells & whistles of JSM, you may want to consider moving to a regular Jira project and saving the cost of the JSM Agent licenses.

Out of curiosity - if you're not using the portal, why did you choose JSM? SLAs? Queues? Other? Thanks

While we don't use this algorithm, I think it's an excellent idea. IMO it should be configurable, so there should be an option to choose between 3 options: * Leave unassigned (let Jira assign it by project lead/default assignee/some automation) * Assign to a specific (=fixed) user * Auto-assign as per OpsGenie schedule

I would implement it slightly differently. 1. If tickets are only created by CSR, then leave the reporter to the CSR person. 2. Add a single-select custom field for the customer (for example, if all customers are credit card issuers, values would be 'Visa', 'MasterCard', 'AmEx', 'Diners', etc.) and make it mandatory, so…

All good points. The last one is something that I also ran into...

This is from the latest documentation: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-group-and-user-picker/#api-rest-api-3-groupuserpicker-get

Good point! In our Jira, all the automations are per project and not global, and each has very specific conditions. So I wonder about this "global execution" - is this counting the number of times the automation was invoked or only the cases where the actions were performed after the "if" clause in it was true?

disclaimer - not a GDPR expert... I don't understand how GDPR is relevant here. If someone has worked in a company and they interacted with Jira, why is this fact considered a "secret" that needs to be redacted? In my mind, it goes against the well-established paradigm that you never go back and change the history. You can…

@Ste Wright idea of using automation and the issue.subtasks.size is a great solution. But, IMO, it needs to be tweaked as follows: 1. The trigger for the automation should not be 'issue transitioned', as adding sub-tasks can happen at any time and is neither considered a workflow transition nor related to any transition.…

I don't think that this is the correct response. @Phillip Talbot asked for a count of sub-tasks, not for the # of times an issue made a transition to a specific status.

One of the changes Atlassian introduced in Jira Cloud is to close the security vulnerability where you could add HTML code and/or URLs in a field description, which would make the Jira Cloud server run arbitrary (and possibly malicious) code or redirect to sites with malware. What they should do IMO is to allow the…

A more recent update - the 2nd one does not work either...I suspect it's the same problem - it assumes there's a issue link between the parent and child, and there isn't. For now, I gave up on the validator and instead I am using the simple, Atlassian-provided condition that checks sub-tasks statuses. From UX perspective,…

An update (for cloud) on the answer provided by @Radhika Vijji _Innovalog_ There are actually two JMWE validators with similar names. The one that Radhika mentioned ('Linked Issues Status Validator') does not work for me. I think that it relies on link type 'is parent of' which is not created by Jira when you create a…

Re de-duping fields - this is easier said than done, speaking from (painful) experience - replacing custom field A with B can be a lot of work, especially if you have a) many issues, projects and issue types using this field b) field is used in workflows (conditions/validators/post-functions), automations and other…

Minor comment - AFAIK, priorities in the cloud are global. There is an open feature request to have priority schemes in the cloud.

Good point. I tell people, "if you create a team-managed project, we (the Jira admin team) cannot support you." That usually works... I will look into blocking this option completely.

this is one of my guiding principles - use existing entities if they have the same type (e.g. for status, the requested status category) and if the name is close enough. Another best practice - we migrated 2 on-prem Jira servers to the cloud and now we have large number of unused entities. So I would take an existing one…

Here's my (non-exhaustive) list : 1. Have a small, trusted group of Jira admins 2. Establish best practices (e.g. "Do not create custom field with same name as an existing one") 3. Clean up entity sprawl - get rid of unused statuses, screens, custom fields, workflows (=inactive ones) and all kinds of schemes (screen, issue…

If you provide the team with a Kanban board where each person can see her tasks and the status of each task (each task is represented by a Jira issue), that will give them a single dashboard to see what they're doing (and need to do) and what other team members are doing.

I'm on Jira Cloud now, so I cannot validate my answer. However, IIRC, there is a simple validator, built-in in Jira (meaning no add-ons are needed) that tests that a specific field is not empty. As other answers have suggested, some add-ons also provide similar validators, with more functionality (e.g. run the validator…

excellent suggestion! thanks for reminding us about 'personal boards'

I just wonder what's the problem with users creating as many boards as they like. In my case, I didn't like the Kanban boards that someone created, so I copied it, tweaked it and now I have the board behaving exactly as I need. I think that letting users creating boards is a feature, not a problem. If you want to limit…

Regarding the suggestion about adding a new integer custom field as a counter (or several of those) and have automation and/or workflow post-functions increment it. It's correct that it will only work going forward. However, you can write a program (Python, Java) and use the Jira REST API to examine each issue's…