ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Multiselect custom fields (Feature #141)

Added by David Alves at 2011-02-04 01:10 pm. Updated at 2013-01-31 09:37 pm.

Status:Open Start date:2011-02-04
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:Custom Fields
Target version:-
Remote issue URL:http://www.redmine.org/issues/1189 Affected version:

Description

Hello,

There is a long awaited feature for redmine that many people would like to see in ChiliProject, it's a 3 years old issue on the redmine official tracker.
The objective is to allow multiselect option for Custom Fields. We are using it extensively but in 3 years, the patch has never made it to upstream.
That would be awesome to have this feature upstream on ChiliProject

The Redmine issue is here : http://www.redmine.org/issues/1189

Thanks you.
David.

History

#1
Updated by Holger Just at 2011-02-04 03:17 pm

  • (deleted custom field) set to http://www.redmine.org/issues/1189
  • Category set to Custom Fields

#2
Updated by Felix Schäfer at 2011-02-14 08:21 am

I had a look at the patch, and I'm a little underwhelmed. Currently CustomField has_many CustomValues and Customizable has_many CustomValues, so in essence CutsomValues is a fat join table between customizables and custom_fields. The patch introduces a new type of CustomValue that wraps an array and tries to be smart about saving the individual values to single custom fields. This does make searching a tad easier, but feels very brittle to me, as well as a problem that already has a solution in the form of serialization.

So I guess what I'm saying is that I'd rather have CustomValue accept multiple values than try to emulate that behavior by storing each selected value in a separate CustomValue. Thoughts?

(and while we're at it: do we have something like a "needs a design/implementation decision" state?)

#3
Updated by Eric Davis at 2011-02-14 11:02 pm

Felix:

I remember that patch and it felt a tad complex. Especially since Custom Fields are already pretty complex.

I wonder if we could just serialize the custom value's value? If it stores YAML in the database, then search can still pick it up (it's just plain text). (e.g. ---\n-- "Foo"\n-- "Bar" is close to the raw values)

#5
Updated by Steffen Gebert at 2011-04-01 05:46 pm

I'd love to have this possibility, too! Optimal would be to have it connected versions (e.g. affected versions/branches, fixed in version, etc).

#6
Updated by Matteo Giaccone at 2011-08-31 10:23 am

Hi all, i tried to patch the last version of Redmine (http://www.redmine.org/issues/1189#note-66) and i'm interested too in this feature, let me know if i can be of any help.

#7
Updated by Brian Jacobi at 2011-12-09 09:48 pm

+1 we continue to have use cases come up that could utilize multi-select fields.

#8
Updated by Kurt Klinner at 2012-01-30 07:27 am

we would love to have that feature.
Our old system supported multi select cusom fields, so our customers are used to have that feature.

#9
Updated by David Alves at 2012-01-30 08:20 pm

the upstream redmine has now support for multiselect custom fields.

http://www.redmine.org/issues/1189

Thanks !

This ticket may be closed.

#10
Updated by David Prothero at 2012-10-26 08:32 pm

Just curious if this is implemented in redmine, if/when we can expect to see it come down to ChiliProject?

#11
Updated by Felix Schäfer at 2013-01-31 09:37 pm

David Prothero wrote:

Just curious if this is implemented in redmine, if/when we can expect to see it come down to ChiliProject?

We don't follow the development of Redmine anymore, so this would probably be integrated if someone adapted the change to ChiliProject and made a pull request/patch.

Also available in: Atom PDF