Feature #5127
Custom Fields to be configurable on 'per project' basis
| Status: | New | Start date: | 2010-03-19 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | Custom fields | |||
| Target version: | - | |||
| Resolution: |
Description
I think, it would be very useful to change setting of a Custom field on a 'per project basis'.
This mainly relates to 'List' type of fields. What happens is that the same type of field might have different possible values in different projects.
Right now this means that I either have to list values possible for all projects (which is not a good idea) or create different custom fields for every project (but then I cannot really filter across different projects and always have to create a custom name for the field in every project...)
Related issues
History
#1 Updated by Mischa The Evil about 2 years ago
- Category set to Custom fields
- Issue-relation added: Related to Feature #1767
#2 Updated by Brandon Bonds almost 2 years ago
Seconded. Here's a good example situation:
A project sponsor wants a custom field named exactly Defect Cause, and supplies a precise list of options. But there is already have a field named Defect Cause for all the other projects, approved by other sponsors. So I'm stuck having to OK the change of my original field because Redmine doesn't allow different custom fields with the same name, even if they are never used on the same project.
#3 Updated by André Jonsson almost 2 years ago
Thirded :)
Another, probably common, is "version".
Could, in theory, be simply a text field, but it's not uncommon to have specific versions. As I see it, this would be the same kind of configurable as now-existing "Versions" and "Categories".
When an issue is reported, this issue will have to be associated with a specific version. This is currently not possible and this information will have to be put in the description field. This is sub-optimal as it is not searchable (or groupable).
#4 Updated by André Jonsson almost 2 years ago
André Jonsson wrote:
(some stuff)
Actually, I take my example back... I realised my scenario is already supported by the existing "Versions" (that I also mentioned) ;)
But I still think this would be a nice feature to have for other purposes.
#5 Updated by André Jonsson almost 2 years ago
Ok, back again :)
Maybe I can rephrase my scenario a bit: If there was an issue field "Reported version" in addition to the existing "Target version". Both being of the type Versions so that they both show content from the defined Versions data, but can be set to two different values, which is probably most common (reported in version A, but targeted to be fixed in version B).
#6 Updated by Christian Hausleitner over 1 year ago
We have exactly the same issue (see help request).
Currently, we are editing the DB for overcoming this problem (custom filed with same name in different projects).
#7 Updated by Robert Schneider about 1 year ago
+1
Custom field values for lists really shouldn't be an administrator task. They may change to often.
#8 Updated by Robert Schneider about 1 year ago
This issue is propably contained in #1853 as well.