FINAL BEHAVIOR:

1. For fields with options (epic status):
If everything is 1:1 like the original configuration, then lock the field, otherwise don't lock the field

1a. Unless there is all projects/appropriate issues field scheme with ZERO options in there. In that case we will just add the options.

1b. Unless there are no schemes, in which case we introduce our own.

2. For fields without option fix up the contexts then lock the field

3. do NOT fix up field names/descriptions for any of the fields

3a. But fix the searcher.

4. for the Rank field, change managed level to "admin" (field creation) plus a message that the field should normally not be created as GH creates the field

5. The default rank field should be fixed up in context and then locked.

In JIRA 5.2 there is a new API around Managed Configuration Items. This allows a plugin to specify that instances of custom fields, and custom field types, are "managed" by the plugin and should not be modified/created by administrators.

Fields to be restricted (no edit, no create):
All Issue Types/Global Context:

• Epic Link(show)
• Sprint(show)
• Rank(show)

Epics only/Global Context

• Epic Status(show)
• Epic Name(show/require/renderer - default text)
• Epic Color(show)

We must also ensure that existing fields are in the correct configuration before locking them down.

Development Notes

Q: Is fixVersions one of these since we rely on it for release planning?
A: No - it is a system field provided by JIRA and therefore should be locked by definition.

Q: Rank field?
A: Also fix/lock the default rank field