Tarun Sapra Community Champion

Devs create al sorts of sub-tasks which sometimes make no-sense and thus there is a need to sometimes delete some issues.

ohk, got it. thanks. In the docs they have only mentioned the types against jira.permission.* i..e users/groups/roles thus got missed. But this blog link helped. http://www.j-tricks.com/tutorials/permissions-based-on-workflow-status

Hi Nic, In the workflow permission I only see the editable issue permission - jira.issue.editable , I guess that should do the trick. But I dn't want the issue to be "non-editable" just non-deletable.

I hope this is documented soon, I was quite confused as to why some fields are missing. It's better to make sure only people with admin rights can perform this operation so that they can see all the fields.

If it's a hosted version of jira that you are using, then why don't you just write a small groovy script using script runner plugin and put that in the validation phase of the create issue transition. Javascript messes up jira.

In the code above- 5 is the transiton ID which will take the issue to current status to resolve status thus you need to know your transition ID of the transtion that you wish to execute which can be global transition( from all statues to closed) or it can be a single transtion( form a particular status to closed) Just open…

Hi Jan, Your code seems to be fine, only thing that might be going wrong is the transition Id workflowTransitionUtil.setAction (5) Make sure you use the transition Id from your workflow instead of the one given in the docs

see my answer below..

Atlassian isn't implementing it any time soon - https://jira.atlassian.com/browse/JRA-4812 their qiuck fix - https://confluence.atlassian.com/display/JIRA/Setting+a+Default+Value+in+the+Description+Field my quick fix - either use bulk update or use script runner…

Hi Devu,Can you please share your archiving strategy? thanks

Hello @Ercan Canlier My Suggestion will to use "Cascading select list" as it will be easy for the user to see the department names mapped to the respective emails. and then use Script Runner plugin to send the custom email using the built-in post function.

You can try http://www.tempoplugin.com/products/tempo-planner/ workin' only with JIRA 6.x onwards

DateTIme custom field type displays both date and time.

Wow nice , indeed UX can be confusing ( try issueType migration ) @Lior Pesoa Please accept/upvote the answer. thanks!

Creating a field which is similar sounding as that of a system field is a really bad idea. 

Then you need to configure your field configuration scheme in such a way that the field configuration in whcih components is mandatory only applies to members issueTypes and not for bug thus different behaviour for diff. issueTypes it's easy to do…

Thats your problem right there, you are using the default field configuration scheme for all issueTYpes, you haven't associated the project with the "Field configuration scheme" which contains the Field configuration scheme for the issueType "Members experience"

thanks, can you also share the screenshot from the "fields" section of the project-admin section , I want to see the field configuration scheme mapping the project admin section versus the issueTypes

@Lior Pesoa Can you paste your field configuration? and field configuration scheme screenshots. thanks

Please see here - https://confluence.atlassian.com/adminjiraserver071/specifying-field-behavior-802592555.html "whether the field is required (i.e. the field will be validated to ensure it has been given a value) or optional" And you have can have a different field configuration for different issueTypes in the same field…

Please add a specific "Field configuration" for the that issueTYpe and make the components field mandatory on that field Configuration. Once you make it mandatory it would appear on the screen with a red Astrix which means mandatory. The solution by @Elifcan Cakmak is also possible but it in that case user would see the…

I think I missed the part about "Sitte-admin" in cloud part. Apart from the normal admin stuff (adding, removing users etc) the thing which site-admins can do as well is the "Access to billing information"

Hello @Liam Williamson "jira-administrators" is a group, now it depends on how you have mapped this group in your "Global Permissions" There are two major Global permissions related to administration JIRA Administrators Ability to perform most administration functions (excluding Import & Export, SMTP Configuration, etc.).…

I guess you want to add the content in some fields, try custom fields of type limited or unlimited text

In your JQL search, you just write -> parent = "ISSUE-1234", thats it! and it lists all the subtasks and then you can export that list

Also, You can loose your custom field data permanently if you haven't mapped the custom field to the new issueType, please see the above JIRA ticket link that I have posted

You might loose some data if you do bulk move, thus my suggestion is do it first on test machine, and then see which assignee have gone missing and then update those in production with project lead and then do issueType migration. But to be honest the whole User Experiencce of IssueType migration is pretty crappy I have…

Some of your old issues might have assignees that no longer have "assignable user" permission in your project thus you can't retain them.

Scripted custom field is part of script runner plugin https://jamieechlin.atlassian.net/wiki/display/GRV/Scripted+Fields

@brent- I hope you haven't forgotten to publish the workflow after adding your new step.