Nic Brough -Adaptavist- Expert

>But when i create a ticket. I see the field is present. I am sorry, I misunderstood that to mean it was present on screen when creating the issue. The strike through appears when there is any value set in the resolution field. So, when you were moving from done to in-progress, the field is either on the transition screen,…

It's the tendency to go more modular, which is a common tenet of natural technological development. Where people used to build something from scratch which eventually came to meet their exact needs at the time, industrialisation, mass manufacture and technology naturally push us towards modularisation. Why have a load of…

This suggests you have had an inexperienced admin add "unresolved" as a resolution in the list of options, AND placed it on the "create issue" screen. Remove the field from the screen immediately, then rename the "unresolved" resolution option to something like "broken resolution - do not use". You'll then need to look at…

You'll need to describe what you want to "display" in full. "A group of issue types" does not really tell us anything we can work with.

Just to clarify some "Jira speak": A role in Jira is a global thing that goes across every project. Here, roles are not being removed from projects. I think what you mean (again in "Jira speak") is that some (project) roles are not being populated with groups and/or users when you create new projects. This happens because…

I think the notion of "career" has shifted over the years. When I was a kid, my parents and grandparents did shift career (fewer than 5 times though), the more surprising ones being swimming coach -> biochemist -> anthropologist, and teacher -> health worker -> chocolate taster -> counsellor My careers so far have been…

You can't - there's more than just a request type attached and you don't enter that. Via email, you have to set a default request type for emails - see https://support.atlassian.com/jira-service-desk-cloud/docs/choose-a-request-type-for-email-requests/

Request type comes from the customer (or agent acting for a customer) creating the request (not the issue) in a portal. The issue you've got here was created in the back end, not from a portal, so it has no request type, or interface to the customers.

Think of active and inactive as indicators of whether a workflow is in use, not a flag you set (a flag would be of no use - what matters is if a workflow is set to be used by a project or not)

Does your project lead have admin rights? Admins don't have to be agents to create and configure projects (although using them as an agent, they do need to be agents)

The question you gave us implied you were struggling with urls, so I tried to answer for that problem. If you'd already updated the url, then there was no need to talk about localhost in the question, and I would have suggested that you check the logs next, as it's unclear what the problem was. A permissions problem on…

Yes, once mounted in the right place, the shared directory will do all the work for you. You must NOT move any other folders into there (although you could put other stuff in there, for other applications, that would make your Jira install look very odd and will cause problems if there are any name clashes such as another…

Your query is explicitly selecting unresolved issues. Try assignee = currentUser() and resolution is empty

That would be a very poor thing to do to an admin, and will absolutely not "close" any security vulnerability.

No, there's no reason for this to go into the history - it's a configuration change, not a change to issue data, and the issue history is about the issue, not config.

The workflow is about how you want to handle requests coming from your end users. Creating a request is only the first step, the rest of it is up to you and your processes. In your list, steps 1-3 are built in things in Jira Service Desk that aren't part of the workflow beyond being just the "create" step. On step 4, the…

I've seen two broad methods used for this. The short versions are * Bugs as stories (sometimes in the same project the original story was in, sometimes in other projects) * Bugs as sub-tasks If you are doing Scrum, the first option is a lot easier to work with in Jira. This is because sub-tasks effectively add work to the…

Ok, I would drop the "level !=" part of it, you do not need it. Imagine you have 5 issues, with "internal only" set on 2 of them. You, as an internal user (matching the rule for "internal only", which I guess is something like "group = internal users") can look at the dashboard, or search, etc and you will see results…

The usual way to do this is to set the Jira data directory (I usually call this <jira home>) to something in the same way we do for Jira Server. You do this on every node. In my example, I'll go with /data/jira, under which you create /data/jira/jirashared - that jirashared is the default. On the first node, you then mount…

Issues do not "move workflow". Workflow is directly determined by, and locked to, the issue type (the workflow scheme for a project tells Jira which workflow to use for each issue type) So, your question is not "move workflow", it's actually "change the issue type". This is not something you are going to do in a "snippet"…

I think you have the "Cenote Lockpoint" app (used to be Aresnale lockpoint) which is capable of locking attachments dynamically and controlling access to them. The error you've got is quite generic, but I would ask your space admins to check your permissions, and then ask the Confluence/system admins to read the log files…

Due <= 0 means "the due date is before or equal to <base date of timestamps in the datatabase>", which is probably going to be something like 1st Jan 1970. I think what you want is "Due <= now()"

If you are using "issue level security" to "classify" your issues, then you can share any dashboard with a customer - Jira will simply not report on any data that is classified. Can look a bit odd when an internal user looks at a dashboard and then a customer does, the customer will see lower issue counts, fewer results in…

So, you need to decide if you want to see the "to do" stuff in the backlog or not. To include it, you need it mapped on the board, but remember that it will not appear on the board because you won't be drawing it into a sprint, so you can have your first column contain "to do" and "ready". Starting a sprint won't remove…

Cloud is maintained at "latest", so there is no real "version". But when there are changes being rolled out, they do not go to every Cloud site immediately, they proceed in waves, so it is possible that one of your versions is behind another. However, at a glance, it's because your landing points are different - one of…

If you wrote a service that runs a search regularly, you could iterate over the results and run https://library.adaptavist.com/entity/transition-an-issue-using-issue-input-parameters to transition each issue found.

I?f you raise a support request with atlassian cloud support, they can move your system from the current url to a new one. https://support.atlassian.com/contact

Hmm. What's that plzzzzz bit? JSU should be fine for this, but the validators in the workflows I've got throw me back to the transition screen fine, so I'm a little confused.

There are three ways to get to see a page in Confluence (to keep it simple, ignoring page restrictions) * You are logged in as a Confluence user, and you have "use" permission in a space * You are logged into a Jira service desk as a customer, and that desk is linked to a knowledge base space * You are not logged in at…

The community board chose not to do this because there's no way to know where to draw the lines in terms of size, and it might be unfair on newer apps and vendors. We started the examples with things like Tempo, Insight, Zephyr - things that added a lot of functions, but then do you go down to popular stuff like Jira Suite…