New Field type where options can only be enabled/disabled, not edited, added or deleted by project admins

[Jeffrey Thornsen]

Hello,

We have a bit of a strange use-case and I was wondering if the Project Specific field plugin might be updated to support us.

What we want to do is create a single-select (or multi-select) custom field where the options in the list are defined only by the Global Jira Admin (like a regular select list), and the Project Administrators (via the project-specific UI) can only enable and disable the options (as defined by the global admins) in the list, and not edit any of the text of those options (or add/delete new options to the list).

The reason for this is that we need to have strict control over the exact verbiage used for the options, so we want to deny Project Administrators from editing the actual options in the list. The Project Administrators should only be allowed to enable and disable the options available within the project.

Is there any way to make a new Custom Field type that behaves this way and can re-use the existing Project-Specific UI in some way?

‌

I know that we can do this using a standard Select List in Jira along with a multitude of Field Configurations (where the desired combination of options are enabled/disabled), but this still means Project Administrators need to coordinate with the Jira Administrators if they want to switch between contexts or change which options in their select list are enabled or disabled within their project.

[Holger Schimanski]

Dear Jeffrey, thanks for getting in contact and for providing this idea. I have to say this is quite special and I have not seen such a request before. After thinking about this a little I don’t think that I will implement this scenario.

Maybe as an alternative solution you give full permission to the project admins, but you establish a process to look and inspect the option values used by projects on a regular base.

‌

[Jeffrey Thornsen]

Thanks for the prompt reply. I’ll mark this as Resolved/Won’t Do.

We will probably stick with a standard Select List field for this.