Vishal Biyani Expert

@Arpita Solanki Have you written any automation rule so far? there is a limit to number of issues that can be handled via automation at a time. First business problem should be scoped properly, then the rules should be straight forward to handle. if you run JQL where target end date is empty does it returns few hours or…

Hi @Max_Clark 5 hours will go in Original Estimate. User will log actual hours against the story. in this example 2. As the end of sprint, you should be able to get Actual vs Original estimate. Will this work for you?

Iterate over fixVersions {{#issue.fixVersions}} if(name.match("*(ABC)*"), <True do something>, <False do other logic>) {{/}} see if this works for you

@Patrick Cartier Do you have specific rules for exclusion? if so, you can iterate through the list of fixVersions and if they match the rules for exclusion then don't append in Epic else append it.

@Milly Eames One of the problems could be with your use of withDay. As per documentation link, under section Date with attribute {{[date].with[attribute](input)}} there does not seem to be an attribute called Day. Trying to print something simple like {{now.withDay(10)}} returns nothing. Another thing that appears odd to…

Assuming your developer field is a multi user select field For assignee to developer field, you can do Trigger When Field value changes for Assignee Then use advanced json edit to update developer field. Note: in the below SS I have development manager. You need to use the field that you have. Once this works, the reverse…

@Vidhi Parmar Have you tried to write some automation on your own? When you say when assignee is updated, developer field (custom field) should be updated. This can be handled via an automation,

@Leong Peng Kwai Refer to the link that should help you get started how to create the issue using JIRA REST API

@Víctor Hugo Ortega Tenorio The context is not clear. Jira has Epic -> Story/Tasks -> subtasks. Do you have a customized hierarchy? From which transition to which transition are you talking about and for any issuetype or a specific issuetype?

@Deniss Bulbuks Looks like others are also facing issue. Looks like some bug got introduced recently impacting users. You can check this link and this where others are reporting similar issue

thanks for sharing the details. in this case, I have no more ideas why it stopped working for you,

one clarification in that case, At the time of issue creation can the original estimate be updated? I now understand that none of the users or role are able to edit original estimate value.

Go to project settings -> permissions and check if Admin role has right to edit original estimate field. As you have mentioned, if folks with Project Leaders role have access to edit the issues and not admins, then you won't be able to edit it. Give yourself the edit rights for edit issues and see if this works.

The format for @mention to work is [~accountid:{{issue.assignee.accountId}}] or replace the bold values with your fields. However, as Rebekka rightly mentioned, sharing what you have put in place so far and the audit logs will help in analyzing the problem

@Deniss Bulbuks if you are not able to update original estimate fields, most likely your jira admin has not given your user/role, the required privileges to update this field.

In JIRA cloud importing the issue is creating a new issue. Seems some functionality has changed as previously i think given an existing issue key and summary, we were able to update other fields.

@Bentley_ Andrea As per the documentation only time part is converted not the date.

@kirkland Are you on free JIRA plan? Are others in the team able to access the site?

@FNU MRINAL Sprint closure is dependent on the last most column in the scrum board. If you add the status Ready to be marked Done, then you will be able to close the sprint with correct metrics.

@Abdelrahman Alfawaier Assign issue Component Lead Using Post Function, you can assign the issue to Component Lead at the time of transition. Restrict issue transition You can restrict who can transition the issue. Limit number of subtasks This can't be done natively in JIRA. You will have to use script runner or some…

@Yugandhar Kumar Chintamaneni There looks to be a typo in how you are using fixVersion. Try with this {{issue.fixVersions.name}} Someone else got it working using "Fix versions" There are known issues for fixVersions. See this open issue You could be having issue due to that. in that case it will be a dead end. To rule out…

@Vivek Chauhan if you refer to this article it will give better clarity. See if this helps

@Bud Herz In your workflow, you can add a validator to check if Story point is not added, then don't let the issue transition. As JIRA Admin, click on the desired transition, a screen like below will pop up Click on Validator and then Add Validator button In the form select Field Required Validator. Let me know if this…

@Supriya Gunjal Can you share the screen shot of both the rules? That way folks can understand if there are any obvious problems why the rule is not triggering.

@Eric Trucco As far as I know native JQL does not allow history search on duedate field. Your options are * go for a marketplace app that allows for History Serach on this field * Use automation/programming to get list of issues based on changelog

@Todd Reynolds Looks like it is not feasible to do this in cloud. Please check this article You can though add Feature below Epic (alignment with SaFE) if you have premium subscription. You can refer to this article for details

@Suzi Firth Can you try with exists? e.g. if customfield_10272 does not have a value, then content inside if block won't be printed. {{#if(exists(triggerIssue.customfield_10272))}} Value: {{triggerIssue.key}} {{triggerIssue.customfield_10272}} {{/}} Let me know if this works for you.

Glad to know it worked for you

@Jordy Vervuurt Can you share the link of the youtube video that you have referred to?

@Luke to better understand your issue, it would be great if you can share the screen shot of your current workflow. In absence of any SS, all I can say is most likely JIRA Admin has edited the workflow.