Feature #5127

Custom Fields to be configurable on 'per project' basis

Added by Vladimir Dzalbo over 9 years ago. Updated 7 months ago.

Status:NewStart date:2010-03-19
Priority:NormalDue 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

Related to Redmine - Feature #1767: Make spent time - & project custom fields configurable/sw... New 2008-08-11
Related to Redmine - Feature #4015: Make app settings overridable at project level New 2009-10-10
Related to Redmine - Feature #10027: Make "Required" overridable per-project New
Related to Redmine - Feature #1853: Make Projects truly independent of each other New 2008-09-04
Duplicated by Redmine - Feature #16383: Custom field // a LIST with values by projects Closed
Duplicated by Redmine - Feature #18425: the custom fields can be defined in the project Closed

History

#1 Updated by Mischa The Evil over 9 years ago

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

#2 Updated by Brandon Bonds about 9 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 9 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 9 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 9 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 almost 9 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).

#7 Updated by Robert Schneider about 8 years 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 8 years ago

This issue is propably contained in #1853 as well.

#9 Updated by Dipan Mehta over 6 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.

#10 Updated by joseph john almost 6 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.

#11 Updated by Christophe SERMET-MAGDELAIN almost 6 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.

#12 Updated by Andrey Shevchenko over 5 years ago

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

#13 Updated by Nicholas Ustinov over 5 years ago

+1 as well

#14 Updated by Robert Schneider over 5 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.

#15 Updated by Samuel Samfra over 5 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

#16 Updated by Stéphane Dubois over 5 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.

#17 Updated by Toshi MARUYAMA over 5 years ago

  • Duplicated by Feature #16383: Custom field // a LIST with values by projects added

#18 Updated by Javier F almost 5 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

#19 Updated by Omer Arslan over 4 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.

#20 Updated by Toshi MARUYAMA over 4 years ago

  • Duplicated by Feature #18425: the custom fields can be defined in the project added

#21 Updated by Victor Campos almost 4 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. =)

#22 Updated by Adrian H. over 2 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)

#23 Updated by Matthias Hahn about 2 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 :)

#24 Updated by Dmitry GLushchikov over 1 year ago

Plugin makes 'Spent time' custom fields configurable on project - tracker
https://github.com/rpc1/time_entry_cf_binder

#25 Updated by VD DV 7 months 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.

Also available in: Atom PDF