Nic Brough -Adaptavist- Expert

The doc you've pointed to does mention that if you have external user management enabled and it is read-only, you can't use Confluence to maintain users (because it can't write to the directory). I would guess that is what the case is here.

You don't just rip out a core component of a piece of software and jam in an alternative like that. That is a bit like buying a petrol-powered Rolls Royce and saying "I'll just throw away the Rolls Royce engine and drop in a Tesla one". You've got quite a lot of work to do - start by downloading the source code of Jira,…

Your thought process makes complete sense, but would lead to a very very rambling series of possibly quite disjointed answers if I followed my training and answered point-by-point. It is not quite this simple, but most of us can think of two types of "Backing up Atlassian Cloud" * Atlassian back up all their Cloud systems,…

Actually, almost every Linux distribution that supports networking and a supported architecture will work. This comes down to "can the server run the required version of Java?". Note that is not "does it have it installed?", just "can it run it?" The Jira installers will install everything you need to run Jira - the…

Jira does not track users, it tracks issues. It records all changes people make to issues, and it records their last login data, but not a lot more about their activity. So, off-the-shelf, * Assuming "active" means "logged in", look at the list of users and their last log in times * You'll probably need to check the…

You don't "restrict" people from access to Jira, it is a lot easier to think of it as "allow" For a very simple case that you describe, I would * Create a new project role called something like "User access to project" * Create a single permission scheme, in which * You grant Browse Project to Role: User access to project…

Ok, then yes, you need to be a system administrator (broadly, the line between system and jira admin is that the system admin can do structural things that totally change how it all works)

Go to the support portal and look for "General request - Scriptrunner for Jira Cloud" at the bottom. Should be https://productsupport.adaptavist.com/servicedesk/customer/portals?q=scriptrunner and it won't ask for a version.

You can't do this directly. You will need to go through each permission scheme, adding the admin to "browse issue" permission. Once you've done that, try the filter for the 5 issues again. If you still have non-visible issues, then you will need to go through all the "issue security schemes" as well.

See your other account's identical post and response.

Site-admins tells me that you are on a Cloud, not Server/DC, Jira systems. You do not upload apps to Jira Cloud, you go through the app entry in the marketplace to get the one you want connected to Cloud (or "build your own" from the manage apps page).

No "server info" page usually means you are on Cloud. Cloud does not generally expose the Server ID as the end-user simply has no use for it. Why are you looking for the server id?

The only field that fits that off-the-shelf is a large text field, which literally would hold that as text. I suspect you want this as probably a table, with name/surname/date fields, for which you will need an app to provide such a field (Table Grid is the one I look at first) Jira doesn't have multiple-line custom fields…

You do not need the server id to make a "create issue" REST API call. I suspect you mean something else though, could you explain what you mean by "server id"? (Server ID in Jira means "a string related to the server that identifies it to use admins and Atlassian for the purposes of licencing and support", and isn't…

This will be a function of the end-point of the VPN. You have two normally isolated networks. You are using one of them, but want to use the other. A VPN allows you to "tunnel" into the other one. Once you are in the second network, your routes to other places are determined by that network. So my guess is that the network…

My guess is that in the second screen shot, you are looking at a project using a different Field Configuration Scheme.

According to your first screen shot, you already have

You can not. Jira's assignee field is supposed to represent the one person currently responsible for dealing with the issue. So it is a single-selection of one user. The reason for this is simple real-world experience - if you have two or more assignees on an issue, you can absolutely guarantee that the group will drop…

I would always recommend a backup before an OS upgrade. Not just for Atlassian applications.

The field configuration tells an issue how to behave for each field, but you tell a project which field configuration to use for each issue type with a field configuration scheme. If you look at the field configuration scheme for your project, that is where you will be able to set things like "defect = use default field…

You cannot do this. A portal is completely configured within the context of the project it is part of. If you want to use two projects, you need two portals.

You will need to talk to the application administrators. We are a public group here to talk all things Atlassian. Your admins may be here, but you cannot assume that, and you cannot expect them to be watching everything looking for stuff that might be for them. Ask your co-workers or the people who gave you access to your…

I would have said that if it did - that's not a minor thing.

It depends. If the upgrade affects the version of Java you are using, then it might. If you have installed Jira as a service, you may need to check that the upgrade does not remove the service unit or change it in a way that stops it working (the service is part of Windows, not Jira. You'll still be able to start Jira…

See https://confluence.atlassian.com/adminjiraserver/connecting-jira-applications-to-postgresql-938846851.html If you get stuck, let us know what you're doing differently to the doc.

Jira has a fixed list of fields available at a project level. You will either need to set up some form of extra field tracking, or get an app that adds project level fields (Profields is the only one I've used and it does a very good job)

The problem is that you've only got half a clause in your query: * Project in () - selects for projects * and * ("Field1") - and field1 what? * and * ("Field2") is empty - checks if field 2 is empty As you entered this into the JQL box, it would have told you that "and" was wrong after the end of that clause.

This is not possible, the assignee must be a single user (this is a good thing - having multiple assignees simply does not work in real life - your humans will miss things because they think someone else is responsible for it)

Yes, the description is true. You want the view permissions to cascade down in this way - if you don't you have no hope of anyone keeping anything remotely private as it becomes a complete free-for-all. I am less convinced by the edit cascading idea. I err on the side of "explicitly let people edit" as it seems more simple…

This would be down to a change of library, variables, or structure of the JS in Jira. This changes are going to happen in new versions, and your best option is to not inject unsupportable js in this way.