Mikael Sandberg Community Champion

Hi @Jane Deese, Welcome to Atlassian Community! The short answer is no, you cannot change the default hierarchy which is Epic - Standard issue types - Sub-tasks. What you can do if you have Jira Premium is to add additional hierarchy above Epic, see Configure custom hierarchy levels in Advanced Roadmaps for more…

Okay, in that case you should be able to find those with a JQL like this: project = XXX AND issuetype = sub-task AND summary ~ "\"Financial analysis\""

Hi @Geneviève Lagacé, Welcome to Atlassian Community! A little bit of more information is needed in order to give you an answer to your question. Are you trying to only get the sub-tasks with your filter? Are you trying to create a filter that gives you both the tasks and the corresponding sub-tasks? What are you trying to…

Hi @Jennifer England, Welcome to Atlassian Community! It sounds like the permission scheme on the project in question has changed, or that you have been removed from one of the project roles/groups that gives you access to the project. I would start with looking at those two things. 

The one that is called Start date is the one that is the default one that Jira creates, all the other ones are custom fields. Without knowing your instance I cannot advice you on which one to use.

The rule would look something like this: You may want to add is another condition that checks the issue type if you only want the start date to be set on subset of issue types.

You can get the Atlassian ID via the search user endpoint, and then use that to set the request participant.

Have you considered using automation to do the bulk linking? All that you would need is a JQL that picks up all the issues that you want to link to the release issue, and then use the link issues component.

Hi @Gabriel Carvalho Vitorino Rezende, Welcome to Atlassian Community! Your site admin has enable access to Product Discovery, based on the error message you have not been added to a group that give you that access. 

In that case then use use {{issue.myField}} in the reporting. Note that you cannot trigger the automation on when the issue is created if you are using Forms and link fields to Jira fields. The data in Forms is not transferred to the Jira field until after the issue is created, so in order to get the data you have to…

No, there is no way other then giving the Dev user an JSM license and add them to the Service Desk Team role. It is only agents that can reply to customer.

Currently the only way to include data from a Form in an automation would be if you have linked the Form field to a Jira field. You could then access that field in the automation and check if it is a specific number, something like this:

Replace the transition in the if/else component if the approvers - customer = reporter with the Approve/Decline request action.

Yes, you can hide statuses from customers. Under Project settings > Request types and select the request type you want to change. Here you will see workflow statuses, all you have to do to hide a status from the customer is to give the hidden one the same name as one that should be available. See this KB for more…

Hi @Christiana Graham, Welcome to Atlassian Community! I believe you ended up in the community because the company that is responsible for TIDE is using Confluence for documentation. This community is all about Atlassian products and I don't think anyone here will be able to answer questions about TIDE.

If the request is on a status that requires an approval you cannot use the transition issue component, instead use the Approve/Decline action to bypass the approval.

This is expected behavior, any time you add the Resolution field to a screen it will automatically be required. The Resolution field is an important feature in Jira. It specifies the reason an issue is closed and removes the need of having multiple statuses with the purpose of stating why the issue is closed,…

The article you found only applies to Data Center, not Cloud. In Cloud automations are found under Project settings > Automations and have components to lookup Asset objects. Here is an example where I set an Asset object field for linked assets: If you go this route the AQL would look something like this for the internal…

Another option would be to have external object and internal objects that you link together, and then use automation to set the internal object field based on what the customer selected. 

How are you creating the new project? If you click on Projects > Create projects and follow the on screen instructions, on the screen it asks for project details you have the option to share settings with an existing project. This will set up the new project the same way as the existing one without copying any issues over. 

Hi @Rachel Wang, Welcome to Atlassian Community! It is the field that is set to the label in Assets that will be displayed in the field on the portal. So in order to only show the customer facing name you would need to change which field is the label in Assets, but that will also affect the backend. But unlike the portal…

I agree with everyone else, this was a really interesting and informative series. Finished the last episode today during my daily walk. The part that I really liked was to hear from the actual people that worked on the project.

Also check if someone moved the requests to a different project, an easy way to check that is if you have the issue key for the request that is missing, you can then enter it in the search bar to see if the issue is found.

Even if the requests were created via the preview (this only works if the request type has already been added to a portal group) or via the Create button they should show up in the project. If you do not see them in any of your current queues you could create a new one that shows all your requests. Next I would check your…

Hi @Zack, Welcome to Atlassian Community! The request type was made a required field when Atlassian added the option to use request type fields so that you would see the same thing that a customer via the portal would. If you click the drop-down you have an option to set it to No request type to bypass it.

Yes, that is possible, and it is easier if the custom field is a user picker field instead of a text field. If the custom field is the latter you would need to get the AtlassianId for that user first.

You cannot link a custom field to a project role, so the only way of doing this would be to use the REST API. You would first have to get project roles for the project, then get the specific role in order to get the members of that role. Once you have that then you can update custom field options. Please note that this…

Currently it is not possible to automate because there is not API endpoint that allow you to remove product access, all you can do currently is deactivate a user. Atlassian is working on expanding the admin API and is currently scheduled for sometime during 2023 according to the public roadmap.

Jira Product Discovery is still in Beta, and that is why you do not see the total number of licenses you have (which technically would be 20000 users). Regarding JWM, the users that are in the jira-core-users group, do they also belong to jira-software-users? That would explain why it says No licensed users. Jira Software…

Hi @Ramesh Gopalakrishnan, Welcome to Atlassian Community! The short answer is that you cannot change the location on were the form is shown. What you could do is add the required fields in the form and link them to Jira fields and have them show up based on the user's answer. You can use sections to conditionally show…