* *Issue-relation* added: _Related to Feature #1767_
--------------------------------------------------------------------------------
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_.
--------------------------------------------------------------------------------
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).
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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).
--------------------------------------------------------------------------------
We have exactly the same issue (see "help request":http://www.redmine.org/boards/2/topics/11996).
Currently, we are editing the DB for overcoming this problem (custom filed with same name in different projects).
--------------------------------------------------------------------------------
+1

Custom field values for lists really shouldn't be an administrator task. They may change to often.
--------------------------------------------------------------------------------
This issue is propably contained in #1853 as well.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
+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.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
+1 as well.
We have list as custom field and we need different default values for different projects.
--------------------------------------------------------------------------------
+1 as well
--------------------------------------------------------------------------------
+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.
--------------------------------------------------------------------------------
+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

--------------------------------------------------------------------------------
+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.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
+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

--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
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. =)
--------------------------------------------------------------------------------
+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)

--------------------------------------------------------------------------------
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 :)
--------------------------------------------------------------------------------
Plugin makes 'Spent time' custom fields configurable on project - tracker
https://github.com/rpc1/time_entry_cf_binder

--------------------------------------------------------------------------------
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.

--------------------------------------------------------------------------------
+1
this would be very nice!
--------------------------------------------------------------------------------
+1
I also need this feature
--------------------------------------------------------------------------------

relates,New,1767,Make spent time - & project custom fields configurable/switchable per project
relates,New,4015,Make app settings overridable at project level
relates,New,10027,Make "Required" overridable per-project
relates,New,1853,Make Projects truly independent of each other
duplicates,Closed,16383,Custom field // a LIST with values by projects
duplicates,Closed,18425,the custom fields can be defined in the project