Nic Brough -Adaptavist- Expert

What do you mean by "alternate for api"? And how would you expect it to not use the identifier for a field when the id is the thing that identifies a field?

How would that work? Given that the id of a custom field is the unique identifier in the database (and the name a human proxy which could be duplicated, but usually won't be) What else would you use to map a custom field?

Yes, please check what documentation you are reading - there's no point reading docs for Server when you are using Cloud.

You are using Jira Cloud. These do not have a server id, which is not a problem because you don't need it. You do not get licences for Cloud systems, you buy a subscription to a service. So, this takes us back to the question of what you are trying to do. Are you trying to renew your subscription?

Same for Server/DC - the built-in clone function is intended to, well, clone an issue. Clones are supposed to be as close to identical to their source as possible. That's what "clone" means.

So... Many... Things... I watched a lot, it's hard to choose, but the one that got to the top of list (barely) was Malcolm Gladwell's talk.

I think the subjective and objective thing is a very good way to talk about this. The thing for me though is that when you're trying to work with other people, "subjective" is a problem, and "objective" is a solution. If I see something subjectively, there's a frame within which I see it. It's my view, I could be missing…

Actually, no. The software for Server and DC has been identical for quite a while now. For a very long time (early 7.x), you have been able to swap a system between Server and DC (a single node) by giving it a new licence and messing with some config files. Since 8.9-ish, Atlassian have got that down to "change licence"…

Yes, sorry about that, I forget it's limited now. I spend most of my time on systems that already had it before the licencing changes, DC (where it's part of the package now) or Cloud, where you get it if you are a premium subscriber.

"return null" on the first line is the easiest way to "disable" a scripted field. But I think there is a deeper question here. Why are you trying to "disable" a scripted field? What do you get from "disable" that is better than "delete"?

I agree - the problem is not the version of Python (nor is it in the Jira API), the problem is in the code, and your patch corrects it.

I totally agree with you on that, it's completely obscure that "change issue type is structural, so you have to move". I don't see it as obscure, but <mumble> years, very little is obscure to me. But I can still see it's obscure to people with <mumble - x> years. My (like you say, I'm not a UX person, probably way behind…

I'm the 👻 . But "Caspar" rather than "Abigail Crain". I often get to a page, want to comment and find someone has said what I want to, but better. I rarely write new things, but I do add to, or update other people's stuff, again because someone has done better than I can as a starter and it could use, well, an update or…

Team-managed/Next-gen projects are a Cloud only construct and are not going to make it to Server/DC. They're partly based on a different architecture that DC probably won't ever support. I can't rule it out, I'm not an Atlassian, but I can't see them going to DC.

It has been a while since I wrote an app that does that sort of thing, but it really is something to do with where your app is asking Jira to display its data. No way to know without looking through the code though.

So, screens are not locked to any particular purpose. They're a resource that can be reused in any place you want. They really are just "a list of fields to present to a human" and can be used by anything that needs to be able to offer a human a set of fields. So, yes, you can use the same screen for edit and a transition,…

Oh, excellent! I didn't think Deviniti would have forgotten it!

Yes, I think so. Looks a little odd to me though, Deviniti don't usually miss this sort of thing in their apps. I would also check that you're on the latest version of Bundled Field for your server. (Plus, it might not be an oversight in their code, it could be a limitation of what an app can do in server, I've not written…

See https://docs.atlassian.com/software/jira/docs/api/REST/8.13.6/ and look for the calls to api/2/projectCategory (for working with the categories) and then api/2/project and expand the "update project" call to see how to set a category on a project

There is no way to "lock" an issue for edit, other than the one method I suspect you've already found (use the workflow as an edit tool, such that when the issue is in an "edit" status, it can only be edited by the person who put it into that state)

There's no bug here, the message is clear that it's the permissions of the user trying to do something. There are two ways this particular error could get thrown: * The user performing the action is not currently an active user in the application the issue is aimed at (by application, I mean that if the project is a…

Your app is injecting its display in the wrong place. You'll need to look at how the app is doing the display of your tables.

I think you have an app that provides a custom field type, one that stores its data in the format you are seeing in your email, but when you see it on-screen comes out very differently (from the data, I'd guess it's a list of users in some form of grouping, or possibly some keys to things in a table format). The problem…

You'll need an app to do that. Advanced Roadmaps can add layers above Epic, themes and initiatives. Jira Align goes further, allowing you to go right the way up to the very top layer of scaled agile frameworks. 3rd party apps like Big Picture can also help with higher layers. If, however, you want to mess within…

Ah, I see, you are mistaking "restriction" for "permission". (This is understandable, I do not think the wording on screen is clear about what restrictions do) A restriction restricts a page. It does not grant permission to it. At the base level, a page's permission comes from the space. If a person has "use space"…

One of the things Jira does deliberately is have a single person who is currently responsible for an issue, avoiding all the problems that multiple assignees always cause. Nothing wrong with having "and other people to talk to about it" information though, and your group-picker is a good way to do it. Anyway, yes: >Can the…

Correct. The licence for an app needs to match the numbers for the application. There is a complexity for Jira applications because you can do things like 100 Core users + 50 Software users + 5 Service Desk Agents which would effectively licence you for up to 155 users. The apps look at the largest of the three, not the…

No, they're not going against the manifesto. They're supporting Scrum. Components or parts of sprint items are not sprint items in their own right, that's nonsense in Scrum. It's not a case of "enforcing" anything, it's a case of "this is a Scrum tool, and this is how Scrum works" I think there is a failure here in Jira's…

Not with a plain web service install, no. The whole point of the url is that it lands you on the server upon which the service is listening to the world. Change the server's url, you need to change the url you access the service on. When people are changing servers, what they usually do is replace, not change. Let's say…

You might want to use functions instead of hardcoded lists of issuetypes. For example, your query would probably be issuetype != Task and issuetype not in subtaskIssueTypes()