Nic Brough -Adaptavist- Expert

Ah, sorry, I missed that. It's actually a lot more simple then. Just drop the two domains that were not working (Confluence can only run properly on one), and rename the working one to wiki.company.com, and change the base url

As a troll got my last post removed (it was rather terse), a better way to put it might be: You will need to get command-line access to the Linux system you are running, and use the Linux installer to install the service. I should warn you that Jira is not a light program, and Chromebooks are not usually server-class…

I do not know - the filters you are using in the issuefunction calls are not visible to us. But the Team field, assuming you're using one of the standard ones from apps, all render as text in the filters, so I am pretty sure your filters can use names instead of numbers for the team field

This usually means that the Jira server can not reach itself over the network, and the usual underlying causes are either that the network cannot resolve the Jira server (or proxy if you have one in front of it) or there is a certificate problem when you're using SSL. Very simple test is to nip on to the apache server and…

The new screen is under Admin -> Issues -> Screens Yes, you have to do all those things, you're taking away one route to set/edit a field and adding a completely different route. There's a lot to do in there!

Sub-tasks are part of their parent issue, so where you've got repeated cycles of things in your process, you can break up the parent into bits and repeatedly use it. This is a slightly clunky example, as it's from before we really had Jira Software or Service Management and well before Insight, and they can help out in…

You cannot do this. Your Confluences are all separate systems, and hence have to have separate urls to run on. Your options are: * Run them on the same URL by migrating all the data you want to keep from them into a single Confluence * Run them as separate systems, but with sub-domains (this is a doddle with a proxy…

Sub-tasks. You can co-opt subtasks to repeat parts of the lifetime cycles.

There's no client ID in that image, but actually, you have a bigger problem. If you want your Cloud system to work with your Jenkins, it needs to be able to see it. Running it localhost can't work, you need to run it somewhere Jira Cloud can get to it. Once you've done that, you'll be able to fill in the App name with "My…

I have used "developers" to talk about people who are in groups that give them Jira Software or Jira Core access. Administration is irrelevant here, admin rights give you admin rights, not "can do everything". You will find that the one person who has "assignable user", is not just a "developer", they also are in a group…

It just sounds like you have not added "project" in as a column to the results display? Your new JQL will work fine with a very minor change to the syntax: ( project = "CocoNet project" AND status = submitted ) OR ( project = ChowDry AND status not in (rejected, solved))

Ok, then all you should need to do is change the team name. and team-name in ("The Maesters") becomes and team-name in ("The Maesters", "Other Team 1", "Other team 2", "Other team 3")

You can't manage a sprint with that filter because you are drawing in things that are not items you include in sprints, and you might not be using the right fields to manage them. Also, your braces may not be doing what you expect, but I am not sure of that, so I'd just suggest you review them and check (you don't need to…

Jira can only have one type of Epic. First, you should establish what issue type Jira sees as Epic at the moment and which one is the imported not-Epic. Go to Admin -> Issues -> Issue Types and look for both of your Epic types. Ideally, hover the cursor over the "Edit" link and look for the "id" in the tooltip of the url…

Ok, let's imagine you have: * A field called protected-stuff * A person called Bob who should be able to enter/edit it. Alice and Charlie can only see the field, not enter/edit * A workflow of To Do -> In Progress -> Done To get the field "protected", you can * Add a new screen,* call the new screen something clear like…

I think there is a deeper question in your mind, but I do not think you have explained it in full. The easy answer to your question is "Read the issue. When you fetch an issue over the REST API, you can include all its history, from which you can work out who was assigned and when". But I suspect you're asking more?

CSV imports create issues, so they can set the status.

I'm afraid you can't do that at the moment. If you removed the "old" sprint from the field, you'd destroy all the tracking and metrics you've got for the old sprint. Issues currently need to be able to keep multiple sprints in the sprint field.

This suggests that the original user removed themselves from the Admin group(s) for the application. They should still be able to add them (and/or your own account) back into it if they go to site admin and look at the user settings and groups. Default groups to look at, from memory, would be site-admins, administrators…

What do you mean by "for more than 1 team"? That query will work for everyone, irrespective of their teams at the moment.

Why? That is a very short and blunt question, but there's not a lot more we can ask. We do not know what you are doing, why you think you want a "project initiation form", what one is for your organisation and so on. If you could explain what you're trying to do and why it is a useful thing to do, we might be able to help…

If you know it's going to always be 4h, you can set it with an automation instead. If it's almost always going to be 4h, it might be acceptable to do that and then ask the people creating the issue to go back and change it on the small number of times when it's not going to be 4h

Service Desk has an additional layer of permissions to it. You can't just add "developers" (core or business users) to Service Desk projects and have them have full Agent rights. You can add them for making comments and being participants and watchers, but they can't be assigned issues, progress the workflow, edit stuff…

Without scriptrunner, you can do a bulk edit, if you temporarily add the resolution to the issue edit screens. But this will not allow you to blank our resolutions for the issues that are not done, it is only changing from one resolution to another. With Scriptrunner, have a look for the built-in/canned script "fix…

Ok, so you'll need to follow https://confluence.atlassian.com/cloud/api-tokens-938839638.html to get the key, then follow what https://plugins.jenkins.io/jira/ says for setting up the Jenkins connection (I'm guessing you're using that one to do it, there's others, but this is the one I run into the most often)

It most certainly does not. I think you may have misread the conversation above? As you've not countered what it was saying.

It's hard to explain differently to what I said before, but here is a worked example. You have three people, Alice, Bob and Charlie. You have a security scheme that says: * None (no security level set) * Secret * Very Secret The rules for the security levels are that * Alice is named for Very Secret and Secret, * Bob is…

Not directly. Fields are not protect-able themselves. You can move the "edit" into the workflow though, so that they users have to go through a transition to be able to edit a field, and that transition can be protected with conditions (like "only admins can do this transition")

The url for a system and credentials for Jira are two totally different things. Could you explain what you are trying to do?

Obviously, your browser still has downloaded them so it can display them, but they'e a little harder to get to than a "copy" style download.