SummarySystemField

Determines whether the field is available for bulk editing given the BulkEditBean.

Returns true if a call to removeValueFromIssueObject(com.atlassian.jira.issue.MutableIssue) will actually remove the value.

There a few different reasons why this method may return false:

• The OrderableField can sometimes remove the value, but it decides that it is not relevant for this Issue. eg: Security Level will ignore remove requests on a subtask, as the subtask Security is not set explicitly (it is always inherited from its parent issue).
• It may possible to remove this value, but the OrderableField does not actually do the job, it is done through some special mechanism. eg Attachments.
• This field is some special system field which it is invalid to remove. eg Project. In these cases calling removeValueFromIssueObject() would normally raise an UnsupportedOperationException.

The order in which to sort the field when it is sorted for the first time.

The value that should be set on the issue if the field is not shown for some reason.

For example: The user does not have permission to see the field, or the field is not part of the create screen.

Return The default data for this system field. May be null if there is no default.

Return a list of Lucene SortFields to be used for sorting search results.

Using this method allows the field to specify the most performant way to perform a search. If a field can be sorted directly using the term in the index then this should just return a singleton list with the sort field.

return Collections.singletonList(new SortField(fieldName, sortOrder));

The default implementation builds this using the FieldComparatorSource returned by getSortComparatorSource()

If you implement this method there is no need to implement getSortComparatorSource().

A sorter to be used when sorting columns in a table. This sort uses the Lucene Document Collection and is therefore a lot faster than sorting the issues in memory.

Gets the value stored for this field on the provided issue.

Defines if a field determines itself as renderable. This is needed because of the way that customfields are implemented. Since all the real work is done in CustomFieldTypes, if we want to treat system fields and custom fields the same way in the renderers then all custom fields must implement this interface. We therefore provide this method so that the CustomFieldImpl can delegate to the CustomFieldTypes to determine if a given custom field is renderable.

Tests field specific way to determine if it should be shown or not.

Removes the field value from the given MutableIssue object.

Note that this operation does not actually persist the change, it just clears the value from the given Issue object. The caller will still need to call #updateValue() in order to persist the change.

Some Fields may choose to quietly ignore this request. eg The SecurityLevel Field will not remove Security Level from subtasks because the subtask must always take the Security Level of its parent issue.

Record the value on the issue (not saving it to the database, see updateValue).

validate the field value