Mikael Sandberg Community Champion

@Troy This smart value should do it, {{initiator.displayName.split(" ").first}}

Hi @James Leblanc, Welcome to Atlassian Community! Do you have an issue type called activity in your project? If so, then you should be able to change tasks and sub-tasks to that issue type. 

Yes and no. You can update the calendar that the SLA is using to determine when the SLA should be active. You can add holidays to it, but you cannot specify the time for when the holiday should be active, only the date. If you need to specify the time you would have to change the work week settings in the calendar and then…

Okay, in that case you would have to create the new custom field first, unless you already have one. Once the field is created it will ask you to associate it with a screen and if you know the name of the screen you can do that, otherwise you can just skip it and hit save at the bottom. Then go to your Contractors request…

Okay, so the Contractor is a request type, not a custom field, similar to your Employees request type. so do you want to add a new request type for Contractors, or are you looking to add a new field with options that shows up on the existing Contractors request type?

It is possible, and it depends on what you are expecting the integration to do. All Atlassian products support what is called smart links, meaning that if you link a JSM request to a Trello card you would not have to leave Trello in order to view the request. You can also use Automation between JSM and JWM if you wanted to…

They would have to know the board name. It has been a while since I used JSW DC, but I believe there should be a carrot button next to the board name that allows you to switch between boards that lives within the project you are on. Something like this: That should list all the boards within the project.

You can use the excerpt macro to define part of the page that you want to reuse on another page, and then use the excerpt include macro reuse it.

It is possible, at its core boards are just filters showing different issues. So you can create a Kanban board that is using the same filter as your Scrum board is using. You could even limit it so the Kanban board only show the issues that you have marked that the developers need to work on.

If you go into the request type you can see both the field name and the display name that you would see in the request form. Here is an example from the onboard new employee template, the due date is used for the Employee start date

You can always check the history if an issue and see when and who added the sprint to the issue that is causing problems. I would also check the filters on the boards, I have had teams the made the filters so broad that they spanned all our projects because it was basically just labels = something and nothing else. 

There is no way to prevent it from ever happening, but you can minimize it by educate your users. I always recommend to only assign the sprint from the backlog but using either the drag-n-drop option, or right-click and use the quick move option. That way you guarantee that the issue are only added to sprints belonging to…

If you want to do this within a Form this is how I would do it. I would create a conditional section that is based on the value selected in the first dropdown, that way the second dropdown will only be shown if the first one has the value that is selected for the section. Something like this: This would mean that the State…

@Madhu_Rathnasekar This should be it's own question and then reference this one. What does you automation looks like? All you would have to do in order to populate the Description field with the "Bug Description" would be to use the smart value for it like this: {{issue.Bug Description}} To add it to the description and…

Yes, it is possible to add more values to that list. What you need to do if find out what the field name is, you can then go to Settings > Issues > Custom fields and locate the field and then click on the three dot menu and select Contexts and default value. From here you can add more values. Please note that you need Jira…

It depends on if you are using managed accounts or not. If you are using managed accounts, then you will find the Product access if you go to admin.atlassian.com and click on Products > Users > Product access You will then see something like this where you can add groups that should have access to products If you are not…

The approvers field is a field created by JSM and is getting its data from the users that have access to your instance, including JSM portal only users. You can find all your users if you go to admin.atlassian.com. 

Hi @Abelardo Martinez, Welcome to Atlassian Community! Anyone that have access to admin.atlassian.com in your org would be site admin. I would start with asking your IT team if they have access to it and go from there.

If you by editing mean renaming a status, then yes, this is expected. You should never rename a status from within the workflow itself. The rename should only happen from Settings > Issues > Statuses because from that view you will see how many workflows the rename will affect. 

No, that is not possible unless the user manually go and change their Atlassian account and adds it to the display name.

You would have to divide your rules up in no more then 1000 issues, if you go above 1000 issues in your rule it will be throttled. You can learn more about the service limits here. I have done this in the past where I had to update about 20k issues, and used a JQL that returned no more then 1000 issues.

It can be done, but you would need either a test account that you log in to. The other option is to use one the sudo apps available in the marketplace. I have used SU for Jira in a previous life when I managed a DC environment.

If you go to admin.atlassian.com and then go to Product > Users and search for the account you can see what product access it has.

You can unlock the form, you do that by using the web request action and then call the Reopen form endpoint.

Hi @Achour Maha, Welcome to Atlassian Community! In it's simplest form the automation would look something like this: But JSM already has a notification scheme that will notify the assignee and the watchers every time there is a change to a request, and there is also customer notifications. 

You would need a separate status for the form to be filled out and submitted before you go to the approval status. Once you are in the Approval status there is no way to prevent the approve/decline until something else happens.

Hi @Consuelo Nicoli, Welcome to Atlassian Community! Because you allowing issues in any status to transition to "to test" your rules are being ignored unless you select the transition "ready for the Test". If you click on the "to test" status and uncheck the "Allow issues in any status..." then your rule should be…

Correct, automation is limited in the number of random numbers and it will only get the first 100 issues in a query. So you would not be able to do this within an automation unless you can find a way of dividing your list of issues up in at least two queries. I created a randomizer using tray.io that gets a number of…

Does that account have access to the JWM project, and does it also have a product license for JWM assigned to it? 

Are you using your own account when using the endpoint? The endpoint is not just for JSW projects, it can return issues from any of to the 4 flavors of Jira.