Nic Brough -Adaptavist- Expert

I think I may be misunderstanding what you're saying, for which I apologise. My understanding is that you want to tell Jira what IDs you want it to use to uniquely label its internal objects. Is that wrong?

I would have changed the port of one of the Tomcats. Look for "server.xml" in the "conf" directory and find the line that says 8080 and edit it. That said, you say you deleted your old Tomcat. Did you stop it and uninstall as per instructions, or just delete the files? When you're starting up Jira, that should throw errors…

Ok, thank you for clarifying, that helps a lot. Let me restate the problem as I see it now: You have three Service Desk Request types (Varese, London and Manno). People are using all three of these Request types. The issues behind the requests are all of issue type "Service Request". Some of the request/issues that are…

A linked issue is a pointer to another issue, related to the current one for some reason. Links are directional, but only made up of four real data points - source issue, link type, link direction and target issue. "A is blocked by B" for example, can also be written as something like "B is a blocker for A" I suspect…

I'm afraid there's no way to structure or categorise filters (yet)

Burndown is trying to measure delivery against commitment. You commit to do a set of stories at the beginning of the sprint, and you burn down the points on a story when it is complete. Sub-tasks are irrelevant here. A story is only done when all its sub-tasks are complete, doesn't matter if there's 0% of them done, 1%,…

That would require the person using it to go to Jira's portal to create the issue, there's no point in having your form at this point, just link them to the portal create screen direct and let them fill it in there. If you want to keep them in your application or site, then do the call in the background, when they fill in…

So many to choose from, but it has to be (by a gnat's whisker) Sam and Max hit the road. - I'm a lagomorph, not a malefactor! The others that almost got it were LeChuck's Revenge (That was the first point and click that worked for me - exactly the right level of difficulty and humour) and Day of the Tentacle (which would…

These don't have multiple workflows yet, so you can't add status for different issue types.

The answer is still the same. Do not do this in the database without stopping Jira, taking a complete full backup, and restoring that to a test system to prove it was valid.

Resolution is not a field you usually give to the customers to set. Repeating your initial question does not change the answer - there are no different portals for different people, there is the portal for everyone, and Jira internal screens for Agents to work with the underlying issue.

No, people need to be able to use numeric fields for estimation.

Yes, mandatory fields are mandatory throughout, not by screen.

We need to be very clear about this: Their membership of the distribution list gives your people no access to Jira. They get access to the issues only because they have Agent access.

Confluence does not have file folders, so you can't import like this. What are you trying to achieve in Confluence here?

An item should only be resolved when it is done. Otherwise you are lying to your people. If it is done, it should be at the end of the current sprint and because it's done, it won't go into another one. In the case you mention, the issue should have been added to the sprint in which the developer finished it when they…

Is this a "Classic" or "Next Gen" project?

Ah, I see. I would go one step further than yes/no, and give your people even more information. Try setting up a scripted field that * Has a "number" or "number range" searcher * Has a "number" template as the scripted field output * Has a script that says simply the below: return issue.getAttachments().size() This will…

It hasn't "improved" because there's not a lot to improve. As before, if you're doing it this way, you've probably got the wrong project structure.

>the product has missed the mark from the usability perspective Actually, I'd argue the opposite. Deleting issues is a bad thing to do. Making it hard to do, and forcing people to understand it, improves the usability a lot!

There are no "improvements" to make here. Atlassian do not default to allowing delete because of the nature of the deletes (see the rest of the discussions on that). You need to grant that one permission that does not do anything else for that one purpose, when you are sure the person getting it understands the…

Because someone has added the story points to the sub-tasks. They're not there by default.

Ah, ok, it's the "Epic / Story A1, A2 / Tasks A1, A2" bit that confused me. You simply don't get that display at all - the breadcrumbs you have pointed to are Project: Current project / Current issue - no multiples, not Epics. You can't change that display. But, it does support Epics - an issue with an Epic shows Project:…

Because someone has added the story points to the sub-tasks. They're not there by default.

My first bet would be that a marketplace App has been installed and configured to insert that menu item. It's probably a dedicated App, but it might also be one of the Scripting Apps which enables the use of "web fragments" (menus, buttons, panels etc that can be injected into some places) Third bet would be on a custom…

In the future, Enterprise Cloud is likely to include a "stick" option where you don't have the latest version shoved on to you when it's ready, but when you are. Currently "when you're ready" has to be in the next two weeks, but that's not good enough for most so I'm expecting it to become a lot longer. That function would…

I think you might want to reach out to your own APAC team - we're a global community of people who use Atlassian stuff, and don't really have localised teams. (Regional groups, but that's because the groups have a locality in common, and/or an ACE nearby, not teams with any goals or tasks)

There's broadly two things that can cause this LDAP synchronisation is failing - you'll need to test it in the directory screen and check the logs for sync errors Your directory administrators have genuinely removed the people from their groups

Can you tell us what the error messages are?

Start at https://developer.atlassian.com/cloud/jira/platform/rest/v3/?utm_source=%2Fcloud%2Fjira%2Fplatform%2Frest%2F&utm_medium=302#api-rest-api-3-project-search-get which is a REST call to fetch all the projects. Same doc has instructions on requesting limited sets of fields.