Nic Brough -Adaptavist- Expert

You can't just change the issue type. You need to go through the whole "move" process, unless the target issue type is configured to use the same fields and workflow.

You can't do this. You could, sort of - if you do not grant the administrator account permissions in the projects, they'll be able to admin the projects and not see your data. But that would stop them from testing or checking their admin work, and it's a doddle for an admin to grant themselves access to the data.

Could you re-read the page I've linked to? It tells you all about reselling Atlassian products. There is no "API for account creation", that's not how reselling works.

Not in Cloud I'm afraid. You'd need a read-only field (and the built-in read-only fields don't display on transition screens even if you could set them to something useful)

Could you show us the sub-task display area of the issue with 8 tasks in it, and the full JQL of the query that is only returning 7?

Ah, ok, then it's just a case of adding them to the right Jira if there's two, or making sure they're in the right groups if you're using a single instance

It absolutely is an issue. I think you have missed the point. If you sort by priority, you don't actually have an order (unless you are in the edge case where every issue has a unique value from the priority list). Please tell me what order these three issues are in, given the data * Priority = high * Priority = high *…

I can't think of an Atlassian application that would do anything like a mail-merge off-the-shelf. I guess you could script something that could do it though (for example, having a confluence page for each address you want to mail, held in a space, and then a letter in another space that has a button for a script that could…

1, 2 and 3, see https://www.atlassian.com/licensing/resellers 4 - Asana is not an Atlassian product. You'll want to talk to Asana about it.

Go to "manage apps" in admin and search for the app that provides the validator you want to use, and install it. Then go to your workflow and edit it, clicking on the "create" transition arrow. It will pop up a box with transition properties, including a tab for validators. Go to that tab, click "add" and select the…

So this is not about adding javascript to Jira, it is about using javascript to use Jira's REST API. (Please correct me if I have misunderstood!) The curl command you have given is an example of a post to send to Jira's REST API to ask it do do something. You will need to translate that into a Javascript post message to…

There is no impersonation function.

I gave an answer to this a few minutes ago - see https://community.atlassian.com/t5/Jira-questions/How-to-secure-custom-field-is-any-JIRA-version-can-support-this/qaq-p/1372890

What do you mean by "add javascript code"? What are you trying to achieve?

No. Jira can't know where to add a step to a workflow or what transitions you might need for it. There's no bulk-edit because you generally don't want people messing with workflows en-masse.

Start by analysing what is taking so long Use the developer tools to break down what elements of the page are slow. Look at what action is slow - issue view? Edit? Transition? Page load for view? Search? Dashboards? Click to Edit? Everything? Do you notice if it is slow for most users but faster for admins? Are the…

Yes, you can set up logrotate for the export directory. It contains all the regular backups to xml Jira makes, plus any you trigger manually, so any file in there that is not actively being written to is just a backup snapshot, and if you don't need older backups, you can clear them out. However, for any Jira of any…

Jira does not have "field level security". You can protect the editing of fields, by removing them from the "edit" screen and allowing edit in transitions (which you can put conditions on), but that's the only option for plain Jira. If you have ScriptRunner for Jira Server/DC, you can do some protection with Behaviours.…

Conditions are evaluated at the point where an issue is displayed. There is no "groups updating on the workflow". Could you show us the conditions you have on the example transition?

You can't make these downgrades on Cloud.

I'm afraid there's no sort order in the gadget - it just works off the ID in the database, which means most of the labels are in a simple "created first to created last" order.

You could just give those three projects a read-only permission scheme, no need to move anything around. If you remove JSD, the fields it used remain in the data, in case you decide to go back. But you won't be able to get to them.

Jira users will be customers automatically, but not Service Desk Agents. Customers are not added to roles.

I think you're missing the difference between a service desk and an issue tracker here. Consider the usual service desk use-cases - imagine you're a banking client or a software end-user who has bought software - that's a very different use-case to "items-needing-work issue tracker"

Could you show us all the conditions you have set for one of the mis-behaving transitions, and then the roles, groups etc for one of the people who don't appear to be experiencing the right block/allow?

To select a security level, you have to have "set issue security" permission, and also match the rule for the option you want to set. Imagine a security scheme of: * None - everyone who can see the project can see this issue * Secret - people in role of "spy" * Top Secret - people in the group "MI6" If I'm a "spy", I can…

What are the column setups and board filters for each board?

That tells us that the project has no issues of the selected type that are linked to the selected Epic (that the current user can see) If that's not the case, we'll need to see an example of the issue view showing us the three fields listed, from the current user's view alongside the "nothing populated" with the JQL

Do not do this if your Jira is not locked away behind your company firewalls. You will be attacked and you will lose your Jira if you allow anonymous write access on the internet.

On the actions menu, use "move issue", unless you have the option to directly click on the issue type "field" and change it on view.