Nic Brough -Adaptavist- Expert

All the locked fields named "Epic <something>" except Epic Link are for the Epic issue type only - they will not function or display on any other issue type.

None of them. It's in the logic. This is one of many reasons you should not be reading the database - it is hard to read and does not have everything you woud guess might be in it. Could I ask what problem you are trying to solve that makes you think SQL is an answer?

Where was the old system looking for your user accounts? Has the new one been set up the same?

I do not think this is a very clear message in some ways, but it does tell you what is going on. Your Jira has and old expired licence that ended on the 24th March 2015. Jira 6.2.4 was released before then, so you were entitled to upgrade to it, but 7.1 was released after it so you can not use it. You say you have a valid…

These are not logged by Jira at present.

Attachments are not stored in the database, and there is nothing you can do to reduce the size of a database without very very careful deletion of data before you take the dump. Put one thing out of place and you could render the database unusable and unrecoverable. So I strongly recommend forgetting that idea. On the file…

That's great, thank you for clearing up where I was lost. I think there is a third option - edit the workflow and have a transition from Cancelled to Cancelled, and include the resolution on the transition screen. This will let you change the resolution without amending anything else or messing up your numbers if you are…

I would recommend approaching Atlassian partners for this sort of work. Obviously, I work for one, so there's a bit of self-promotion inherent in saying that. But I know several of the consultants I work with (including myself) have done work with legal firms in the past, and that applies to other partners as well. Have a…

The query behind the "assigned to me" gadget can be thought of as "all unresolved issues that the current person is assigned". You have set the resolution on some issues, so they will not appear in the assigned to me lists. They are resolved, so they are deselected. "open" and "in progress" are not good resolution names.…

A status is really not much more than a label - something to display to a human when an issue is on step X of a workflow. In the database, they're not much more than a key (id) and the display name (plus translations) Yes, you can now have many status with the same name. This allows different worklows to be independent of…

There are 0 validators showing because you've removed the function that provides the validator, but the config for it still is. You might find it easier to get to if you swap to text mode. Or, if you (temporarily) put Zephyr back in, you should be able to get to it again.

Reading an email was a simplification, but it proves the point that "undo" is not appropriate for some actions. As you can't undo my reading, you make a right mess if you undo what triggered it. When you change the status (and that's the only time you should change a resolution) is not just "clearing a property". You are…

Log in as a Jira admin, and go to Admin -> Issues -> Priorities This controls all the available options for priority. They will need to delete priorities from the list, swapping existing issues over to using the new list. This will affect all of your projects, so it is not something that should be done lightly. Your…

Mmm, not for a lot of processes it's not. If your humans are making that mistake a lot, then there's something wrong with the process or their training. Even if they're not, there should be a route to correcting it, but for a lot of processes, that should be a pain, in order to help them learn to stop making mistakes with…

Yes, that's what an API does. The analogy I was given years ago was two humans talking to each other on the 'phone * We use mostly ears to hear each other when we converse. * We need to have enough of a common language to communicate well * The API docs give you the language the computer understands, and you could say you…

What are you expecting to get from "downloading the API"?

What do you mean by "most compatible"? In almost all cases, the best (most functional and least buggy) version of an app is the latest one the marketplace says is valid for your version of Jira.

The REST APIs are what you use to get other systems to talk to Jira. For the Service Desk specific REST API see https://docs.atlassian.com/jira-servicedesk/REST/3.6.2/ (You can still use all the calls for plain Jira Core too, as Service Desk is an application that runs on top of Core)

The security level is nothing to do with edit permission. You have not set up the security in the way I've listed. Try the absolutely most simple case, from scratch: * Create an issue security scheme* Add one single level to it * In that level, give it the single rule: Group A * Now go back to the project and* Check that…

> they want Service Team B to 'Only' view/edit their teams tickets That's what I described already No, you don't need two security levels, as I said before, only one is needed. You only need one that says "only group A can see this". You need to apply that level to all the issues that you do not want B to see. For the…

You can't do this. If A or B wanted to see page C, then all they'd have to do is log out. So there isn't actually a way to set this up (as it would be pointless)

Yep, should be.

Yes, you can do this, it makes sense. But I don't know how to help you place a file on your own DNS system - it's a system you own, not Atlassian, let alone myself, and I'm not that familiar with DNS server setup. The other option is similar - a text file at the root of a domain you own. That I could walk you through if I…

Technically, no, it's actually the opposite. Resolution is an optional field. In Jira the difference between mandatory and optional is that an optional field can be left blank, but a mandatory field must have content, from the point of issue creation and throughout its lifecyle. But, as you know, the resolution is empty at…

I'm afraid I'm not support, just another member of a community that works with Atlassian stuff. I don't have access to any support calls you may have open with Atlassian either.

Actually, no, you want a level set up for group A, not B. Security levels work by granting access to only the people named in the level. For your situation, where A can edit anything and B only one issue type, you should do something like Create a security scheme with one level, say "secret". You then name Group A in the…

It should be controlled by the permission that you have already set - "manage watchers". I would want to check some stuff: What is the symptom of "cannot add watcher"? Is the link to the area not shown on the issue? Or does it let you in, but have no "add" button? Or does it let you get into the field, but offers no users?…

The advanced query below should tell you the basics: created < -4h The "created" field is the date/time the issue was created, and the -4h is worked out as " now, minus 4 hours". If you're going to work with relative times more, be aware of that calculation, as it is purely relative to "now", it does not take account of…

You should go to the internal directory and make sure there is an account you can log into that has full system admin rights. If you log in with that user instead of your account from LDAP, you will find it can now edit the LDAP connection - this happens because Confluence does not let you edit the settings for the…

The page structure is a folder-like structure already, and it happens partly automatically. Your example data does not seem to be in any structure, so I can't really work with it, but let's say you want to end up with: Home Page (main page for the space) + Page 1 ++ Page 46 under page 1 + Page 3Top Page for some associated…