Nic Brough -Adaptavist- Expert

Welcome to the Atlassian Community! The only way to do this would be to allow your users to see the project, and then use "issue security" to hide the issues you do not want them to see.

I wouldn't bother with a script. There's a built-in condition for "only allow transition if all sub-tasks are in one (of a list of) status"

Welcome to the Atlassian Community! What do you mean by "MR"?

Welcome to the Atlassian Community! Confluence treats the file name as the unique identifier for it, so when you upload several files with the same name, it treats each one as a version of the same file. You will need to rename the files if you want to attach them as different files rather than versions.

Um, no, generally, in a correctly configured Jira, you can not use bulk change. The reason for this is that the resolution field is never placed on an "edit" screen for an issue (nor create) Bulk-edit will only offer you fields that are on the edit screen to amend.

Because fix versions are not release versions, as explained before.

Welcome to the Atlassian Community! How have you calculated this field, and how have you created it in Jira? ("What type of field is it?" is the main question) What chart are you trying to use it in?

Welcome to the Atlassian Community! Adding a version to the project will have no effect on your rights to do things, unless you have done something very odd with the permissions (which has nothing to do with Scriptrunner) Could you explain the symptoms of the problem properly? "unable to" tells us nothing useful about the…

Welcome to the Atlassian Community! What scripting function are you using?

Welcome to the Atlassian Community! As there is no "quiz", no, there cannot be a bug. I think we need more detail on what you think the words you are using mean?

Welcome to the Atlassian Community! This is not going to work the way you think you want it to. The best way to think of a search and result in Jira is that it is a two part thing - literally the search and a report on it. JQL finds issues, it has nothing to say about what you display from the issue list it returns. So…

There are a couple of things here that you need to look at. "Ticket" is a poor word to be using, because it does not tell us what you are actually talking about (plus there's the actual English meaning of the word that makes it a poor choice in an issue tracker). In a Service Management project, you have a customer portal.…

90 days is for a (free) trial with any number of users. Free unlimited time is for up to 10 users.

Ok, so that's a problem with the user part of your migration. It's not misunderstanding that "Author != Owner", you've had a migration go wrong.

Yep, it's a historical thing though - "edit field" refers to editing a field "header" - the thing that hooks it into Jira projects and issue types. Different types of fields have different configuration settings, including contexts, so they needed another name for them.

Jira does not have a many-level cascading select field built into it - you'll need to find an app to provide it!

Yes, AR can do that. It will not alter the fundamental Jira layers of Epic -> base level issue -> sub-task But you can rename Epics, and define other issue types to be at the Epic level. Then it lets you go up from there through whatever layers you need.

Um, that's the wrong end of the board, as I said, your Done status needs to be in the last column, not the first. Are the issues base-level issues (not sub-task types)? And are all their sub-tasks (if they have them) in the last column too?

Welcome to the Atlassian Community! Almost, it's Jira that does not have component events, not SR. SR can't respond to things that are not happening! There are a couple of component synchroniser apps on the marketplace, and I'd actually recommend looking at them, because they do a bit more than just a sync. To do it in SR,…

All you can do now is put logging into your scripts, so that you do get a log that tells you what your script is doing.

Neither! Jira Server/DC has "system administrators" as well as Jira admins and project admins. (Cloud has them too, but only Atlassians can be system admins). It's the same principle though - only a system admin can add a new member to the system admin group(s).

Adding a bit of an explanation to what the others have said - you can't "restrict a user" in Jira. Jira permissions are permissive, you grant the ability to do something. That's why the other answerers are asking you to look at how you have granted the user the right to create, not your "restriction" (because there aren't…

Welcome to the Atlassian Community! You need to ask your Jira admins and/or the project owners about this. The status name you've given us is definitely a custom one, and even if it were not, you would still need to ask them about the workflows they have set up and how to use it.

My guess would be your not-resolution field (please, at least rename it, to avoid confusing people) may be a multi-select field. Your payload is sending a single option, but the field expects an array (even when there's only one option to send)

I'm afraid it is not possible - Behaviours are injected into screens, and the browsers rendering them have no way to support this.

I would use a version of Scriptrunner with HAPI enabled: <span>lue</span><span>(</span><span>resultField</span><span>,</span><span> result</span><span>)</span><span>}</span><span>def</span><span> issueKey </span><span>=</span> <span>"YOUR_ISSUE_KEY"</span><span>def</span><span> firstNumberField </span><span>=</span>…

Attachments is not really a field, it's a function. When you attach files to a Jira issue, it is simply attached, there's no other place to put a file. Even if you could add files via two separate attachments field, you would find they both land in the same list of attachments. There's an app for Server/DC that allows you…

If you do both, the "none" will not be offered any more.

Jira doesn't do "create issue" as part of a workflow. You can create automations, listeners, and post functions to do it, but I'm not sure what you have done here, so I'm a bit stuck on what you have set up.

For those who want to release that way, yes, I do add field(s) for release versions. But those would still be based on the fix version, because a release version is not the same thing - a release version might contain many fix versions. As I explained before, you really don't want to mix up have many field names for data…