nFeed 5.11: Smarter queries for when the dog ate your values


Posted by
Christophe PROME

May 18, 2017

Our leading add-on relies on its ability to quickly find exactly what you’re looking for. Therefore we’ve recently made some changes to make it possible to query JIRA REST API, but we’ll get to that in a bit….

However, we don’t believe in frantically searching just to exert energy. Sometimes the values you are looking for don’t exist for whatever reason. We aim to be efficient and timely – but realise some solutions just need a zen approach.

For this release of nFeed, stay calm and query on (wink)

The mini 404: ‘value not found’ now in the template

Sometimes you just can’t find what you are looking for. Maybe the selected value in the nFeed field was deleted from the remote datasource. Maybe the dog ate it or it was snatched by an UFO…you may never know.

Until now, the fallback was to display the key, which is not very informative as to what the problem is exactly. 

We wanted to let the user know that the data is missing.

nFeed field referencing an issue that has been deleted

nFeed field referencing an issue that has been deleted

With our mini 404 value, it is now possible to define a ‘value not found’ display that will be used when the value requested is not present in the result of the query.
In this template, you have access to the field value through the variable {currentCustomfieldValue}.

Learn more in nFeed documentation.

Local JIRA REST API

nFeed offers two ways to query your local JIRA:

  • SQL queries on the database. It is powerful because we can fetch any kind of data, but it requires an advanced knowledge of the database scheme.
  • JQL queries to get issues. Very convenient and easy to use, but does not fit 100% of the use cases.

With this new release, it is now possible to query JIRA REST API!

This bring new possibilities, as the JIRA REST API is rich and well documented. For example you’ll have direct access to issue comments, votes and remote links!

We should not forget to mention that this new feature will allow you to query the REST API provided by any JIRA add-on like Insight or Tempo… but we’ll come back to this in a future blog article. Stay tuned!

If you have declared the local JIRA datasource in nFeed, the new mode is already available. If you haven’t yet, it’s time to do it now so you can start accessing the JIRA REST API.

‘No result’ label for readonly fields

Here’s an improvement to the UX of your issues / request forms: the ability to define the label to display when a nFeed readonly field has no value.

Those fields are mostly used to display additional data related to the value of another field (the parent field), like the phone number of an employee.

But when users haven’t selected any value for the parent field, until now they see a blank space next to the field. This isn’t very user friendly.

KB article content field depends on Search article in KB - it will be populated when an article will be selected.

KB article content field depends on Search article in KB – it will be populated when an article will be selected.

You can set this value by clicking on the Configure button next to the Editor property of the field configuration.

Abort query: sometimes the secret to success is to stop searching

When nFeed fields depend on another field’s value, in some cases we can determine in advance that the query will not return any result. For example when we want to display additional information of an asset, we should query the datasource only if there is an asset selected.

In this release we have introduced a new velocity function: $query.abort() that you can call to abort the execution of a query.

The advantages are twofold:

  • Reduces the load on the external datasource by avoiding unnecessary calls.
  • Improves user experience as forms will download faster.

Cleaning house

We also made some improvements under the hood aimed to improve the performance of nFeed:

  • We removed the JSON post processing from the cache. Now if two fields execute the same query on a JSON datasource, they will share the same cache even if the JSON post processing are different.
  • We switched from our home-made cache implementation to the Atlassian cache. There won’t be any functional impact on the product, but it will increase performance and reduce memory load.

And that is not all! To illustrate these new features we have published a new tutorial in the nFeed documentation: Easily answer users’ questions by browsing and sending knowledge base articles from JIRA.

nfeed