How to know who added a value to a custom field?

[Javier Gallegos]

I would like to know if there is a way to know who added new values under a Select List (single choice) custom field? I tried checking Audit Log but I can see only when new fields are created, I can't find the history for actual values under the field

[Joe Pitt · Accepted solution]

No. 

Put JIRA under CR

 I STRONGLY suggest you treat JIRA like a production system, put it under change control (CR), and track all requests for any updates, especially new projects, new custom fields, changes in any of the schemes, etc. That way at least the reporter will know when the actions happen and you'll have a audit trail. I've worked many similar tools to JIRA and too many times no one knows anything about why they are configured why they are because there is no requirements or CR. Things are just done based on emails that have disappeared and hallway or lunch conversations.  

If you don't already have a separate change control tool create a JIRA project. I use a basic workflow with a few custom issue types:

Custom field: with a select list of create, update. The description would be to create a new field or modify a current select list, buttons, etc. of a current one

Create Project: I would have text fields for issue types, custom fields, select list/values, per issue types

New Issue Type: description would include all fields and workflow desired.

Workflow: Select list of Create, update, delete. Description of what needed.

Other: Select list of Notification Scheme, permission scheme, field configuration, other

This should get you started. If you aren't familiar with your CR process there should be a configuration management person to talk to.

The goal is to manage what you do and be able to track who asked for what. For instance, if someone wants a new custom field you want to check to see if there already is one you can use that they don't know about. JIRA will let you have multiple custom fields with the same name, which will just confuse you.

[Javier Gallegos]

Thanks for the information, this has been really useful! I'll follow your recommendations

[Joe Pitt]

You're welcome 

Here is another potential 'got ya' to avoid

Do not delete issues. When you delete it is GONE. Hardly a week goes by without someone wanting to restore an issue. Deleting issues will come back and bite you when it is the most inconvenient. I suggest closing with a resolution value of Deleted anything you want to delete. I implement a special transition only the project lead can execute and it requires filling in a reason field from a select list (such as entered in error, OBE, Duplicate, Other) and explanation text.

Another option is to move them to a historical project where no one has access. If needed the JIRA admin can give access.

Deleting issues destroys historical data. Missing issue numbers will eventually cause a question about what it was and why was it deleted even if it was done properly. Missing data always brings in the question of people hiding something that may have looked bad.

The only viable way to restore an issue is to create a new instance of JIRA and restore a backup that has the issues. Then export them to a csv file and import them to your production instance. You will lose the history.

None of my users have delete permission.

If you insist on deleting issues you need the delete issue permission