'Live Fields' is one of the most powerful features in Power Scripts™ for Jira. Imagine your Jira instance as a delicately built house of cards. You've labored over it, creating epics, stories and tasks and assigning tasks in a way which manifests in a towering monument of workflow glory. The last thing you want is for some well-meaning but clueless person (ie. your colleagues or boss) to go poking around, changing dates or other important fields ultimately causing your hard earned work to crumble in a heap.
Fortunately, Power Scripts Live Fields function is that protective fence you need to shield your property from catastrophic destruction (this might be a slight an exaggeration..)
Live Fields contains several routines for Simple Issue Language (SIL) used to manipulate your Jira instance's user interface including the standard and custom fields in Jira, the custom fields provided by our apps (eg. Power Custom Fields, Power Database Pro and more), and certain other graphic elements like buttons, tabs, and so on.
By using our Live Fields routines you can:
- restrict visibility on issue fields or tabs (show/hide or enable/disable them) to certain users
- restrict certain options from the potential values of a custom field
- change the values in the issues' fields on the screen automatically when a certain field value changes
- display field or dialogue messages
- execute your own javascript code
These routines help you ensure governance in your organization by making sure only certain users can edit certain things and prompting users with dialogue messages to enter complete and correct info when creating tickets and tasks. It also helps by automating and streamlining the issue updating process. The actions that you can execute with live fields are also available on view, edit, create, and transitions screens. Please note Live Fields can only be used in issue screens, (you cannot use Live fields for the administration pages of Jira, for instance). Check out the resources below for a comprehensive walk through on how you can use Live Fields to edit your Jira interface and ensure process governance and a well constructed, hurricane proof Jira board.
In origami, there are many types of base folds that give you a good starting point for more complex creations, for example, in order to make an origami crane, you would first start out with the folds that make a basic bird base. The same principle can be applied to using Power Scripts. At the recent Atlassian Summit in Barcelona, we gave visitors to the Power Scripts booth an opportunity to challenge our experts with something we called the 5 minute challenge. We asked users to come to us with a problem they had to see if our experts could solve the problem using Power Scripts in 5 minutes or less. As more and more customers tried unsuccessfully to stump our experts, we excitedly discovered that the majority of the solutions actually started out from the very same script base. We realized that this base was an important building block for many different types of scripts, much like a base fold in origami can be used to make many different types of animals. We are calling this script the loop base.
Loop Base Script
1 |
|
Common Use Cases for the Loop Base
- Checking status of sub-tasks or a value of a custom field within the subtask
- Getting the status of linked issues or a value of a custom field within the linked issue
- Creating custom JQL functions
- Escalation services
- Checking attachment names
- Working with database search results
- Working with results from REST API
- Searching for other issues in Jira
- Creating a scheduled service
- And many more
Sections
The loop base is made of 3 sections, the List section, the Loop section, and the Action section. In its most basic form, the script is only 4 lines of code.
Loop Base Script
1 |
|
List Section
The List section is the part of the code where a list of objects is gathered. This list could be any other issues in Jira, a list of sub-tasks, links, rows in a database, etc. In almost every case this section only needs to be one line of code.
Examples of how to retrieve different types of information in the List section:
Select issues using JQL
|
Get an issues sub-tasks
|
Get the issues links
|
Get the attachments for an issue
|
Get data from a database
|
Loop Section
The Loop Section is the part of the code where we go through the list of objects one by one. The syntax for this loop is almost always the same. This section is essentially one line of code with a closing bracket at the end.
Here is an example of a Loop section:
Select issues using JQL
|
Action Section
This section is where actions are performed on the objects gathered in the list section. This could be writing a message to the screen, closing a subtask, or writing data to a database. This section could have as little as one line of code or many more lines depending on the action being performed.
Here are some example actions:
Close subtasks
|
Copy data to a different customfield
|
Escalate priority
|
Send an email
|
Complete Examples:
Change priority of issues that are past due
1 |
|
Close sub-tasks when main issue is closed
1 |
|
Copy data to a different customfield
1 |
|
Copy data from the parent
1 |
|
The team here at Cprime has just released a new SAFe epic to feature (E2F) translator for Jira which helps to complete SAFe implementations by translating native Jira terminology (“epics”) into terminology used in SAFe (“features”).
Why is this needed?
If you have experience in using the SAFe framework, you will have noticed that the terms used in Jira and SAFe do not match up, even though they are essentially describing the same concepts.
Someone on your team (definitely not you…) may have tried to change the Jira software native fields to better match with your company’s SAFe workflow and discovered, well, that doesn’t quite work. Scan the Atlassian community threads and there are several companies bemoaning their failed attempts to change the name of fields in Jira agile with near catastrophic results. The risks of changing a field name in Jira are multiple and this is why custom fields used by Jira Software are locked for any modifications for Jira Admins. Every such field has the description “Used by Jira Software, do not remove or modify”, and this notification is not for fun!
Risks of changing a field name include causing:
- the functionality of Jira software to break
- reports to stop working or work incorrectly
- ticket links to be lost (or lost sub issues)
- duplication of fields with the same name. This could be caused during updates when Jira cannot locate certain fields and creates them anew.
Basically, if you change the name of the field there is no way for other plugins which are using the API connections to locate this field properly. It’s the same as removing a relation or a link between the plugins and the field. Because it is so hard to keep track of which plugins are using relation by name and what consequences it will lead to, your teams cannot manage or work around this.
Never fear, SAFe Epic to Feature Translator for Jira is here!
The Cprime team is always striving to provide the easiest and most effective way for our clients to use Jira. As such, we’ve developed a new plugin using an Atlassian approved approach to safely translate fields from the Jira Admin UI to match with the SAFe terminology for a seamless approach to task management. The E2F translator for Jira ensures fields are matched properly so all reports and functions of Jira continue to work properly. We have a number of large scale clients safely using our plugin on instances with 10,000+ users already!
Here are some examples in action:
#1 – Defining your enterprise hierarchy of work items: If you’re not using Cprime’s SAFe epic to feature translator, there may be some confusion among teams about the status of work as work items don’t carry across easily from SAFe planning into the Jira board. However, using this plugin organizations can “standardize” a work item hierarchy which makes data consistent and easier to trace.
For example:
- A developer can now see the story he works on and how it connects to the larger feature that will be released soon.
- An executive can now start top-down and can drill into a Feature from Confluence and see all the component level work associated with it.
- All levels now have the context of the work item in their reporting and conversations. Think normalization and standardization.
#2 – Tracking the status of features:
- navigate to the issue search in Jira
- run a JQL search for issuetype = Feature
- cut out Features that are done. status ! = Resolved
“Visualize the query being translated from Epic to Feature Issue Type”
Seamlessly transfer your SAFe workflow into Jira? Now we’re speaking the same language! To get your free 30 trial simply visit here and see for yourself how easy it is to translate your SAFe requirements into Jira.
In order to provide fast searching, Jira creates an index of all the text entered into issue fields which is stored on the file system and updated whenever issue text is added or modified. However, if you alter your Jira instance by adding in customization (eg. custom fields) after issues have already been created or if the index has been lost or corrupted than it may be necessary to do a manual re-index of your data otherwise your search index will be out of sync and not return the correct information.
The following modifications can affect the search index and may prompt you to re-index:
Jira admins who make changes to any of these areas of configuration, may be familiar with the following message in your Administration view:
USERFULLNAME made configuration changes to 'SECTION' at TIME. It is recommended that you perform a re-index.For more information, please click the Help icon. To perform the re-index now, please go to the 'Indexing' section.Note: So that you only have to re-index once, you may wish to complete any other configuration changes before performing the re-index.
Re-indexing used to be a particularly painful task which could take hours if not days depending on the size of your Jira instance, causing interference and delays in your productivity. With no way to schedule a re-indexing using Jira alone, many Jira admins suffer from either 1) Sleepless nights as they try and re-index mammoth instances in the middle of the night which can take several hours or 2) Ultra slow Jira performance if they choose to index 'right away' during business hours, resulting in frustration from everyone trying to use Jira in the office. Whichever option was chosen, someone's sanity was at stake!
Power Scripts New Scheduled Re-indexing Routines
Thankfully, Power Scripts' new scheduled routines make re-indexing a breeze as you can now schedule the re-indexing so you don't need to run it during working hours or right away as opposed to normal Jira functionality.
Re-indexing can also happen in the background without blocking access to Jira and thanks to our new updates, the routine runs the re-index in chunks of about 2000 issues at a time so now large customers can schedule a re-index by project, and schedule out the projects they want to re-index (eg. 1 a night) so that they don't break or impact performance or slow the system down.
For the tech savvy minded: you can see the re-index progress status in the logs showing you the percentage of the re-index being done. So even during the process you can monitor the re-indexing and see how it's going. The logs are available for Administrators only.
How to schedule your Jira re-indexing
- Go to Administration > Add-ons and select SIL Scheduler in the POWER SCRIPTS section.
- Click the Schedule Job button in the upper right corner of the screen.
3. In the new window, select Cron for the Scheduler type.
4. Enter the following expression in the Schedule input box to schedule the job to run at midnight on weekdays:
|
5. Select the script that you created.
6. For the Run this script as input, select a user account with administrative privileges.
7. Press Schedule!
Power Scripts for Jira's new scheduled re-indexing function allows Jira admins to ensure both their search indexes and stress levels are well maintained with a few easy clicks! Check out our easy scheduling routines for more information:
The developers here at Cprime are really happy to announce a new feature available on Power Scripts 4.1.1 and SIL Engine 4.1.1 which allows you to copy a custom field value to a linked issue. As any great Jira admin knows, the key to awesome task management is simplification! Take a moment to think about how many of your day to day activities revolve around handling a number of issues from a single Jira instance, how can you make sure all these issues are updated in the most efficient way?
Previous to our new feature, a Jira admin would have to update individual issues one by one with the new status – not the best use of time! To speed up the issues updates, we are happy to introduce the new routine implementation Copy custom field value to linked issue/s (‘cpCfValueToLinkedIssue’). It enables a user to copy a custom field value to linked issues or by linking type.
Popular Use Cases:
The primary use case is the updating of custom field values for linked Issues (of a particular issue type). Essentially if the value of Custom Field A is updated, the same field in Linked Issue is also updated and vice versa. Another possible use case is to update Custom Insight Fields for Linked Issues via workflow transitions (using Power Scripts).
More Updates:
We have also added support for the following global Jira events for the lfWatch routine, this is going to come in handy if you need to call an IfWatch routine for the following Jira UI events on the issue screen:
1 – inlineEditSaveComplete – if a user has successfully saved a custom field that this user was inline editing
2 – newContentAdded – when any content is added to the ticket
3 – issueRefreshed – when any change is made in the ticket that refreshes the issue (not a page refresh)
How to use the copy custom field to linked issues routine
1. Install the latest version of Power Scripts. The latest version of katl-commons will be installed automatically. This is important that you have the SIL Engine v4.1.1 because the functionality/code is there.
2. Following functionality is used: Issue linking
3. To use the feature, go to Administration > Add-ons and select SIL Manager in the Cprime TOOLS section. Then select the script you've created earlier. Click Check and Save.
4. That's it. So when you update 1st Issue custom field with 'BUP2'
5. The linked subtask is updated with the same value
And the TEST 2 Issue is updated with the same value
How to trigger a script during inline editing
- To create configuration for inline editing you need to set up an IfWatch live field and SIL listener. Every time when the live field is triggered, the hook.sil is executed updating linked issues with the same value custom field. Please click on the images to expand.
2. That's it. Let's remove custom field value on the inline editing mode
3.The linked sub task issue is updated accordingly.
With our new Copy custom field value to linked issue/s and IfWatch routine, it's never been easier to stay up to date, and manage your mutliple Jira issues with minimal fuss.
Dear Jira Admins,
Rate your level of pain caused by data and workflow inconsistencies that are silently spreading like a virus, infecting your applications, work items, and ultimately inhibiting collaboration inside your organization. 
You’re probably a 10, but we cooked you up the remedy with our HTTP & JSON REST-ipes!
The Problem
As an Atlassian Solution Partner, we’re frequently asked to come in and clean up messy software applications that have derailed, or to fix botched software implementations. While the remedies are usually some blend of software and services, we’ve seen that most of these challenges across multiple organizations are quite often the same:
The lack of a cohesive implementation plan for an organization to adopt software quickly fuels multiple fires that compound into a massive blaze.
If you’re a Jira Admin managing instances, you’ve heard this story countless times. You know that the best solution is to just integrate your applications together for one aligned enterprise perspective! After a recent visit to Atlassian’s marketplace, we were shocked that a query like “integration” brought back 504 plugins related to integration. Based on the count, it seems that all software applications eventually lead through Atlassian in the form of an installed plugin. Can you say cha-ching?! 
Common Use Cases
A Jira Admin repeatedly encounters the following business problems:
- The need to develop apps / plugins that help extend Jira functionality
- The need to create specific metrics, reports or one-time pulls that paint a picture to assist program managers, or portfolio managers in an attempt to simplify their complex data.
- The need to sync Jira issues, workflows and fields with other external application systems together for one unified enterprise perspective.
The Remedy
Looking back over the recent engagements, there’s a definite trend towards data integration in an effort to align and consolidate all metadata, software applications, and workflows into a singular system. With 500 different apps available, how do you choose – Eenie Meenie Miney Mo? But then how many apps will you need? How many hours do you invest researching what app or apps will get the job done? Before you start down that rabbit hole, we’ll save you the time. You only need one app, (yes, seriously, only one), and it’s called Power Scripts for Jira. Power Scripts for Jira has the power to wrangle all of your complex Jira administration use cases, all the while simplifying your integration story to one vendor. We just rolled out a powerful new feature that allows you to manage your integration through one partner rather than a 504. #zinged If you’re a Jira Administrator, and you don’t have this in your toolbox:
Stop. Wasting. Time.
Power Scripts – Release 4.1.0
Now with the 4.1.0 release, Power Scripts for JIRA can handle JSON & HTTP routines. With these pre-built routines, you can interact with the Jira API and:
- Authenticate with the REST API via Basic Authentication in order to connect to external systems
- POST to the REST API w/ JSON payload for the purpose of updating fields in a destination system
- Acception response from REST API w/ JSON payload for the purposes of updating native fields and native custom fields in Jira
- GET data from external systems
- Set up integrations back to Jira
- Keep two Jira instances in sync
Now, users can enjoy the ability to join and integrate with any application systems in real time that uses a REST API. Get your thinking cap on because if the REST API exists, the opportunities are endless. Just think Zendesk, Salesforce, Jenkins, Telecom Systems, you name it.
Being a Jira Admin brings a ton of time management and solution challenges. Y’all know the drill, it’s Friday and you’re finally about to leave work on time when you get a last minute request for a script to be run.
Luckily, while many scripts require a Jira Admin to be present, there are numerous situations where scripts can be planned and scheduled to be run at a time in the future that is more convenient in order to reduce the risk on the business. The common use case that we see is that you have to run a script at a specified time interval or need to schedule a time for a script to execute in a repeatable way on specific days, weeks, months and so on.
In Power Scripts for Jira, using the SIL Scheduler, cloud users can now have the flexibility to write a script, schedule and plan when they would like it executed at some point in the future and can even pass different arguments into the script to get specific to projects or other Jira specifics. Hurrah! No more staying back late for you!
The primary reason for needing a SIL Scheduler comes into play when:
- you can’t disrupt users in the system
- you don’t want to run it often
- you can’t run the script off of a workflow or listener
Introducing The Power of 2: SIL Schedulers
In Power Scripts for Jira, cloud users can now have 2 primary options of scheduling and executing scripts. Previously, there was no way to automate these scripts and Jira admins had to be physically present in order for these scripts to be run. Now, admins can choose between Interval Scheduling and Cron Scheduling, allowing scripts to run in the background at a specified time.
#1 – Interval Schedule
Using this setting you can run a script at a specified interval. For example, run my script in 30 minutes once and delete after execution. In addition, you can also add an ability to make your script run in a repeatable fashion. For example, run my script every 24 hours.
#2 – Cron Schedule Using this setting, you can really open up the flexibility to write your own CRON statement in order to really dial in your scheduled events. For example, run my script at 1:00am on every Friday. The options here become endless and you can really start to customize to your needs. Options include running scripts every few seconds, minutes, hours, days, months.. You get the idea.
Don’t hate, automate!
SIL schedulers provide an easy and convenient solution to ensuring your scripts are run precisely on time and at a time where there is low risk of disruption to the system or users. It eliminates the human dependency element so you can have all the glory of a job well done with none of those pesky after hours. All you have to do is schedule your script, then schedule a congratulatory high 5 for a job well done.
Take a look at the current routines available using the SIL Scheduler:
Learn All About The SIL Scheduler
Scheduling routines
Use cases:
There are multiple ways you can use our enhanced JQL plugin to help your project management for example:
- For a SAFE implementation, you can use the hasLinksofType() or issuesInEpics() JQL function to find all the epics related to a feature or all the stories related to an epic
- Or, you could use the issuesLinkedAtDepth() function to get all the epics and stories linked to a feature but not sub-tasks
- Or, use the hasSubtasksOf() function to get all the subtasks associated with an issue or all issues within an epic
- Use the hasAttachments() function to find any issues with attachments
- Or, if you are looking for a specific attachment you can use hasAttachment() to search for attachments that have a specific file extension or word in the name
Also, something to note, these functions can be combined or used along with other standard JQL functions.
So, if you wanted to find issues that have links and also have attachments you could use something like this:
|
Or, if you wanted to exclude sub-tasks from that list you could combine with a standard JQL function like:
|
Seeing the Index feature at work:
- Install the latest version of Power Scripts. The latest version of katl-commons will be installed automatically. It is important that you have the katl-commons v4.0.16 because the functionality/code is there.
- To enable an index, go to Administration > Add-ons and select SIL JQL Support in the POWER SCRIPTS section. Then click the Enable Functional Index button.
- Let's check the example. For example, if you are using 'key in expression' JQL search at first nothing is displayed.
- Before being able to see any issues in such search, you need to assign it properly. Therefore, change assignee to admin.
Now, after conducting the query again, you will see your issue.
That's it. It means the entire expression is indexed, it doesn't run any scripts it just goes into the index in the memory. After using the query more than once, our enhanced JQL feature learns that it is frequently used and it indexed all the issues and put the expression into the memory for easy future access.
Recommended Reading
Want to see what JQL can really do? Check out some of our Pre-defined JQL functions or Advanced JQL Searches to help you get started.
Got some questions? Check out our JQL Support page to see if it's been answered or reach out to us from the same page, we're happy to help!