Mikael Sandberg Community Champion

You can use the changelog smart value to get the previous issue type. This should do it: {{changelog.issuetype.fromString}}

Hi @Robinson Emmanuel, Welcome to Atlassian Community! You would most likely get a better answer if you post your question in Mifos Community. You ended up at Atlassian Community because Mifos is using an Atlassian product for their documentation. 

You need an app that extends JQL in order to do a query like that, out-of-the-box JQL cannot do nested queries. If you check the Marketplace you will find apps that extend JQL.

Unfortunately the Audit log does not note when an issue is deleted.

The easiest would be to create a filter that returns all issues that you are watching. This JQL will give you all issues you are watching: issuekey IN watchedIssues()

Do you happen to know the issue key or URL for one of these issues that are not showing up anymore? Most likely if you cannot search on them and the direct link is not returning anything is that the issue has been deleted, you would only be able to recover them if you happen to have a backup. You should check your…

Yes, you can set a field configuration for each issue type, just go to Project settings > Fields and click on Actions > Edit fields. This will take you to the field configuration scheme and from here you can associate an issue type with a field configuration.

The only ones that comes to mind are JXL and Structure, but they are not displaying that information in the epic. Your best bet is to search the Marketplace.

Hi @forabi, That is a question for the vendor of the app, I just mentioned it as an example. You can contact the vendor by clicking on the support tab in the marketplace listing. 

Hi @Erica Dover, Welcome to Atlassian Community! In order to filter on issue type and description the JQL would look something like this: issuetype = task AND description ~ "\"something in the description\"" The "\" ... \"" indicate that you are searching for that specific phrase, you can remove it and just use "" but your…

Are you project admin or and agent in the project? Project admins and agents will be able to view the project from the portal, there is no way of limit it to just customers unless you remove admins and agents from the project.

The automation would look something like this, this is from the Automation library

@Alicia Morgan Yes, this is only available in JSM. JSW projects are using the notification scheme, so anyone that submitting an issue to a JSW project has to have an account on your instance in order to get notified.

No, you cannot use the parent/child option to make a task a child of a Story like you can with subtasks. Your option would be to use link issues, it has a parent/child link type.

There is a way to do this, you would need to use a web request to your identity provider to get the manager. We are currently using a Tray.io to get data from Okta that we then use in JSM for our automated access approvals.

@ mentioning in internal notes are sent to to the mentioned user if they have access to the project as either an agent or user, and if that user has enabled email for @ mentioning in their personal settings.

Currently you can only base an automation on fields in a Form if that field is linked to a Jira field. Forms does have a simple API, which is currently in EAP, so you could use that to get the answers given in the Form and then act on it in an automation.

@Junaid Hussain Have a look at this KB, it shows you how to create an automation that clears the resolution field for you. In it's simplicity it would look something like this: My example is manually triggered from within the issue (the automation would show up under actions on the right-hand side), instead of during…

No, but I recommend using automation instead of adding a new transition in the workflow, mainly because it is easier to create an automation and updating the workflow may take longer depending on how many issues you have. 

The short answer is no, you cannot change the name of a request type globally. Request types are project specific and therefore you have to rename them one by one in each project.

The progress shown in the epic is based on the statusCategory, not on the actual status. So, is the category for the "Ready for Implementation" set to In progress? If you look at the color of the status (gray = to do, blue = in progress, green = done) what color is it?

Hi @Ehsanul Allan, Welcome to Atlassian Community! On the subtasks that are done, is the resolution field set? If you are not setting the resolution when moving an issue to a done status it will not be considered done. You can learn more about the resolution field here. 

Also, take a look at Best practices on using the "Resolution" field for more information about the resolution field and how it should be used.

The reason your task is not showing up on the board is because the resolution is set which indicate that the issue is resolved. You have to clear out the resolution field (either by adding a transition in the workflow that clears it or create an automation that clears the field) in order for it to show on your board.

As the error message indicated you have to assign a license to the user. Just adding them as an agent to the project will not automatically assign a license. Go to admin.atlassian.com and locate the user and assign the license.

You would need an app in order to do that, the default portal cannot have sub portals. Refined is one app that can be used for this.

Have a look at this KB on how to reduce the repo size. You can either use a BFG Repo Cleaner to removes files that are over a certain size, or use git filter-branch to rewrite the history. I have used BFG in the past to do this.

Absolutely! I'm more than happy to tell you more about it.

@Abby Stiris This is awesome and so timely too. A question, I looked at that import and Asana is listed as coming soon, how soon with that be? The reason I am asking is because we are about to migrate out of Asana in the next few weeks.

Yes, that is possible if you use automation to copy the issue over to your JWM project. I have a similar setup for one of our teams were they are using two forms in JSM that the user fills out, and then that form is added as a pdf to the issue that is created in their JSW project.