Post functions

nFeed extends JIRA workflows capabilities with two post-functions. This page explains how to configure them



They are available in the post-functions list when updating a workflow transition. 



Post function : Set a field value

Usage

This function allows you to select a set of nFeed fields whose value(s) will be updated when the transition is executed.

There are two cases, depending whether your field is a single or multiple value field.

Single value nFeed field

When run, the post function will update the field with the first available value in the values list. Exactly as if someone would edit the issue and select the first value available for the field.

If there is no available value (the edit query evaluates to empty), then the field is cleared.

Multiple value nFeed field

When run, the post function will update the field with all available values in the values list. Exactly as if someone would edit the issue and select all the values proposed for the field. This could have an impact on the performances of your application.

If there is no available value (the edit query evaluates to empty), then the field is cleared.

Configuration

When you add this post function to your workflow transition, you will need to select one or more fields to update.




Once saved, the function is displayed with its fields list.


Post function : Copy nFeed display to another field

Usage

This function allows you to select a nFeed standard field whose display will be copied to another issue field.

The display value is the formatted value displayed in the issue view.

Target issue field

The list of issue fields available as target is limited to the following types :

Field typeAvailable fields
Text fields

Text system fields (summary, description and environment)

Text custom fields (read-only, single and multi line)

Date and date time fields

Due date system field

Date and date time custom fields

User fields

Assignee and reporter system field

User picker custom fields (single and multi)

Number fieldsNumber custom field

Content adaptation

Here is a list of how nFeed display is adapted before the target field can be updated:


Field typeWhat is copiedHow is content adaptedMultiple vs. single
Single line text fieldsThe whole nFeed display including header and footer


Line breaks are filtered and replaced with coma (,) N/A
Multi line text fieldsThe whole nFeed display including header and footerNo adaptationN/A
Date and date time fieldsHeader and footer are ignored. Every display line is adapted


Every display line is tested against Jira date patterns and converted before being inserted.

Values not recognised as Dates are ignored.

If the target is a single field and the display contains many lines, only the first one is taken into account. Additionnal lines are ignored
User fieldsHeader and footer are ignored. Every display line is adapted


Every display line is matched against available user keys before update. Values that do not correspond to valid users are ignored.Same as above
Number fieldsHeader and footer are ignored. Every display line is adapted

Every display line is parsed to match a number (floating point). 

Values that do no match are ignored.

Spaces in values are ignored.

Same as above


Configuration

When you add this post function to your workflow transition, you will need to select a nFeed standard field as source and another issue field as target.


Post function : Copy nFeed key to another field

Usage

This function allows you to select a nFeed standard field whose programmatic content (keys list) will be copied to another issue field.

The key in nFeed field is the identifier in the field administration (see Edit view for details about the key definition).

Target issue field

The list of issue fields available as target is limited to the following types :

Field typeAvailable fields
Text fields

Text system fields (summary, description and environment)

Text custom fields (read-only, single and multi line)

Date and date time fields

Due date system field

Date and date time custom fields

User fields

Assignee and reporter system field

User picker custom fields (single and multi)

Number fieldsNumber custom field
nFeed fieldsnFeed custom field (all types)

Key adaptation

Here is a list of how nFeed keys list is adapted before the target field can be updated:


Field typeHow is key adaptedMultiple vs. single
Single line text fieldsList of keys are joined with coma (,) N/A
Multi line text fieldsEvery key in the list appear in a separate lineN/A
Date and date time fields

Every key is tested against Jira date patterns and converted before being inserted.

Values not recognised as Dates are ignored.

If the target is a single field and the nFeed field contains many keys, only the first one is taken into account. Additionnal keys are ignored
User fieldsEvery key is matched against available user keys before update. Values that do not correspond to valid users are ignored.Same as above
Number fields

Every key is parsed to match a number (floating point). 

Values that do no match are ignored.

Spaces in values are ignored.

Same as above
nFeed fieldsNo adaptation. The keys list is copied to the other nFeed fieldN/A


Configuration

When you add this post function to your workflow transition, you will need to select a nFeed standard field as source and another issue field as target.


Post function : Add a comment

Usage

This function allows you to add a comment to the transitionned issue. The comment content will depend on the selected nFeed field.

Configuration

When you add this post function to your workflow transition, you will be proposed the following options:



  • field: a nFeed field which will be evaluated and used as comment content.
  • header: Free text concatenated in the comment content before the field. If a text is present in the header, a new line will be appended after it.
  • footer: Free text concatenated in the comment content after the field. If a text is present in the footer, a new line will be appended before it.


Once saved, the post function should display like this:



Comment content

The final comment content will be obtained by concatenating the header, then the nFeed field evaluation, then the footer.

The nFeed field is evaluated thanks to the 'Post function comment' display view in nFeed field administration:


If this view is not defined, then the standard issue view will be used. Then if the issue view is not defined, the edit display will be used.

Special cases

The field is empty or the view evaluation is empty

When the field evaluates to the empty string, then the comment will still be added using the header and footer defined.

The field view evaluates to more than one line (view query returns many lines)

When the field evaluates to many lines (in case you override the view query), then every line is added, separated by a new line.

Limitations

As these function run in the context of a transition, there are a few things to keep in mind:

Create issue transition

When used in the Create issue transition, nFeed post functions must be placed after the Creates the issue originally post function :



Velocity context

The  variables defined in Velocity context can be affected :

  • $userInput is not available
  • $currentUser and $currentUserLocale will be based on the user running the transition. This is not an issue during normal operation, but this is to be considered when transition are run automatically by a script of an add-on