Nic Brough -Adaptavist- Expert

No, Jira Cloud did not add a resolution field to your issue creation screen. One of your admins did it. Remove the mandatory flag that they added from the field configuration and it should go back to working.

What are you trying to do with this command? It has invalid arguments, so I'm wondering where they came from?

If you've done the Atlassian course, then you are well prepared. You might not feel it, but you are. The best cheat sheet you can have is your notes from doing the course.

This is something broken in whatever library or application you are using to talk to Jira with. You'll need to fix your code such that it makes a valid call. You've not told us what you're using, so we can't tell you much more than that.

Why are you trying to create sub-tasks on an Epic? They're not intended to have sub-tasks, they're there for grouping stories together.

No, it's hard coded. (The + is also the standard recommendation for replacing spaces in urls, so you shouldn't be trying to do this anyway)

Go to the sub-task and click "delete" on the options menu. If you do not have that option in the menu, then you do not have "delete issue" permission - you'll need to talk to your admins about that. However. Do not delete issues. Delete completely destroys them and there is no way to recover other than "restore a backup…

Jira Software's hierarchy is Epic -> Story -> Sub-task, there's no more layers in plain Jira. Advanced Roadmaps gives you layers above Epics, but there's no real way to do sub-tasks of sub-tasks in Atlassian software. The Structure app does allow you to add more layers as well, you might want to take a look at that.

Boards do not have archiving options, only projects and issues do. A board is not a container of issues, it is a view. Deleting a board has no effect on the underlying issue data, so there's no real need for an archive function.

Nope, spamcop is listing your email server, not an Atlassian one. You'll need to talk to spamcop about getting your email server off their spam list.

The two email addresses you have given and said you want to be different are the same, so I'm not sure what you actually want to change. It is not clear what the problem is here.

Yes, you can remove time-tracking from the screens, or hide it in the field configuration, that will remove it from the project.

There is not a simple answer to this. You need to make a balance between authoritarianism and freedom. You could dictate that everyone does things in the same way (this does not work). You could let everyone do whatever they want that works for them (this works, but only for getting the odd thing done, not getting the…

You need to go into the issue you want to convert and look to the options menu.

All apps are "for Jira API" When you create an app for an Atlassian application and add it to the marketplace, you have four things to target: * Server * Data Centre * Cloud * Something that runs elsewhere but talks to one or more of the above You can build for any number of those, but to muddle it a bit, Server and DC…

The current assignee can add a watcher if they have maintain watcher permission. They will be limited to selecting from the people who can see the issue.

There's an essay question on the largest paragraph in there on the vagaries of Jira UX design, and much as I'm well known as a fan-boy, you'd find my essay would have a lot of opinions not that different to yours. Possibly enough that you'd ask me to be one of the product owners. But I think the point of your question is…

Was this for Server (or DC), or Cloud?

Every site admin can see the installed (or subscribed) apps. What are you seeing under Admin -> manage apps?

This is not going to work the way you think it will. If you add a field to an issue, then anyone who can see the issue will be able to see the value of that field. There's no "one team can see this field" functionality. Permissions are project level (down to issue level if you use issue security) and that's it. So, for the…

I suspect your rights are that of a Jira administrator, who can see and manage apps, but not upload them. To upload, you need Jira System Administration rights

Custom fields all have a "context". This means "where I am valid on a project and/or issue type basis". For example, you might have "root cause" as a field. Never going to appear on any issue type other than "incident", so limit its context to incidents and you don't have to think about screens or field configs for hiding…

You are using "internal requirement" like it is an issue type. May we assume you have added an issue type with this name? If so, then you need to check the issue-type grouping - there are three levels in Jira Software; Epic (can only contain one issue type, which should be Epic), Standard and Sub-task. If your internal…

You'll need to get an admin to grant it - it's done by adding groups to it in Admin -> Global Permissions -> Bulk Edit permission. (A lot of us use the "can log in" group, so everyone has it, but not everyone does it, and the default is admins only IIRC)

So, to echo the "issues should not be deleted", yes, that is true, it is a nightmare to get them back, can destroy your audits and and and. If there is any chance you might need an issue, do not delete it (archive instead) If you can be 100% sure that the issues are total junk and you'll never need them or be questioned on…

You cannot restrict your admins, they need admin rights to be able to do their jobs. Space admins can of course, be limited to their space(s), but Confluence admins can't do their job if you remove their admin rights. Actually, you can, technically. Admin rights give you admin rights, not "can do everything". So if you…

Your paid apps are part of your subscription, not the data in a backup (although they may have some of their data in your backup, that will be restored whether the target system has subscribed or not). All you should need to do is, after restore, go to "manage apps" and re-enable them.

No, you do not need to worry about these potential compatibilities. Your versions of the various elements are close enough together that changing any one of them will not break the others and force an upgrade. The worst case is that you upgrade one element, and you find a shiny new feature in it cannot be used until one of…

Yes, that's the whole problem we're getting at - you can't search for information you have not put into the system. So we kept coming back to how you are capturing the route things arrived by. Labels is one way of adding the information, but yes, very manual. But now you're entering that data, the answer becomes very…

Ok, but where is your system actually running? If you have not changed the defaults, then it should be on the url in the docs, but a refusal suggests a network block (which could be a firewall on your machine or even a browser setting), or that there is a service listening on that port but not serving anything. I'd like to…