Issue fields requires some re-design for greater flexibility.

For example, in migrating the field 'Attachment' to be an actual issue field, there are a number of areas that prove problematic and restrictive.

(The migration of the 'Attachment' field to an actual issue field allows greater user control as with all issue fields - e.g. in this case, the field can be hidden, further description added and it can be reordered.)

The 'Attachment' field is unique in that we wish it be 'hideable', not 'requireable' and not required by default - i.e. it can never be set to be required - it is always optional.

At present, the current design enforces that an issue field is either required by default or requirable.

Checks if a field is 'requirable' are used throughout - and this determines the fields requirability - both in the UI and the system code.

Further, a second check is made against a collection of 'required' fields that all 'requireable' fields are added to - this check appears to be redundant.

The hierarchy of fields could also be re-designed. With the introduction of a field that is hideable, not required and not requireable - it would seem beneficial to separate the HideableField interface from the RequireableField interface. This could lead to the introduction of the NavigableHideableFieldImpl and NavigableHideableRequireableFieldImpl classes.