If plugins aren't an option you can give them admin access and instruct them to only use it for project creation with instructions if they do anything else it is 2 days off without pay.
I also strongly advise you 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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.