Feature #1189
closedMultiselect custom fields
0%
Description
My project manager wants to be able to assign an issue to multiple target versions (customer requirements - they are fine with backporting a monstrous changeset, but not with "updating" - please don't ask...). I though I could simulate this with categories or custom fields, but none of them allows choosing multiple values at once.
So, the idea is: add a new type of custom field, similar to list but allowing multiple choice values. (Or, ideally, allow multiselect for 'Target version', but I suppose this is not possible?)
Files
Related issues
Updated by Carl Nygard over 16 years ago
Why not just copy the issue and assign it to another milestone? The issues can be related to each other. After all, applying a patch to a separate version really is a separate issue to be tackled. Would that solve your problem?
Updated by Jason Trahan over 16 years ago
I also second this feature. Mainly for custom fields. Our management team would like us to assign multiple values for a given field. They would also like the ability to select multiple catagories for example.
Another item similar to this would be related projects. So for example if we create a ticket under our main project. They would like us to associate the sub projects that the ticket applies. Basically the same concept as relating a ticket, but allowing related projects so they they can group together. For example if there is a bug in 1 project, that bug may affect other projects and they would like to have that association so that they know which projects are affected by that bug.
Updated by Maxim Krušina over 16 years ago
IMHO It's not good idea. Issue should be assigned only to one version/milestone at the time. Otherwise it will mess up time estimates and other statisics. If you set estimated time for a shared issue for example to 40 hours and asign it to two versions/milestones, you will see you need 2x 40 hours of homanwork to fix it, which is nonsense. The better idea IMHO is to create just second issue and link t to the original issue, so you can trac issue in both versions/milestones at the same time. Also, sometimes you see that issue can't be finished in time to be included in version/milestone, so you simply reassign it to the second version/milestone, and all times are autimaticaly recalculated, ok?
Updated by Jason Trahan over 16 years ago
That's understandable from that perspective. But in our case we have custom fields that we need to be able to select multiple values for. I'm not worried about time management. This is mainly so we can assign various things that management wants us to group together.
Updated by Kurt Hilsmeier over 16 years ago
My organization has a similar need for multiselect custom fields. Bugzilla offers such a capability (while lacking many nice features of Redmine). Looks like a multiselect field is supported to some extent by this interface as searching can be done on one or more trackers...it's just not supported as a custom field.
Updated by Wladmir Kocerka about 16 years ago
This would allow cutting the number of duplicated features or bugs. Instead of duplicating a request, just create a list custom field with your customers and assign multiple to the same request.
Updated by Jan Ivar Beddari about 16 years ago
+1
In some of my use cases for Redmine a multiselect custom field would be very helpful, for example when
- .. tracking changes. One issue could impact more than one entity. Easy example, VPN and firewall configuration, track what firewalls a rule change involves.
- .. adding alternate email-addresses. In one setup I have an external script that queries the db and feeds email to Redmine, very specific to that system. It would be helpful to have a custom field per user that would hold all the different email adresses I need. Right now I need to add them as a delimited string which is more cumbersome.
Updated by Jean-Baptiste Barth almost 16 years ago
- File 102_add_custom_fields_multi.rb added
- File multi_values.diff added
Here is a new migration and a patch which let you choose multiple values in issue custom fields, if you checked the "allow multiple choices" option in the field settings. You may apply it to trunk version (r2065 today), and run a db:migrate after integrating them.
Please consider it is totally experimental : even if all test passed for me, I'm not sure it won't break anything, and I feel like these modifications are a bit "hacky", but I didn't manage to add it another way. Any criticism or suggestion is welcome :-)
Updated by Roman Belyakov over 15 years ago
- File multi_values_tracker_bug.diff added
Jean-Baptiste Barth wrote:
Here is a new migration and a patch which let you choose multiple values in issue custom fields, if you checked the "allow multiple choices" option in the field settings. You may apply it to trunk version (r2065 today), and run a db:migrate after integrating them.
Please consider it is totally experimental : even if all test passed for me, I'm not sure it won't break anything, and I feel like these modifications are a bit "hacky", but I didn't manage to add it another way. Any criticism or suggestion is welcome :-)
There is a bug in new issue creating when I try to select a tracker which does not have multiselect custom fields:
NoMethodError (You have a nil object when you didn't expect it! The error occurred while evaluating nil.custom_field): /vendor/plugins/acts_as_customizable/lib/acts_as_customizable.rb:86:in `custom_multi_values=' /vendor/plugins/acts_as_customizable/lib/acts_as_customizable.rb:76:in `each' /vendor/plugins/acts_as_customizable/lib/acts_as_customizable.rb:76:in `custom_multi_values='
Attached patch fixes this problem. You should apply this patch after multi_values.diff
Updated by Jean-Baptiste Barth over 15 years ago
Thanks a lot, I'll try this.. In fact I don't think my patch is a real good solution ; I was told it puts multiple objects in one line of Journal, so it breaks future features which would parse journal entries and do researchs on it for instance... and I don't have enough time to work on this because of other projects. I think this would be a cool feature but it may imply deeper modifications..
Updated by takuro monji over 15 years ago
Hi, I want to change Issue tracking system from "JIRA " to "Redmine".
But our project manager also wants to be able to assign an issue to multiple target versions.
(because our project shares a lot of program modules in some projects.)
Could you include your patch in version 0.9 ?
Updated by Nelson LaQuet over 15 years ago
+1 for including this in 0.9
I would really like to apply this patch, but don't want to revert to r2065.
Updated by Diego Garber over 15 years ago
I second this feature. I created a custom field called Customer, to assign Issues to customer's requests and there are Issues requested by more than one customer, as a matter of fact those are naturally more prioritized.
Updated by Antoine Roux over 15 years ago
I would also like to allow multiple choice. We have issues that apply to hardware equipments. An issue may apply to multiple models of hardware, so that would really be a great improvement !
Updated by paulo jr over 15 years ago
I also would like to add a multi-values field to set a custom field called "Interested people", where I would select each one of the people who would be interested in some new feature or defect resolution, but who I would not like to add to my Redmine system (to avoid simple users to access the system), just to make me remember to keep these people up to date about changes.
Updated by Jean-Baptiste Barth over 15 years ago
After weeks of intensive tests (ahah), I don't think my patch is a good solution. There are problems mentionned above about future evolutions and journal parsing especially, but moreover, it is not really easy to use and not really stable. I think it would be better to implement the same behaviour as attached files, i.e. you don't have to erase/save a new list of items each time, you just add one or erase one step by step. Unfortunately I don't have much time to work on this (maybe in August ?). I don't think actual patch should be integrated to 0.9 (without saying there are no test to be sure it works well, brr!).
Updated by Mikhail Grinfeld about 15 years ago
I need this feature, too. +1 for including this feature in 0.9
Updated by Alex Last about 15 years ago
+1 we need this. is there a way to vote on issues instead of writing stupid "+1"? :)
Updated by ciaran jessup almost 15 years ago
ARgggh, completely missed this issue previously, I've also implemented this functionality over here: http://github.com/ciaranj/redmine/commit/90213d234e30d35b21de4977e47a957690450248 Although my patch also provides the ability to use multi-select fields as search filters, I guess I'll take a look at the above patches and see if I can throw mine away, could've saved myself a coupla hours work had I spotted this previously :(
Updated by Jean-Baptiste Barth almost 15 years ago
ciaran jessup wrote:
[...] could've saved myself a coupla hours work had I spotted this previously :(
Hi !
Don't think you've wasted your time, since :- I'm not even sure this patch works anymore
- it's not very easy to use every day with big lists (>20)
- the way multi values are added or deleted is not very cool
I'll take a look at your patch, I guess it will be better than mine.
This feature would be very interesting in my opinion, but there are 2 major problems which must be solved before implement it :- how do we store multiple values without breaking searchs, and journal future exploitation
- how do we organize the UI in such cases : html multi-select are very difficult to use ; maybe something like files attachments (one field by default, the other added with javascript, and baskets for deletion) ?
When I see Eric's plugins, I wonder if it's not possible to implement it as a plugin. Any suggestion on these 2 issues would help it progress I think.
Updated by ciaran jessup almost 15 years ago
Jean-Baptiste Barth wrote:
ciaran jessup wrote:
[...] could've saved myself a coupla hours work had I spotted this previously :(
Hi !
Don't think you've wasted your time, since :
- I'm not even sure this patch works anymore
- it's not very easy to use every day with big lists (>20)
- the way multi values are added or deleted is not very cool
I'll take a look at your patch, I guess it will be better than mine.
I'm not sure about that tbh :)
This feature would be very interesting in my opinion, but there are 2 major problems which must be solved before implement it :
- how do we store multiple values without breaking searchs, and journal future exploitation
I'm just storing the selected values as a comma-seperated-list (I need to validate to ensure no options are inputted that contain commas!)
I implemented the logical search operations (filter operations) in the patch and normal searching works as expected, with regards to journal future exploitation I'm not sure quite what is precluded by listing the new 'state', i.e. the new set of selected values each time, unless that 'exploitation' is happening in the DB it shouldn't be very challenging to work out what changed each time ?
- how do we organize the UI in such cases : html multi-select are very difficult to use ; maybe something like files attachments (one field by default, the other added with javascript, and baskets for deletion) ?
I did think about this, and this is do-able using a plugin, I had really wanted to do this with 0 db schema changes as I regularly merge the trunk head back into my branch and didn't want my schema to diverge.
When I see Eric's plugins, I wonder if it's not possible to implement it as a plugin. Any suggestion on these 2 issues would help it progress I think.
Most of my changes could probably be done in plugins, except for the part where I tweak the 'form' layout algorithm to allow for multi-line widgets :)
Hope this feedback helps
Updated by Roman Belyakov over 14 years ago
- File multi_values_safe_attributes.diff added
In current trunk (r3518) you can't save multiselect custom fields.
Patch attached.
Updated by David Teixeira over 14 years ago
Hello, Can this feature be reviewed by a team member to give a status ? Since it's a very important feature for a a lot of users.
Thanks you
Updated by Minjie Zhu over 14 years ago
First, thanx for Jean-Baptiste Barth, Roman Belyakov and others who give me a solution for this issue.
I merged the patches above and update it for r3739.
And I fixed some bugs
- Now you can duplicate or copy an issue with multiselect custom field, same as bulk copy.
- Now the journal is correctly created for multiselect custom field.
- Without this patch, the old value will be displayed in changed-to-value.
- A blank value will only be saved when only itself is selected.
- If any other none-blank value selected, the blank value will be removed. I think this will be more natural.
- Bulk edit doesn't work, and will just be ignored.
- If you set the multiselect cf to be used as a filter, the search result is not easy to understand.
- In Issues page, only the first value will be displayed in the issue list.
I am beginner of ruby and rails, so my code is very ugly and may be not safe. Hope some one will give a more smart and safe patch.
I does need this feature too, hope it will be import to the redmine.
Sorry for my poor English, and thanx for your read.
Updated by Eric Hollering over 14 years ago
I would love to see this feature rolled into the core product.
Updated by Jean-Baptiste Barth over 14 years ago
- File deleted (
102_add_custom_fields_multi.rb)
Updated by Jean-Baptiste Barth over 14 years ago
- File deleted (
multi_values.diff)
Updated by Jean-Baptiste Barth over 14 years ago
- File deleted (
multi_values_tracker_bug.diff)
Updated by Jean-Baptiste Barth over 14 years ago
- File deleted (
multi_values_safe_attributes.diff)
Updated by Jean-Baptiste Barth over 14 years ago
I removed other patches so that it's clearer which one should be applied. Didn't have the time to look at it for the moment. Anyway, I think the whole custom_fields database structure should be questionned if we integrate such a feature, so that we won't break journals and stop dumping yaml objects in the DB (it's really bad when you want to query on it, as I experience it these days...).
Updated by Eric Hollering over 14 years ago
I personally have no idea what is required to get this feature integrated to the core, but I think it is one of those flexibility enhancements that really add value to the product and make it much more attractive for users who have environment-specific needs (and who doesn't?) that must be considered when choosing products and processes.
Updated by anisa s. over 14 years ago
+1 for this feature.
Did you guys tried this patch with redmine 1.0.0? I need this feature so I downloaded the above patch but I get a redmine 500 error when I access or create a custom field.
I would really appreciate your help on the topic,
thnx in advance
Ani
Updated by ciaran jessup over 14 years ago
- File Updated-the-QueryColumn-code-to-be-allow_multi-aware.diff Updated-the-QueryColumn-code-to-be-allow_multi-aware.diff added
It works fine for me against the 1.0.0 tag in edavis10's github repository. I've also added a secondary patch to be applied on top of the existing patch that shows all the custom field values that are selected against a given issue when searching. Otherwise you get rows back with displayed values that do not neccessarily show one of the searched for values. A better patch would probably to just display the desired/searched-for value(s) but that information is not available to me [I don't think] at the point in time where the issues-list renderer asks the column to display its value.
Updated by ciaran jessup over 14 years ago
- File Updated-the-QueryColumn-code-to-be-allow_multi-aware-v2.diff Updated-the-QueryColumn-code-to-be-allow_multi-aware-v2.diff added
Ughh, noticed a stupid nil mistake in my previous patch, sorry ( this one supecedes Updated-the-QueryColumn-code-to-be-allow_multi-aware.diff ).
Updated by Eric Davis over 14 years ago
- Target version set to Unplanned backlogs
I would really like to see this as a feature in Redmine. I can think several cases where being able to select multiple values in a custom field would be useful. For example, the Affected Version one here.
Updated by Bruno Samora about 14 years ago
+1 and my 2 cents:
in addition to the multi select feature, would be very nice if we have some sort of autocomplete for large list, just like the one we have for project members.
Updated by Eric Davis about 14 years ago
Bruno Samora wrote:
in addition to the multi select feature, would be very nice if we have some sort of autocomplete for large list, just like the one we have for project members.
It will be better to open this second request as a new feature request. Otherwise it will be lost in this issue, which has 41 notes already.
Updated by Bruno Samora about 14 years ago
Eric Davis wrote:
Bruno Samora wrote:
in addition to the multi select feature, would be very nice if we have some sort of autocomplete for large list, just like the one we have for project members.
It will be better to open this second request as a new feature request. Otherwise it will be lost in this issue, which has 41 notes already.
Eric, issue #6225 opened
thx
Updated by Martin Fink almost 14 years ago
+1 (yes this is a important feature) :)
Updated by Leszek Ciesielski almost 14 years ago
I'd like to point all of you to issue #6914 . Enough with the "+1" already!
Updated by Maxim Yastremsky over 13 years ago
This is a feature, which my company also would to use. But the patch doesn't work on Redmine versions which are later than 0.9.
Guys, is it possible to update this patch for 1.1.1 version? it will be good
Updated by Steven Risner over 13 years ago
Is anyone working on this feature? Its huge and I can't believe its been this long. I'm hoping the existing patches can been modded to suit version 1.2, but this really needs to be part of the core.
Updated by Leszek Ciesielski over 13 years ago
FFS, can't you guys fix #6914? I've had enough of those moronic '+1' comments.
Updated by svr678 svr678 over 13 years ago
Is there some problems on this? technical or marketing consideration? Thanks!
Updated by Steffen Gebert over 13 years ago
+1
This would be a really important feature for us.. being able to select multiple affected and target versions.
Updated by Emanuele Tomeo over 13 years ago
+1
It would be a really useful feature (instead of a block to adoption this great app)
Updated by Matteo Giaccone over 13 years ago
Hi,
i've tried to make the patch working for Redmine 1.2.1 on rev6402.
Here attached my try, it's still not working as i have a bug while trying to save the multi select:
ActiveRecord::AssociationTypeMismatch in IssuesController#update CustomValue(#-612294428) expected, got CustomValuesCollection(#-612298128)
Application trace:
gems/activerecord-2.3.11/lib/active_record/associations/association_proxy.rb:259:in `raise_on_type_mismatch' gems/activerecord-2.3.11/lib/active_record/associations/association_collection.rb:321:in `replace' gems/activerecord-2.3.11/lib/active_record/associations/association_collection.rb:321:in `each' gems/activerecord-2.3.11/lib/active_record/associations/association_collection.rb:321:in `replace' gems/activerecord-2.3.11/lib/active_record/associations.rb:1331:in `custom_values=' vendor/plugins/acts_as_customizable/lib/acts_as_customizable.rb:93:in `custom_field_values=' gems/activerecord-2.3.11/lib/active_record/base.rb:2918:in `send' gems/activerecord-2.3.11/lib/active_record/base.rb:2918:in `assign_attributes' gems/activerecord-2.3.11/lib/active_record/base.rb:2914:in `each' gems/activerecord-2.3.11/lib/active_record/base.rb:2914:in `assign_attributes' gems/activerecord-2.3.11/lib/active_record/base.rb:2787:in `attributes_without_tracker_first=' app/models/issue.rb:245:in `send' app/models/issue.rb:245:in `attributes=' app/models/issue.rb:320:in `safe_attributes=' app/controllers/issues_controller.rb:292:in `update_issue_from_params' app/controllers/issues_controller.rb:174:in `update'
Is this still of any interest? Bye
Updated by Sven Eisenschmidt about 13 years ago
Could it be possible some skilled Dev update the patch to make things work in 1.2.1?
This is a highly anticipated feature.
Updated by Sven Eisenschmidt about 13 years ago
I took all patches applied them to the current Redmine 1.2 stable from SVN and made it work. See the diff attached.
Updated by Joe Goloso about 13 years ago
+1 We also need to be able to create multichoice custom fields.
Updated by Szilard Pall about 13 years ago
+1
Could any of the Redmine folks enlighten me why has this been not implemented the last 3.5 years?
Updated by Ir Rubin about 13 years ago
Sven Eisenschmidt wrote:
I took all patches applied them to the current Redmine 1.2 stable from SVN and made it work. See the diff attached.
I tried this patch but I got :
ActiveRecord::UnknownAttributeError in IssuesController#create unknown attribute: custom_multi_values
Application Trace:
/redmine/vendor/rails/activerecord/lib/active_record/base.rb:2918:in `assign_attributes' /redmine/vendor/rails/activerecord/lib/active_record/base.rb:2914:in `each' /redmine/vendor/rails/activerecord/lib/active_record/base.rb:2914:in `assign_attributes' /redmine/vendor/rails/activerecord/lib/active_record/base.rb:2787:in `attributes_without_tracker_first=' /redmine/app/models/issue.rb:245:in `send' /redmine/app/models/issue.rb:245:in `attributes=' /redmine/app/models/issue.rb:320:in `safe_attributes=' /redmine/app/controllers/issues_controller.rb:324:in `build_new_issue_from_params'
Updated by Matteo Giaccone about 13 years ago
i continue to have the same exception that i had with my patch also using yours:
ActiveRecord::AssociationTypeMismatch in IssuesController#update CustomValue(#-612294428) expected, got CustomValuesCollection(#-612298128)
someone else got it working?
Updated by Matteo Giaccone about 13 years ago
Here you are my patch working with my setup (the previous one was not working)
I have rails 2.3.11, ruby 1.8.7
Redmine 1.2.1
Updated by Leif Lange about 13 years ago
- File Error_after_applying_patch_multiple_values.pdf Error_after_applying_patch_multiple_values.pdf added
I have applied your patch to the exact same setup. However, when I try to edit or create a new custom field, I get the error:
undefined method `allow_multi' for #<IssueCustomField:0xb5738a74>
Attached is the PDF of the entire error page.
It would be really appreciated if you could shed some light.
Thanks!
Updated by Leif Lange about 13 years ago
- File Error_after_applying_patch_multiple_values.pdf Error_after_applying_patch_multiple_values.pdf added
Reattached the PDF as the previous contained errors
Updated by Matteo Giaccone about 13 years ago
Leif Lange wrote:
I have applied your patch to the exact same setup. However, when I try to edit or create a new custom field, I get the error:
[...]
Attached is the PDF of the entire error page.
It would be really appreciated if you could shed some light.
Thanks!
have you migrated the DB? it seems that you are lacking that.
Updated by Leif Lange about 13 years ago
Thanks for the reply, I had indeed forgotten issue a 'sudo rake db:migrate' command. But even after successful completion of the migration, I still get the NoMethodError complaining about the missing 'allow_multi' method.
Updated by Matt H about 13 years ago
Hi,
What are the issues that are stopping this request from being implemented and added to a formal release?
Cheers,
Matt
Updated by digital fredy about 13 years ago
+1 please add this to formal release
Updated by Jeremy Udit almost 13 years ago
Leif Lange wrote:
Thanks for the reply, I had indeed forgotten issue a 'sudo rake db:migrate' command. But even after successful completion of the migration, I still get the NoMethodError complaining about the missing 'allow_multi' method.
Same error on my installation (Ruby 1.8.7, Rails 2.3.11, Redmine 1.2.1) after running the db migration:
NoMethodError (undefined method `allow_multi' for #<IssueCustomField:0x7fb2d5c322d0>):
app/controllers/issues_controller.rb:121:in `show'
passenger (3.0.7) lib/phusion_passenger/rack/request_handler.rb:96:in `process_request'
passenger (3.0.7) lib/phusion_passenger/abstract_request_handler.rb:513:in `accept_and_process_next_request'
passenger (3.0.7) lib/phusion_passenger/abstract_request_handler.rb:274:in `main_loop'
passenger (3.0.7) lib/phusion_passenger/classic_rails/application_spawner.rb:321:in `start_request_handler'
passenger (3.0.7) lib/phusion_passenger/classic_rails/application_spawner.rb:275:in `send'
passenger (3.0.7) lib/phusion_passenger/classic_rails/application_spawner.rb:275:in `handle_spawn_application'
passenger (3.0.7) lib/phusion_passenger/utils.rb:479:in `safe_fork'
passenger (3.0.7) lib/phusion_passenger/classic_rails/application_spawner.rb:270:in `handle_spawn_application'
passenger (3.0.7) lib/phusion_passenger/abstract_server.rb:357:in `__send__'
passenger (3.0.7) lib/phusion_passenger/abstract_server.rb:357:in `server_main_loop'
passenger (3.0.7) lib/phusion_passenger/abstract_server.rb:206:in `start_synchronously'
passenger (3.0.7) lib/phusion_passenger/abstract_server.rb:180:in `start'
passenger (3.0.7) lib/phusion_passenger/classic_rails/application_spawner.rb:149:in `start'
passenger (3.0.7) lib/phusion_passenger/spawn_manager.rb:219:in `spawn_rails_application'
passenger (3.0.7) lib/phusion_passenger/abstract_server_collection.rb:132:in `lookup_or_add'
passenger (3.0.7) lib/phusion_passenger/spawn_manager.rb:214:in `spawn_rails_application'
passenger (3.0.7) lib/phusion_passenger/abstract_server_collection.rb:82:in `synchronize'
passenger (3.0.7) lib/phusion_passenger/abstract_server_collection.rb:79:in `synchronize'
passenger (3.0.7) lib/phusion_passenger/spawn_manager.rb:213:in `spawn_rails_application'
passenger (3.0.7) lib/phusion_passenger/spawn_manager.rb:132:in `spawn_application'
passenger (3.0.7) lib/phusion_passenger/spawn_manager.rb:275:in `handle_spawn_application'
passenger (3.0.7) lib/phusion_passenger/abstract_server.rb:357:in `__send__'
passenger (3.0.7) lib/phusion_passenger/abstract_server.rb:357:in `server_main_loop'
passenger (3.0.7) lib/phusion_passenger/abstract_server.rb:206:in `start_synchronously'
passenger (3.0.7) helper-scripts/passenger-spawn-server:99
Has anyone been able to fix this?
Updated by Jean-Philippe Lang almost 13 years ago
- Status changed from New to Closed
- Assignee set to Jean-Philippe Lang
- Target version changed from Unplanned backlogs to 1.4.0
- Resolution set to Fixed
Feature added in r8721.
When creating a list, user or version custom field, you can now check the "Multiple values" checkbox to make the custom fields accept multiple values.
Updated by Leszek Ciesielski almost 13 years ago
Three years since I lost interest in this ticket I have initially raised and after almost a hundred of unwanted notifications - thank you for finally resolving this. May I again point you to #6914 ?
Updated by pasquale [:dedalus] almost 13 years ago
Jean-Philippe Lang wrote:
Feature added in r8721.
Question: existing list could be converted to "Multiple values" behavior?
Updated by pasquale [:dedalus] almost 13 years ago
pasquale [:dedalus] wrote:
Question: existing list could be converted to "Multiple values" behavior?
auto-reply: yes! because r7434 ;-)