Managing context lists at the project level

[Ed Snow]

When testing we have a collection of version numbers (hardware rev, firmware rev, software rev, spec rev, build lot).  Right now the only way I can provide a list of valid choices is to setup context lists by project.  While this works there are two things that would improve life quite a bit.  

First, context lists can only be edited with admin rights, not project specific rights. So the project admin has to issue a request for a system admin to have new versions added.  If there is a way to make this accessible at the project admin level that would help alot.

Second, is there a way to setup a select field that allow you to enter a new value, or select one that has already been referenced at the project level?  This would allow new versions to be entered without waiting for any admin.  We are not concerned about data validation; it would be caught quickly for other reasons and the benefit of not having to request a new context value would be huge.

I did look at project versions, but that seemed to only have one version list, and I need multiple.

[Nic Brough -Adaptavist-]

No the field lists for most fields is controlled by the administrators.  Versions and components are controlled by project admins, and that's probably what you should be using for your versions.

There is one type of field you can add items to on-the-fly - labels.

[Paul Alexander]

But to be clear for Ed, versions and components may also be added on-the-fly (from a screen for instance) if you are a Project Administrator.

[Ed Snow]

Thanks for pointing that out.  It has the right behavior; if only I could create custom version fields.

Is there any trick to use Versions for more than one thing?  I'm thinking maybe prefix and you have to select from the combined list?

I see version picker in the custom field list; I assume that just referencing the singular version list.