Nic Brough -Adaptavist- Expert

I don't think there's a way to do this on Cloud at the moment, I can't find an app that can do it. There are a couple which can read attributes from a directory but they don't provide custom picker fields. That suggests that it should be possible to write an app to do it. A second option might be to have an external script…

Ok, at a project admin level, yes, there is a limited function for this. It's actually a team-lead / scrum-master level, rather than project admin, as it's done via Agile boards rather than project, but your Jira admins can enable it. * First, find a suitable board - a lot of boards have a 1:1 relationship with a project,…

What do you mean by "clients"? You wouldn't want customers or developers altering workflows, only scrum masters, team leads and admins. "clients" implies "customers".

Then yes, each of the "duplicate" status are not duplicates - they're different things with the same display name.

Welcome to the Atlassian Community! Admin rights mean people can administrate your system. They do not mean "can do anything". You need to look at the rule for who can be assigned issues in that project. Check the permission scheme and/or role settings.

A board represents a team's pile of issues that need attention. I say that because it explains why "done" is relative. In Scrum, the principle is simple - every item is something that needs attention, and "done" means "this team does not need to pay any more attention to it". (Kanban is a little more complex, with the…

Welcome to the Community! The rather brusque answer to this is that you should never share keys between accounts. It's fine to share an account's public key, that's what it is for, but you should never use the same key pair for two accounts. What you should do here is generate a new key pair for one of the accounts. You'll…

I am not sure it's what Juul has run into, but I can replicate it! It also works correctly if you create a global field called project (for CMPs). The JQL seems to be picking the first "project" field it finds in the order: * Project in a TMP * Actual Project * Project as a CMP custom field I still say it's a howling bug…

The fields that appear in that column are partly hard-coded. The "view screen" does make a bit of a difference lower down in the column, but the column is coded to show you the most important parts of an issue - summary, description, links and so-on. So, no, you can't remove the fields that are are there, because showing…

Welcome to the Community! Workflow steps are not assigned to people, and the workflow does not (by default) do anything with the assignee. So I am a little lost on what you mean by "default person a workflow step is assigned to" I think you may have inherited a workflow that has been modified - it has had post-functions,…

It may be more complex than permissions, but there's a quick test - from the issues that you can see, pick one that your other user should be able to see in the gadget and get them to look at it in the issue view. If they can see it, then it's not permissions or security. But your last screenshot answers it. The gadget is…

Welcome to the Atlassian Community! You can't have public links while anonymous access is enabled (and I seem to remember public links can't be enabled at the moment if you didn't enable them a while ago). Which one do you want to use?

You've gone over most of the permissions in detail there, but there's one missing - can these users actually see any of the issues they should be seeing in the gadget? (I know you've said "in the project", but that doesn't necessarily mean they can see the issues)

There are no REST APIs for doing that yet, so I'm afraid the answer is "no" - you will have to do it manually.

Issues do not "migrate" or "move" between boards. Boards (and their backlogs) are a view of a selection of issues, they are not containers for issues. All you need to do is set up your "Tribe" board so that it selects all the issues you want to see on it.

I suspect your field configuration applies to all the issue types in the project. A field's presence on a screen has nothing to do with whether it is mandatory. I think that because you didn't mention the field configuration scheme in here to say you had set up different field configurations for different issue types.

You don't - the issue was in a sprint, Jira is telling you that it was.

Team managed projects don't have the functionality to display that on the cards in their project boards - you can't customise the card view enough (yet) You could do this by using a different board. I can explain that if you want, but I don't want to write an essay if I have misunderstood the problem. I think what you are…

Welcome to the Atlassian Community! Yes, Jira exposes a REST API to which you can make calls to create, update, transition or view issues. Many monitoring tools already have functions to do this built in.

Your "status = XX" can be worked out by looking at what status are mapped into the last column on the board, and will come out as something like "Status in (Done, Complete, Closed)"

Welcome to the community! You need to tell the pages that they have attachments. Attachments are not just files, Confluence needs metadata like the filename, author, upload date, etc, so that it can version and report on them. You will need to work out what each file was, and re-attach it via the UI.

Welcome to the Atlassian Community! There's no real way to do this. The built-in exports are capped at 1,000 issues (and only contain issues, not the project, config, user, etc, data) simply because exports load the system and it can become unusable by the other users. So we could start talking about taking an XML backup…

Welcome to the Atlassian Community! This forum is based on Khoros ( an older name was called "Lithium"), but the previous version of it was based on Atlassian's own Questions for Confluence . There are several apps for doing forums in Confluence - see https://marketplace.atlassian.com/search?product=confluence&query=forum

Welcome to the Atlassian Community! Very broadly speaking, yes. Most DC-compatible apps I know of are the same as, or forks of, their older server-based incarnations. Simple core functionality in server and DC is pretty much the same, so apps that don't have complex needs will simply work. The most obvious ones are reports…

No, because there's no permission to work with.

Are you named in at least one of the security levels (doesn't matter how - group, role, assignee, individual, etc)? The field won't appear if the only option available for you to set is "none" (you have to be included in a level to be able to set it)

The main bit of code you need is simply issue.getParentObject().getKey() For writing it away, there's a good guide to setting most types of field at https://library.adaptavist.com/entity/update-the-value-of-custom-fields-through-the-script-console

Ah, sorry, you can't restrict the issue links like this, there is no "link issue" permission to do it.

When you create a request, the type is mapped to an issue type, so the customer is effectively selecting the issue type by their choice of request type. As a customer commits their request, Jira extracts all the mapped fields for creating the issue with, and then creates it, with the issue type given in the request type…

Welcome to the Atlassian Community! This doesn't work because you should not be moving requests from one project to another. To many of your customers, this would look like you have deleted their request because they can't see it in the other portal. Two options for handling it though, quite easy with a bit of config: *…