Feature #5127


Custom Fields to be configurable on 'per project' basis

Added by Vladimir Dzalbo almost 14 years ago. Updated 8 months ago.

Custom fields
Target version:
Start date:
Due date:
% Done:


Estimated time:


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

Related to Redmine - Feature #1767: Make spent time - & project custom fields configurable/switchable per projectNew2008-08-11

Related to Redmine - Feature #4015: Make app settings overridable at project levelNew2009-10-10

Related to Redmine - Feature #10027: Make "Required" overridable per-projectNew

Related to Redmine - Feature #1853: Make Projects truly independent of each otherNew2008-09-04

Has duplicate Redmine - Feature #16383: Custom field // a LIST with values by projectsClosed

Has duplicate Redmine - Feature #18425: the custom fields can be defined in the projectClosed

Actions #1

Updated by Mischa The Evil almost 14 years ago

  • Category set to Custom fields
  • Issue-relation added: Related to Feature #1767
Actions #2

Updated by Brandon Bonds over 13 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.

Actions #3

Updated by André Jonsson over 13 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).

Actions #4

Updated by André Jonsson over 13 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.

Actions #5

Updated by André Jonsson over 13 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).

Actions #6

Updated by Christian Hausleitner over 13 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).

Actions #7

Updated by Robert Schneider almost 13 years ago


Custom field values for lists really shouldn't be an administrator task. They may change to often.

Actions #8

Updated by Robert Schneider almost 13 years ago

This issue is propably contained in #1853 as well.

Actions #9

Updated by Dipan Mehta almost 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.

Actions #10

Updated by joseph john over 10 years ago

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.

Actions #11

Updated by Christophe SERMET-MAGDELAIN over 10 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.

Actions #12

Updated by Andrey Shevchenko about 10 years ago

+1 as well.
We have list as custom field and we need different default values for different projects.

Actions #13

Updated by Nicholas Ustinov about 10 years ago

+1 as well

Actions #14

Updated by Robert Schneider almost 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.

Actions #15

Updated by Samuel Samfra almost 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

Actions #16

Updated by Stéphane Dubois almost 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.

Actions #17

Updated by Toshi MARUYAMA almost 10 years ago

  • Has duplicate Feature #16383: Custom field // a LIST with values by projects added
Actions #18

Updated by redmineservices . over 9 years ago



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)

Actions #19

Updated by Omer Arslan about 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.

Actions #20

Updated by Toshi MARUYAMA about 9 years ago

  • Has duplicate Feature #18425: the custom fields can be defined in the project added
Actions #21

Updated by Victor Campos over 8 years ago

Javi Ferrer wrote:



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)

Javi Ferrer, I forked your plugin to make it work in redmine 3.1. =)

Actions #22

Updated by Adrian H. over 7 years ago


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)

Actions #23

Updated by Matthias Hahn over 6 years ago

I could not find the fork of Viktor of Javi´s Plugin.
Where can I find it? Thanks!

edit: ... it´s in the repo :)

Actions #24

Updated by Dmitry GLushchikov about 6 years ago

Plugin makes 'Spent time' custom fields configurable on project - tracker

Actions #25

Updated by VD DV about 5 years ago

This issue is related to #21149 and #25043. There is one (of many) point of view how that functionality can be solved.
Still hoping that this functionality will be included to Redmine in near future.

Actions #26

Updated by hsc solutions almost 4 years ago

this would be very nice!

Actions #27

Updated by Yaroslav Matsera over 2 years ago

I also need this feature

Actions #28

Updated by Jérôme Gallot 8 months ago

best idea ever ;)


Also available in: Atom PDF