Mikael Sandberg Community Champion

Hi @berto.ceballos, Welcome to Atlassian Community! All you have to do is go into the issue itself, the sprint field will indicate the sprints that the issue is/has been in. You can also check the history to see which sprints it has been in. 

There is, but you would need an app in order to do that. You could probably do that with one of the out-of-office apps that are available in the Marketplace. The other option would be to use the on-call schedule in JSM and the user would then put themself on the schedule or use the override when they are not available, but…

There is no REST API endpoint that will let you know if the user is logged on or not. The only way would be if you could access their computer and see if there is an active session cookie, but that would only tell you if they have logged on recently.

You can't. Agents has to be able to edit fields in the project, and there is no way in Jira to set individual field permissions unless you have an app that allow you to do that.

And you can also add quick filters that works the same way as custom filters in TMP. Just go to Configure boards > Quick filters.

Company-managed boards does have filters as well. If you go to Configure board > General you will see the JQL used and the filter.

Hi @Michael S_ Morris, Welcome to Atlassian Community! Have a look at this article that describe how you can do this based on when the request is created and who is on-line at the time. I used this to set up our round-robin schedule until we started using the on-call schedule in JSM instead. The issue with using the…

Hi @Ryan Tracey, Welcome to Atlassian Community! You cannot use the Cloud API to add users to groups on Jira DC, you have to use the API for DC which you can find here. Jira DC do not use the accountId so you should be able to add them based on their username in your environment.

Ah, that cannot be done. Sure, you could remove it from the default screen, but then you would not see the field when viewing it. Note that it is only agents that can edit that field after the request has been submitted (this is a default setting). 

Just to add to @Jack Brickey great answer. If your client has access to the enterprise plan then you can get a report for this in Analytics. One of the template dashboards have a chat that shows you the number of times an issue has moved between different statuses.

That is a custom field that has been added to the issue layout. You can remove it by going to Project settings > Request types > Incident, then select the incident type and from here just drag the field to the right to remove it from the issue layout.

That is a custom field that has been added to the incident type. In order to disable/remove it just go to Project settings > Request types > Incidents and the select the request type. From here you can remove the field by dragging it to the right on both the request type form and issue view.

Hi @michael_miranda, Welcome to Atlassian Community! Yes, this can be done in a company-managed project. What you need to do is update the permission scheme that the project is using and define who should be able to browse project and other things. I would suggest that you use the existing project roles in the permission…

Yes, that is possible, you just have to edit the workflow and add a new status. At my previous company I had a draft status that automatically transitioned to then next one unless the user checked a checkbox. This was used so that the user could quickly log an issue without having all the information and they could come…

@Jeremy Drexler It looks like the delete attachment step is not converting the $ regex correctly. I just tested and .*.har seems to work.

Currently the transition is not considered, so if you have multiple transitions to the same status the automation would trigger on all of those. There is a suggestion to add the ability to trigger on transition, see AUTO-824. You could work around it by setting a custom field as part of the transition so you know which…

You cannot do this using an automation in just the SD project, you would have to create a global automation that either triggers on the transition to the status that sets the resolution on the linked issues or on the resolution field change. Something like this should do it: So instead of working this from the SD project…

Hi @Jenny Chen, Welcome to Atlassian Community! The email request is enabled by default, you can go to Project settings > Email requests to see the email address that was created for your project. If it is not enabled you enable it from there too.

A JSM project can only have one email address associated with it, but you can work around it by forwarding to it from other email addresses. I have a project that have 3 different email addresses that is forwarding to it and then I am using automation to set the component based on what email address was used (it is added…

You could do it via the REST API, there is an end point for archiving projects. Another option would be to use Scriptrunner, the Adaptavist Library has a script to archive projects (it's for Data Center, but I bet it can be converted to Cloud).

It can be done, but you would need an app from the Marketplace in order to do it. You could then use automation to set the color based on the due date.

No, I would do the same thing that you are doing by looking at the reporter and then change the request type based on that.

From the backlog, open the epic you want to change the color on and select view details. From here just click on the color square next to the summary and select the color you want.

If you are using different project then the check box to only display sprints in the current project would do the trick. But as I mentioned in my first answer, I always recommend that assign issues to sprints from the backlog, that way you are avoiding the situation of adding the issue to the wrong sprint by mistake.

It can be done, but you have to use components, labels, or a custom field to do it. Then you will have to change the filter on each board so that they only pick up the issues that relates to that board. I would recommend using components since you can then control those from project settings. 

Just to add to Bill's excellent suggestion. You could utilize SLA for it as well that starts when the request is approved and then use the SLA threshold breach trigger to send the web request to remove the access.

Yes, and no. The history shows that the issues were removed from Sprint 177, but it does not indicate that the sprint was removed. But since you cannot see the sprint when you go to the Sprint report, that indicates that the sprint was deleted.

This might be a good resource, Manage how work flows in your team-managed project, it talks about multiple workflows and the board.

The easiest way to see the two workflows that you have is to go to Project settings > Board > Columns and statuses. From there you will see that you have two workflows, it should look something like my screenshot above. 

No, the backup option that Atlassian is working on would be for the whole instance, not for separate projects. There are apps in the Marketplace that can do granular recoveries, for example Revyz data manager