Nic Brough -Adaptavist- Expert

You can not do this. The subscription for an app needs to match the highest number of people you have subscribed across the three applications. If, for example, you have 25 Core (JWM) users, 5 Service Management agents, and 65 developers on Software, then apps will be licences at 65.

See https://community.atlassian.com/t5/Off-topic-discussions/Ukraine-Invasion-by-Russia-what-response-from-Atlassian/m-p/1959789#M14159 for the main links on this.

How did you create the CSV file? I ask because the most common mistake people make here is to prepare it in a spreadsheet and then rename it, or not export/save as proper CSV, so they end up with empty lines or spurious columns. Also, check that the second line has data for the "summary" field. I vaguely remember an older…

Welcome to the Atlassian Community! Jira does have some automatic assignee functionality - the projects have a simple setting at the top level for defaulting to either unassigned or the project lead. If you're defining your "help area" with components, you can go further. Components can have a "component lead" assigned,…

I'd strongly recommend you stop looking at the database for this. There are at least five separate tables and conditional reads you'll need to understand the usage of in order to construct some (likely to be non-performant) SQL to replicate the JQL. What problem are you trying to solve by doing this?

No, they can't. A sub-task is only "in" a sprint as part of its parent issue. Unless you've defined your own Sprint field, which won't be the one Jira is using for the board.

Welcome to the Atlassian Community! A page id is the unique immutable id for a page, content id is the id for content (which may or may not be a page). What are you looking at here? Why are you asking about the IDs of the content, when you probably don't need to?

No, there's only one issue type that acts as an Epic. If you have Advanced Roadmaps though (a function of premium), you can create other issue types to act as holding issues like that though.

Don't ever do things like messing with Cron unless you fully understand what they are doing. You should read a tutorial or docs on Cron (and "find" if you're going to be using a command like the one I gave earlier)

If you've done all these moves within the UI (or over REST). then no, it should not be anything to do with issues being moved around. This is usually broken data in the database, which mostly only happens when people write to the database or write scripts that do bad things.

Could you show us the configuration of the board? What status are in what columns?

Jira's permissions model is permissive, not restrictive. To exclude a group from a dashboard or filter share, you have to not grant them access to it, you can't exclude them.

Assuming cancelling an issue means moving it to a cancelled or ending status, then yes, your problem is with the workflow. Either there is no transition from the current status into the cancelled or end status, or there is, but it has a condition on it that is blocking you from using it.

You'll need to get the scope corrected in that call. If there were an "alternative", you'd have the same problem with it.

This suggests people have been updating issues that were worked on during the sprint, changing what the sprint reports are reading from them

Ok, so someone is tagging you in Confluence. You'll want to ask the people who have asked you to use the Confluence about this.

What do you need in "elaboration"?

What do you mean by "alternative to"? There's a REST API call for getting transitions, why would you not use it?

To answer the implied question: "My understanding here is that setting up a scheme should allow me to define the issue types available across all projects we set up." That is only true for company-managed projects. Team-managed projects have their own way of doing issue types and they're set up on a project by project…

All I can tell you is that your workflow has a transition into the blocked status, and it is probably mis-labelled.

Welcome to the Atlassian Community! I'm afraid you are asking in the wrong place. We're a community of people here to talk Atlassian, we are not the administrators of your iShift Jira (they might be here, but they wouldn't expect help requests to come from here). I think you've clicked on "help with Jira in general"…

I do understand what has happened. I don't understand what you are trying to achieve or what question you want answered.

This means that your account has been claimed by the owners of the domain the email address was set for. You will need to talk to the administrators of that domain to get things changed on the account. ----- Tämä tarkoittaa, että sen verkkotunnuksen omistajat, jolle sähköpostiosoite on asetettu, ovat lunastaneet tilisi.…

You need to decide how you want to do these "defects". Either they should be raised as stories and then linked to other issues at the same level, or you should raise them as sub-tasks as they are a part of the main story. It's one or the other - either these are sub-tasks or they are not.

Go to Project -> People and remove them from there

You need to grant the dynatrace account the permissions to do what it is intended to do. Admin rights are wrong, the app doesn't need admin rights (and they don't mean "can do everything"), it needs permission to log in and act in the projects you've configured.

The Jira software application will create the field if it is missing. But only once. You have a human adding copies of the field here and you need to get them to stop doing it.

I'm not sure why you are worrying about the Toolkit app, the error message you have is that a custom field does not exist.

Yes, you can report in Advanced Roadmaps.

Check the permission schemes for the projects