Nic Brough -Adaptavist- Expert

The sub-task does not hold any sprint value, it can't. The problem here remains that you are completing issues when they're not complete.

It's the same answer

Confluence doesn't have "folders", it's made up of spaces and pages within them. I'm going to guess you mean a page. Could you explain exactly what you are trying to share, how, and give us the full text of the error message? But before that, please check that the intended co-worker has an account with the permissions to…

User profiles do not have custom fields (unless you've got an app that adds them). Could you explain what fields you have, what you're trying to get rid of, and why? (I ask "why" just as a prelude to "is there a reason you can't just ignore them?", not anything big)

No, that would be a breach of your licence agreement and that of the person signing up for it. You should be using a developer licence for this, not a trial.

No, the field configurations don't actually contain any fields, they're an array of settings for every field that exists in your system, irrespective of usage. You can't remove something that isn't there in the first place! The only place custom fields actually exist is in, well, the list of custom fields. Check in there…

Just to be clear - the problem here is not Jira. "Broadcast message from root user: The system is going to power off now" is a message sent to all active users from the user who is shutting down or restarting the system. It's nothing to do with Jira, one of your *nix system admins is deliberately stopping/restarting the…

For the last part of the question, no Sourcetree is not being phased out or dropped at the moment. There is no "support" for Sourcetree directly, but new features, bugs and so on can be recorded and tracked over at https://jira.atlassian.com/browse/SRCTREE or https://jira.atlassian.com/browse/SRCTREEWIN

What exactly do you want from this code example? "map fields" does not tell us what you're asking the code to actually do. Maybe if you were to explain what you're trying to achieve, we could help you better.

You can "disuser" accounts with a flag in the user's profile in site management, or just remove them from the group(s) that let them use the application (if, for example, a user has access to Jira because they are in the group "Jira-software-users", then removing them from the group removes their access, and reduces the…

Just to be clear, Scriptrunner is an Adaptavist product (since 2014 where we acquired it from Jamie by getting him to join us), and is not going anywhere. The server versions will be dropped as Atlassian stops supporting Server products, but the Cloud and DC versions will continue as long as Atlassian still does Cloud and…

Ah,ok, that makes a lot of sense - you'd got issues that were flagged as complete while not being complete because parts of them (sub-tasks) were not. Getting rid of the sub-tasks fixed it, but it's probably not the right thing to do - the best thing to do here would be stopping people flagging issues as complete when…

Changing plans does not affect your data at all. It only affects who can use it.

Is every issue and all their sub-tasks in the last column of the board when you close the sprint?

That's very odd - could you try a quick test? Go to search, pick advanced, and start typing the query? Does "linkedissue" become automatically suggested?

Remember that your Jira admins will always be able to give themselves access to a "secured" project. You are going to have to trust your admins on this, no matter what.

Sort of, but the real fix would be to fix whatever it was that corrupted your index!

Don't need to yet this year, this "summer" in the UK seems somewhat more chilled than usual. But if it does get hot, we've got fans, a 'fridge with an ice tray (and ice packs for a nice little cooling fan which is enough to take the edge off on all but the hottest of days), I often drink more (tea, seems to make me feel…

The issue history records all changes to issue data. You can use the "was" and "changed" to search for priority changes, but the date is not stored as a field, so it's hard to report on.

You said the issue was in "issue solved". Is it in Done or Issue solved now?

Yep, that explains it. MDC-76 is not a child of MDC-27, it has a link (which your admins have mis-lead you slightly by describing it as "is parent of" and "is child of" - they are not parent/child at all) Anyway, you should be able to get the issues that are linked to it with linkedissue(MDC-27, "is parent of"). (Or…

What do you mean by "fusion" and what has it got to do with Jira?

Quick question to rule something out - you've said you are on a Cloud system - is that true? (Easy way to tell - your Jira is available under <something>.atlassian.net)

I don't think there's anything wrong with your database The issue status is "issue solved", so it is not "done" (because "issue solved" is not in the last column, it's not done) and hence won't contribute towards the done count.

That suggests that the project and issue type are not using this field configuration scheme

Check for "services" in general for where most apps might automate this from (Scriptrunner for example, will show in there), and then go through your Automations.

Is "issue solved" in the last column of the board the sprint was created for?

You'll need to look at the connector that is sending something over to Service Now - if it is event triggered, it needs to be coded to understand that changes coming from Service Now should not be played back.

The REST API is behaving as it should - an event is fired when an issue is being changed. There's no way to stop this, because you shouldn't - the events are needed as part of the process of changing issues.

Sprints are not "in projects". A sprint contains issues that could be from anywhere that the board filter limits them to. If a sprint could include issues from a project, then boards and issue views that show sprints will show the sprint as being related to the project, because it might be.