Feature #5127
openCustom Fields to be configurable on 'per project' basis
0%
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
Updated by Mischa The Evil over 14 years ago
- Category set to Custom fields
- Issue-relation added: Related to Feature #1767
Updated by Brandon Bonds about 14 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.
Updated by André Jonsson about 14 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).
Updated by André Jonsson about 14 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.
Updated by André Jonsson about 14 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).
Updated by Christian Hausleitner almost 14 years 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).
Updated by Robert Schneider over 13 years ago
+1
Custom field values for lists really shouldn't be an administrator task. They may change to often.
Updated by Robert Schneider over 13 years ago
This issue is propably contained in #1853 as well.
Updated by Dipan Mehta over 11 years ago
If you see the entire fields permissions work flow - which allows { per-tracker X per-status X per-role } now repeat this per project (with 100 projects!) it would be too heavy!
Instead of having to have custom field configuration 'per project' it is better to 'override' for specific projects per say.
This issue should follow the approach #4015 rather than #1853
Please add related #4015.
Updated by joseph john about 11 years ago
+1
This is one of the biggest trouble we face. We have around 10 different projects and there are few field values which make sense for different project but the values are project specific.
I was looking forward for this implementation in the latest release.
Updated by Christophe SERMET-MAGDELAIN about 11 years ago
I'm starting to bring our people to work with Redmine and one of the first need I encounter is exactly this feature request.
On each project we have ussue categories and versions to attach data for each issue. Theses two predefined fields are usefull but we'd like to attach more information to be more accurate when organizing, filtering issues.
For example, we need target version but we need tested version too. We need to add information about where the issue takes place considering our application content structure, and so on.
All these may be done with custom fields but as we need it to be predefined value lists, with different values for each project but the same field name... exactly the same trouble as described here.
The #4015 approach is a more generic approach but I guess it could be a hard one as far as the whole workflow is concerned.
Updated by Andrey Shevchenko over 10 years ago
+1 as well.
We have list as custom field and we need different default values for different projects.
Updated by Robert Schneider over 10 years ago
+1 just to make it not forgotton.
If I'm not wrong we could distinguish: CF could be like the categories - the field and its values are defined within the project. Or the field is globally but the values are per-project defined. I don't know which one would be easier to implement.
Updated by Samuel Samfra over 10 years ago
+1 ... I need exactly the same thing. We call this "the breakdown" (either it is GLOBAL or PROJECT)
Advantages to have one attribute but values by project is that we can manage the rights for all projects (otherwise we must add and place the field project by project)
To create one attribute for each project solves the problem BUT we can't call it with the same name...
The best example is the "CATEGORY" field... I would dream to use the same behavior for customized attributes : User can add their own values if the value is missing, etc.. etc...
thank you
Updated by Stéphane Dubois over 10 years ago
+1 I also need this.
I would dream to be able to create a custom field of type Project list. Then, in the project settings, I would see one tab per Project list custom field, allowing the project manager to define the values of each list.
Updated by Toshi MARUYAMA over 10 years ago
- Has duplicate Feature #16383: Custom field // a LIST with values by projects added
Updated by redmineservices . almost 10 years ago
+1
Hi,
I've just published a plugin with this feature. Works on redmine 2.3, 2.4 and 2.5 (at the moment, only works with issues custom fields)
https://github.com/javiferrer/redmine_custom_values_projects
Updated by Omer Arslan over 9 years ago
If Redmine is wanted to be referred by a free project management tool, it must give permission to create custom fields per project as in the issues. By the way, great thanks to the developers who contributed to redmine app.
Updated by Toshi MARUYAMA over 9 years ago
- Has duplicate Feature #18425: the custom fields can be defined in the project added
Updated by Victor Campos almost 9 years ago
Javi Ferrer wrote:
+1
Hi,
I've just published a plugin with this feature. Works on redmine 2.3, 2.4 and 2.5 (at the moment, only works with issues custom fields)
https://github.com/javiferrer/redmine_custom_values_projects
Javi Ferrer, I forked your plugin to make it work in redmine 3.1. =)
Updated by Adrian H. almost 8 years ago
+1
We are experiencing the same requirement here with a similar use case:
The Custom Field is defined as List Box; the entries (including a default value) must be configurable on project scope.
Our "solution" so far is using a text field, which leaves us without default value and error-prone.
(Victor's fork of Javi's plugin, which seems to work with 3.3, does not treat to the default value part)
Updated by Matthias Hahn about 7 years ago
I could not find the fork of Viktor of Javi´s Plugin.
Where can I find it? Thanks!
edit: https://github.com/javiferrer/redmine_custom_values_projects/network ... it´s in the repo :)
Updated by Dmitry GLushchikov over 6 years ago
Plugin makes 'Spent time' custom fields configurable on project - tracker
https://github.com/rpc1/time_entry_cf_binder