Phill Fox Community Champion

Hi John What you are saying makes sense but I am not sure how embedded you want the payment to be. If you offer many different types of payment then it may not be possible to automate them all. I would approach this by using a workflow which basically steps through as follows. Create request on portal - Awaiting payment…

I believe that the solution to your problem is not so much about using a custom field but actually using a feature called "Security Levels" with this there is the ability to determine which group of users can see which tickets. The steps to set this up are briefly as follows 1. Decide on who your different groups of users…

Edit reason - Later reply identified a plugin that was released following the original comment date, thus rendering this response no longer fully accurate.

@Prem Chudzinski _extensi_ I stand corrected and will investigate your plugin further. I will amend my original response to state that this is not part of core JIRA Software functionality rather than not possible. @Tim Saunders1 As you can see there is an option through a 3rd party plugin and I apologise for not being…

I would not expect any other parts of JIRA to be impacted other than the project using the specific workflow. But it is always worth checking.

An alternative approach is to use the behaviours of ScriptRunner for JIRA to hide/show the field as required. More documentation is available at https://scriptrunner.adaptavist.com/latest/jira/behaviours-overview.html As suggested by Christoph you could start the count on your custom field when you make the transition to…

Lets consider the two cases. Data - you are possibly going to see resolutions that you would expect to be excluded. Remember that the resolutions exclusion will not be retrospectively applied to existing issues that have a resolution already recorded. Operations - if an operation does not obey the exclusion property it may…

Hi Sandor The issues you might experience are that the restrictions on resolutions may not be fully applied and so you would have anunexpected resolution against an issue. As I tried to explain above the difference between include and external is associated with when a new resolution is setup. If you use exclude you would…

Hi Sandor I have never experienced any issues with using the jira.field.resolution.exclude property but there are no doubt some edge cases where it may cause issues. In cases like this you should fully test your system to make sure you are not impacted. The key areas to test include 1. The normal workflow process within…

Hi Emma One option would be to build a page with content from the pages you want to include using the Include Page Macro (https://confluence.atlassian.com/doc/include-page-macro-139514.html) or the Excerpt Include Macro (https://confluence.atlassian.com/doc/excerpt-include-macro-148067.html) Then you can export the page…

Hi Herbert You can add the sprint and version fields to your issuetype that is used for the request. You can then use automation rules or a plug-in to capture the information on the linked ticket and bring it across to your request. Personally I would use ScripRunner for JIRA to capture the details of the sprint and…

I assume that you are capturing some estimate against each sub-task and that this is then being included in your burndown charts which is why you are considering them to be broken. JIRA Software considers all estimates set at the start of the sprint as the committed delivery. Any adjustment to items in the sprint - changes…

This is not a direct answer to your question but is an explanation of some of the challenges you will face trying to calculate the SLA in date format rather than hours to review. SLAs are calculated against a calendar. Out of the box JSD comes with two configured calendars 24x7 and 9-5 office hours. But each installation…

As an alternative to the answer given by @Nic Brough yesterday. As you already have a resolution which you wish to change I assume that you are already on a Closed/Resolved Status. So you can add to your workflow a transtition which self-references the current status eg from Resolved to Resolved using the standard resolved…

For JIRA Cloud you can export the project to move as a CSV from the tools menu and then using the CSV import tool reload the content back after you have initially created the project to which you want to restore.

You will be pleased to know there is a straight forward process that is documented at https://confluence.atlassian.com/adminjiraserver070/restoring-a-project-from-backup-749383456.html for how to import a project from a backup. So in big picture terms backup JIRA instance A and then import from the backup into JIRA…

In addition to the comment from @Bob Swift [Bob Swift Atlassian Add-ons] I would also think about the edge case where you had two defect subtasks which would have caused the parent issue to be flagged. Do you still want to clear the parent if only one defect has moved to "In Refinement"?

In order to do this you need to be able to identify which geographical region each issue is associated with. Once you have this information stored about each issue you can then build your SLAs around each region and with different calendars to cope with regions/holidays etc.

Check your global permissions to see who has permission to create spaces and confirm that you are in at least one of the groups with permission. <yourhost>/admin/permissions/globalpermissions.action

The JIRA Charting Plugin is designed (as are all gadgets) to be used on dashboards rather than Agile or Project pages.

Hi @Paul Cleghorn If you make the sprint field visible on your edit screen you can then remove manually or via a bulk edit the entries. You can then remove the field once you have resolved the issues. Hope this helps. Phill

You can force a transition based on a custom field content using a post function. Depending on the plugins you already have installed this may require the purchase of an additional plugin to provide the ability to check a customfield content and then update the destination based on that content. An alternative to the…

Hi Your code will read the value and store it in the JIRA database, however it will not refresh that value when you move the issue to another project. So you need to understand that once the value is stored it will not be updated as a "live value" until your code is executed again. Depending on how frequently you move…

Hi You need to either create a new notification scheme or take a copy of the existing default notification scheme and then edit that version. Once you have the notification scheme defined apply it to your single project (by replacing the default notification scheme) Hope this helps Phill

Hi Gary, You may wish to look at https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html which shows you the versions of JIRA and the end of life support. From this you will see that 3.12 is not actively supported. There have been many upgrades including security upgrades since the…

Ok so if you look at the permission scheme what is the rules for people who can access the project? Is it as I suggested those with the role of users? If not this combination of permission scheme and roles is where you should look to adjust.

There is not an easy way of rolling back the changes that you made. If you have a recent XML backup from before you made the changes you could copy this in to a development environment and manually restore to match. The simplest approach to managing permissions for different projects is to use a permission scheme that…

@Steven Behnke I spend far too much time working with organisations who need more control/options over sprints than I care to consider. But thanks for the recognition. It would be a good blog for Atlassian to publish about how to use JIRA Software with complex project/team structures.

Ok that is not that different. So the way I would approach this is as follows.Team A filter : sprint is EMPTY or Sprint ~ "Team A"Team B filter : sprint is EMPTY or Sprint ~ "Team B"In this way as soon as an item is moved to a sprint it is removed from the filter for the other team and so no longer shows in their backlog.…

@vincentj It should not need to add an extra step into your sprint planning. If your queries identify any issues not assigned to a sprint OR assigned to only one team, you can do your product backlog grooming using either board (as these issues will not be assigned to a team). As you identify issues for a team during the…