Nic Brough -Adaptavist- Expert

No. Cloud does not give you any access to its backend (plus, it's a terrible way to try to ask questions of a Jira data set even on Server) You will need to use the REST API. What CMDB are you using in Jira?

How are you making the fields read-only in plain Jira?

I'm afraid you have got as far as you can debugging it from the Jira side. Your mail server is rejecting the connection. You'll need to question the mail server to see why.

Ok, then it's either a slow network (I've worked in places where it's 10 times faster to work from home because the office network was bad), or the data you're drawing into the board is too large and complex to process quickly. Are other parts of the system slow ? Admin screens, issue navigator, reports outside boards etc?

I'm afraid dropping and recreating the table is unlikely to help you here. I suspect your database is damaged,as h2 is known to fail without warning. If you do want to try recreating it, then the definition is below Column Type Not Null Default Constraints id numeric(18,0) NOT NULL Primary Key job_id character varying(255)…

Because they do different things. Templates are static, used to create a page in a shape. The functions you're missing from templates are for doing the more dynamic things that you would do when editing a page. And vice-versa.

Yes, technically, but it's "as big as the number your identity provider system can cope with"

The user filters are a Cloud-only function (for now) You can do it manually, by creating a filter for each person, but it's a bit clunky.

Absolutely all of what @Joe Pitt said. Especially on change control - you really should do that, and a Jira project is a brilliant way to do it. On the specifics of deleting an issue type, yes, you can "just" delete it. BUT, do not. There are impacts you need to think about. First, the good things you should know: * Jira…

Point releases are usually bug fixes, tweaks, and corrections like spelling mistakes. Since Jira 4, they very very rarely make changes that have any significant impact on your end users. Best thing to do is read the release notes for Jira Software Server 8.5.4 and 8.5.5 - they list all the changes going in. I usually find…

I would strongly recommend that you do not bother reading the database. Issue (story) data is smeared across 18 tables, and that's for an issue that has no custom fields, and is just an issue (no service desk request, and not being used in a Software project). This increases exponentially as you add fields or other…

The information on the marketplace is worth reading, it covers all of those questions. See https://marketplace.atlassian.com/apps/1211111/elements-copy-sync-formerly-exocet?hosting=datacenter&tab=overview - the pricing and support tabs especially.

It's still "trivial" - remember something like this does no harm beyond minor confusion possibly, and slowing down speed-readers. I can't see how it will have much impact. Critical/bajor/minor/trivial are comparative measures. For a comparison - a major bug is something that damages data or prevents people from working.…

It's recovered.

Hang fire - the community is suffering a problem with a load of answers going missing, and this looks like one of the affected questions. (It's solved because it has an answer which has been marked right. But we can't see them, or they've been deleted). Atlassian are aware and are working on it.

What do you mean by "enterprise Jira"? Enterprise licencing, the old Enterprise versions, the long-term-support releases, or something else?

Yes, a field can't actually hold data without it having a context, so you can't lose anything by deleting a context-less field. And, yes, your assumption is correct. There are other ways to get there (deleting contexts, scripts, apps etc), but almost all context-less fields I've seen are as a result of project deletion

I'm afraid there's no easy fix for this. There is a dirty trick you can play on Unix-like systems though - create a symbolic link at the old absolute path.

Yes, any text value in resolution (even "unresolved") counts as done. The field in the database is null when an issue is unresolved.

Note the "resolution" field says "unresolved" here. That's why your issues are coming out in searches - plain Jira believes them to be open. This happens when you have a workflow that fails to ask for a (or set to a fixed) resolution as you move the issue into an end state ("won't fix" in your case). First, I would go over…

This sounds like you may by using a numeric field for estimating the sprint, and have given that field a context for sub-tasks. Sprint estimates should not be put on sub-tasks, so I'd recommend changing the field context from "global" to "only for standard types"

Have you followed it through all three layers? Issue type screen scheme, screen scheme and screen?

resolution is empty and assignee in (Alice, Bob, Charlie)

That sounds like you have a slow connection. Are you a long way from your Cloud service (for example your company is mainly based in Western Europe, but you're in North America)

I think you are asking this in the wrong place. I suspect your kbase thing is based on an Atlassian system (or documented in one) and you have clicked "help with atlassian system" instead of "help with kbase". You'll probably need to ask this in a kbase place, I have no idea if there might be a forum for that, or you'll…

I think you are asking this in the wrong place. I suspect your kbase thing is based on an Atlassian system (or documented in one) and you have clicked "help with atlassian system" instead of "help with kbase". You'll probably need to ask this in a kbase place, I have no idea if there might be a forum for that, or you'll…

Quick filters are for narrowing down the list shown on the board, not controlling swimlane usage. You could do something like it by using a quickfilter that is the exact opposite of a swimlane definition, so that when you enable the quickfilter, the board hides all the issues in the swimlane. This wouldn't expand/contract…

They did not.

Three main causes: * You're using Jira Cloud, not server. Cloud doesn't have priority schemes * Your Server version is too old. From memory, they arrived in Jira 7.6 (definitely somewhere between 7.5 and 7.9) * Someone upgraded your Jira from 6.something to Jira 7.1 or above in the past, without going through 7.0

User labels will not solve that problem. Why not use a custom field for "attendees"?